[PHP][Bezpieczeństwo] Absolutne podstawy bezpieczeństwa w PHP cz.1

PHP niesłusznie jest nazywany mało bezpiecznym językiem. Przeświadczenie takie pozostało po poprzednich wersjach języka, które szczerze mówiąc rzeczywiście pozostawiały wiele do życzenia w kwestiach bezpieczeństwa, szczególnie w rękach mało doświadczonych programistów. To się jednak zmieniło, a PHP wciąż ewoluuje. Prawda jest taka, że poprawnie skonfigurowany serwer, z poprawnie skonfigurowanym PHP i prawidłowo skonfigurowaną bazą danych, na których działa poprawnie napisana aplikacja to mieszanka, która może się okazać naprawdę bardzo bezpieczna.
Trzeba jedynie trzymać się pewnych reguł i zasad, mieć pojęcie o możliwych typach ataków i pisać kod "z głową". W cyklu artykułów tutaj postaramy się omówić sobie wszystkie najważniejsze zasady, których bezwzględnie powinniśmy się trzymać podczas pisania swoich aplikacji w PHP. Na spokojnie, w cyklu kilku artykułów omówimy sobie także zabezpieczenia po stronie serwera, silnika, bazy i zasady bezpiecznej ich konfiguracji.
Idąc na przekór wielu poradnikom, które opisuję jedynie techniczne aspekty dodam od siebie kilka spraw, które nie są zazwyczaj opisywane w poradnikach. Zaczynamy część pierwszą, która zarazem będzie jedynie wstępem i krótkim wprowadzeniem do cyklu artykułów.

Zasada numer zero, czyli po co "hackerom" moje dane.

Postanowiłem jako pierwsze (a właściwie zerowe) opisać pewne błędne założenie, które ja nazywam następująco: "Prowadzę stronę o chomikach, więc po co crackerom moja baza danych?".
Jest to bardzo często spotykane myślenie wśród osób zarządzających swoimi serwerami i oprogramowaniem. Jest to myślenie jak najbardziej niepoprawne. Należy bowiem pamiętać, że każda zdobyta informacja - nawet taka jak dostęp do bazy danych strony o chomikach jest na wagę złota.

Po pierwsze - daje to crackerowi wolny dostęp do danych na serwerze, po drugie - co łączy się z pierwszym - na serwerze tym może też wkrótce (lub już istnieje) pojawić się inny serwis, do którego z automatu będzie miało się dostęp. Po trzecie - może to też być hosting dzielony, co stworzy crackerowi jeszcze większe pola do popisu. Po czwarte - w bazie danych mogą znaleźć się i najprawdopodobniej się znajdują dane kluczowe dla użytkowników, jak ich loginy, hashe haseł (lub nawet czasami same hasła otwartym tekstem co woła o pomstę do nieba), ich emiale i inne dane osobowe. Dane takie są cenne, gdyż istnieje prawdopodobieństwo, że dany użytkownik używa podobnych danych do logowania np. na swoją skrzynkę pocztową. Stąd już krótka droga do kilku socjotechnicznych zabiegów i np. przejęcia konta w banku. Brzmi jak bajka? To nie jest bajka, lecz rzeczywistość i taki z pozoru nic cennego nie posiadający serwis o hodowaniu chomików może wywołać nieświadomie tzw. efekt motyla, przez który ucierpieć mogą nieświadomi użytkownicy.

Biorąc więc pod uwagę powyższe (a opisałem tylko kilka aspektów) powinniśmy zawsze pamiętać, że nawet z pozoru nic nieznacząca aplikacja webowa może w rzeczywistości wywołać prawdziną lawinę, za którą odpowiedzialni będziemy właśnie my. W związku z tym - każda, nawet najmniejsza aplikacja działająca w sieci powinna być dokładnie przeanalizowana i przede wszystkim stworzona z uwzględnieniem wszystkich niezbędnych wymogów bezpieczeństwa. Wiadomo, że nikt nie jest wróżbitą, a żadna aplikacja nie jest idealna i w 100% bezpieczna, ale trzymając się kluczowych zasad możemy przynajmniej sprawić, że nie będzie ona dla crackera jak otwarta książka.

Złota zasada - każdego użytkownika traktujemy jako potencjalnego atakującego.
Bez wyjątków.

1. Absolutne podstawy - register_globals i spółka

register_globals

Szczerze mówiąc nie wiedziałem, czy o tym pisać, gdyż praktycznie każdy o tym wie, ale skoro mamy zaczynać od podstaw, to zaczniemy od absolutnych podstaw, czyli niefortunnej pozostałości z dawnych czasów, czyli register_globals. Funkcja ta - wbudowana w PHP - choć mam nadzieję wyłączona już domyślnie na każdym serwerze na świecie odpowiadała swego czasu za niezły bałagan. Jej włączenie powodowało, że wszystkie zmienne w skrypcie traktowane były jak zmienne globalne. Co za tym idzie - można było zmienić zawartość dowolnej tablicy, takiej jak $_POST, czy $_SESSION bezpośrednio z każdego miejsca, nawet z paska adresu. Nie wiem jak powstał tak szalony pomysł, mimo wszystko powstał i wciąż jest dostępny jako opcja konfiguracyjna w php.ini. Jeśli więc jakimś cudem opcja ta jest u nas włączona, to wyłączamy ją bezwzględnie w php.ini:
[code]register_globals = off[/code]
Przy okazji - wszędzie w kodzie rezygnujemy z używania dyrektywy:
[code]global $zmienna;[/code]
Zamiast tego odwołujemy się do zmiennej globalnej z tablicy:
[code]$zmienna = $GLOBALS['zmienna'];[/code]

Złota zasada - sprawdź dokładnie ustawienia serwera na jaki ładujesz swoj kod.
Bez wyjątków.

Filtrowanie zmiennych

O tym raczej też każdy doskonale wie, choć pewnie zdarzą się wyjątki, dlatego opiszę i ten fakt. Każda, powtarzam KAŻDA zmienna przyjmowana do skryptu z zewnątrz MUSI być odfiltrowana. Niedopuszczalne jest pozostawienie choćby jednej zmiennej, którą może wprowadzić użytkownik w surowej postaci, bez żadnej walidacji. Nie ma znaczenia, czy zmienna ta to wartość pola z formularza, czy numer ID jakiegoś elementu podawany przez GET - filtrujemy bez wyjątku nawet mało istotne z punktu widzenia aplikacji zmienne. Filtrowanie nie powinno polegać jedynie na sprawdzeniu typu zmiennej, lecz również na dokonaniu sprawdzenia zawartości, np. za pomocą preg_match(), dopasowaniu do wzorca, który zmienna może przyjąć i dopiero po weryfikacji na przepuszczeniu zmiennej do skryptu. Zmienne, które mogą przyjąć jedynie kilka możliwych wartości traktujemy za pomocą switch(), nieużywane zmienne zwalniamy z pamięci serwera za pomocą unset(). Pamięć serwera wbrew pozorom też może zostać odczytana, ale to już temat na inny artykuł.

Złota zasada - nie ufaj ani jednej zmiennej, której zawartość pochodzi od uzytkownika.
Bez wyjątków.

Raportowanie błędów

W domyślnej konfiguracji interpreter PHP w przypadku wystąpienia błędu wyrzuca na ekran obszerną informację o błędzie. Informacja taka zawiera nazwę pliku, linijkę wystąpienia i może też zawierać więcej kluczowych informacji. Takie raportowanie bardzo przydaje się w środowisku deweloperskim, jednakże na produkcji stanowi realne niebezpieczeństwo. Zasada jest taka - im mniej użytkownik (a więc potencjalny atakujący) wie, tym lepiej dla nas. W środowisku prodykcyjnym najlepiej jest, jeśli całkowicie wyłączymy raportowanie błędów w php.ini:
[code]error_reporting = E_NONE;[/code]

Złota zasada - o technicznych aspektach błędów powinien wiedzieć jedynie developer.
Bez wyjątków.

Łapanie wyjątków

Wszystkie kluczowe fragmenty kodu, których błąd może spowodować nieprawidłowe dalsze działanie aplikacji koniecznie umieszczajmy w blokach
[code]try{}[/code].
Pamiętajmy jednak, żeby ewentualnie rzucone wyjątki złapać w bloku
[code]catch{}[/code]
Nieobsłużony wyjątek może spowodować błąd i ujawnić wiele informacji, których ujawniać nie powinien. Pamiętajmy przy tym o zewnętrznych, nie swoich bibliotekach, jakich używamy w kodzie - ich też to dotyczy.

Złota zasada - rzucaj i łap.
Wyjątki.

Sesja

Identyfikator sesji przesyłamy tylko i wyłącznie za pomocą Cookies. Nigdy nie dołączamy ID sesji jako parametr URL-a. Ponadto, sesja powinna być niszczona i generowana na nowo podczas każdej zmiany uprawnień użytkownika, takiej jak przejście z użytkownika niezalogowanego do zalogowanego, czy zalogowanie na inny poziom uprawnień. Sesja powinna być niszczona po zamknięciu przeglądarki. Dobrym rozwiązaniem jest także wykonanie wszystkich połączeń dotyczących logowania po HTTPS - ruchu takiego nie da się rozszyfrować w warunkach domowych, w przeciwieństwie do połączenia HTTP. Będzie o tym dłużej w kolejnym artykule. Cookie oczywiście w pewnych warunkach też można przejąć za pomocą Javasciptu, ale o tym też będzie stosowny artykuł. Jako podstawę pamiętajmy na razie, aby za każdym od nowa generować sesję, gdy zmieniają się poziomy uprawnienia.

Złota zasada - nie ufaj z założenia, że dane sesji są prawdziwe.
Bez wyjątków.

Hasła, hasła, hasła i jawny tekst!!!!

Najbardziej kardynalnym błędem jest trzymanie jakichkolwiek haseł dostępu w bazie danych w formie jawnej, czystym tekstem.

Jest to absolutnie niedopuszczalna sytuacja, która z miejsca dyskwalifikuje aplikację z listy "bezpiecznych". Żadnych haseł w bazie nie trzymamy i należy o tym pamiętać - trzymamy jedynie ich hashe. Poza tym, nie hashujemy haseł za pomocą popularnego kiedyś MD5, lecz za pomocą silniejszych algorytmów, typu SHA. MD5 można złamać dość szybko za pomocą obecnie dostępnych technologii. Konsoli PS3 zajmuje to chwilę.

To jedno. Drugą sprawą jest posolenie haseł, tak aby problemem było ich porównanie z tablicami tęczowymi. O poprawnym "soleniu" szerzej będzie w następnym artykule. Po trzecie - hashujemy w kilku przebiegach, używając funkcji hashującej kilkukrotnie.

Złota zasada - trzymaj hashe haseł, nie hasła.
Bez wyjątków.

Produkcja i developing

A to już kategoryczny błąd logistyczny - praca bezpośrednio na produkcji, niestety spotykany dość często. Pamiętajmy, aby nigdy nie robić tak niebezpiecznych manewrów. Od wprowadzania i testowania zmian w kodzie powinno służyć TYLKO I WYŁĄCZNIE środowisko deweloperskie. Zmiany na wersję produkcyjną powinniśmy wprowadzić dopiero po dokładnym ich przetestowaniu w środowisku deweloperskim! Wiadomo, w życiu różnie bywa i czasem trzeba na szybko wprowadzić jakąś poprawkę - ale lepiej wtedy wyłączyć całkowicie serwis i rozwiązać problem na spokojnie. Straty spowodowane niedziałającym serwisem zazwyczaj są o rząd wielkości mniejsze, niż straty spowodowane błędem w oprogramowaniu, a takowe dość często występują podczas wprowadzania zmian "na szybko".

Złota zasada - nie spiesz się.
Bez wyjątków.

Konfiguracja serwera

Nasza aplikacja może być zabezpieczona nawet przed trzęsieniem ziemii i uderzeniem meteorytu, ale polegnie w przypadku błędów konfiguracji samego serwera. Jeśli mamy dostęp do własnego serwera, nawet wykupionego dedykowanego to zabezpieczamy i konfigurujemy go w odpowiedni sposób (o tym będzie dalej). Jeśli takowego serwera nie posiadamy i korzystamy z hostingu dzielonego to bardzo ważnym jest sprawdzenie na jakiej konfiguracji taki serwer pracuje i zabezpieczenie kluczowych rzeczy np. za pomocą odpowiednich plików .htaccess. Nie ufamy hostingodawcy i jego głośnym marketingowym zapewnieniom. Sprawdzamy wszystko sami. W taki sposób poległ ostatnio serwis e-dym.pl (artykuł o tym tutaj), gdzie jedna mała literówka spowodowała wyświetlenie listy katalogów na serwerze Home.pl (tak, home.pl ma domyślnie włączony listing plików w przypadku braku pliku indexu i nie da się tego w standardowy sposób zmienić nawet za pomocą .htaccess).

Złota zasada - nie ufaj publicznym serwerom.
Bez wyjątków.

Testujemy, testujemy i jeszcze raz testujemy

Nigdy nie wrzucamy nieprzetestowanej na wiele okoliczności aplikacji na produkcję. Starajmy się dokonać jak najwięskzej ilości testów na serwerze deweloperskim, starając się przewidzieć wszystkie anomalne zachowania. Jest to trochę zabawa we wróżbitę, jednakże starajmy się w miarę możliwości przewidzieć każdy aspekt "co by było, gdyby..." i testujmy taką ewentualność, nawet jeśli wydaje się ona absurdalna i z pozoru niemożliwa do wystąpienia. Jeśli okaże się, że na daną, nawet totalnie dziwną okoliczność nasza aplikacja jest podatna - zabezpieczamy ją pod tym kątem.

Złota zasada - najpierw przetestuj, potem udostępniaj.
Bez wyjątków.

2. Struktura aplikacji

Dołaczanie zewnętrznych skryptów - include i require

Praktycznie zawsze nasza aplikacja składa się z wielu plików dołączanych do pliku głównego. Pliki takie nie powinny mieć możliwości uruchomienia ich poza aplikacją. Aby zapobiec takiemu działaniu w każdym załączanym za pomocą include, lub require pliku umieszczajmy warunek sprawdzający, czy plik ładowany jest z naszej aplikacji, czy nie. Jeśli nie jest - kończymy jego działanie. Można to zrobić np. za pomocą stałych. W pliku głównym, który dołącza plik zewnętrznym deklarujemy stałą, np.:
[code]
<?php
define('IN_APP', true);
require 'inny_plik.php';
?>[/code]
W zewnętrznym pliku następnie umieszczamy na początku warunek:
[code]
<?php
// inny_plik.php
if(!defined('IN_APP')) die();
?>[/code]

Złota zasada - pamiętaj, że zarządzasz tym co i jak ma się wykonywać.
Bez wyjątków.

Struktura folderów

Na zewnątrz (z poziomu webserwera) wystawiamy jedynie te pliki, które muszą zostać udostępnione użytkownikowi, takie jak arkusze CSS, czy pliki .js. Cały kod naszej aplikacji nie powinien być dostępny z poziomu webservera. Przykładowo, wyobraźmy sobie taką strukturę aplikacji:
[code]
/server
    /kod
    /web
      /js
      /css
      /img
      index.php
[/code]
   
W przypadku tym, Document Root serwera, np. Apache'a powinien wskazywać na katalog /web. Katalog /kod powinien być ponad nim, co za tym idzie - nigdy nie powienien być dostępny z zewnątrz. Zabezpieczenie takie sprawi, że nawet w przypadku wystąpienia jakiegoś nieoczekiwanego błędu - użytkownik nigdy z poziomu przeglądarki nie uzyska dostępu do plików z kodem.

Złota zasada - użytkownik dostaje dostęp tylko do plików, do których koniecznie musi dostać dostęp.
Bez wyjątków.

Bootstrapping

Z powyższym wiążę się jeszcze jedno - korzystajmy z bootstrapów (nie mylić z nazwą frameworka). Jest to potoczna nazwa na pliki, które startują naszą aplikację, ustawiają jakieś wstępne parametry itd. Bardzo częto sam plik index.php jest takim bootstrappem, ładującym całą resztę komponentów aplikacji. Takie rozwiązanie jest niepoprawne. Dlaczego? Już pokazuję. Będzie to skrajny przypadek, może się jednak wydarzyć.
Wróćmy do struktury naszej aplikacji:
[code]
/server
    /kod
    /web
      /js
      /css
      /img
      index.php
[/code]
Załóżmy teraz, że w pliku index.php znajduje się cały kod startujący naszą aplikację, ładujący pliki z katalogu /kod itd. Co teraz się stanie w przypadku awarii serwera lub jakiejś pomyłki, czy błędu w skutek którego zawartość pliku index.php zostanie wyświetlona? W najlepszym przypadku wycieknie struktura naszej aplikacji, w najgorszym - o wiele więcej danych. Dlatego właśnie lepszym rozwiązaniem jest zawarcie całej logiki startującej aplikację np. w pliku:
[code]/kod/bootstrap.php[/code]
Następnie w pliku index.php dodajemy jedynie jedną linijkę kodu, ładującą bootstrapa:
[code]
<?php
// index.php
require '../kod/bootstrap.php';
?>[/code]
W przypadku takim, atakująca nas osoba nie uzyska dostępu do logiki startującej naszą aplikację, gdyż katalog /kod znajduje się poza zasięgiem Document Root webservera.

Złota zasada - nie każdy błąd przewidzisz.
Bez wyjątków.

Directory Index - wyłączamy listowanie katalogów

To już kwestia konfiguracyjna serwera, nie PHP. Wyświetlanie listy plikow w katalogu w przypadku braku pliku indeksu należy koniecznie wyłączyć.  Można to zrobić za pomocą pliku konfiguracyjnego Apache'a (o ile pracujemy na Apache'u) lub w katalogu za pomocą pliku .htaccess.

Złota zasada - nie pokazuj co masz w środku.
Bez wyjątków.

Trzymanie krytycznych danych

To bardzo częsty błąd, gdy ktoś zarządzający serwerem trzyma na nim kluczowe dane, takie jak backup bazy danych, czy pliki tekstowe z hasłami, tudzież jakieś pliki "na chwilę". Nie ma znaczenia, że pliki takie mogą znajdować się w 10 z rzędu podfolderze, w tzw. "głębokim ukryciu" (swoją drogą bardzo ciekawe określenie, które chyba już weszło do mowy potocznej w środowiskach IT ;). Takie działanie jest absolutnie niedopuszczalne, równie dobrze można te dane wystawić w katalogu głównym i dać do nich odnośnik na głównej stronie - na jedno wyjdzie. Pamiętajmy więc o tym - na serwerze produkcyjnym powinny znaleźć się JEDYNIE te pliki, które są wymagane do pracy aplikacji, nic więcej. Naprawdę należy o tym pamiętać, gdyż sytuacja taka, że na serwer poleci coś co nie powinno się tam znaleźć może wystąpić nawet w skutek przeoczenia, czy pośpiechu.

Złota zasada - pamiętaj o tym co wrzucasz na serwer.
Bez wyjątków.

Hasła do bazy

To zawsze jest problem - gdyż o ile dane logowania możemy zapisać w bazie danych jako posolone, przyprawione i popieprzone hashe, o tyle dane logowania do bazy musimy zapisać gdzieś na serwerze jawnym tekstem - inaczej nie połączymy się z bazą. Z punktu widzenia "fizycznego" - danych tych nigdy nie zabezpieczymy w 100% (zdobycie hasła do konta FTP serwera wystawi je zawsze na tacy jawnym tekstem), możemy jednak utrudnić do nich dostęp. Przede wszystkim plik z danymi dostępowymi trzymamy poza katalogiem webserwera (czyli Document Rootem np. Apache'a). Pozwoli to już jako tako wyeliminować problem z przypadkowym dostępem do tego pliku z poziomu przeglądarki/z zewnątrz.

Po drugie - nie definiujmy tych parametrów jako zmienne, czy tablice globalne, a najlepiej jako prywatne lub dziedziczone własności klasy. Ciekawym rozwiązaniem - i chyba od strony technicznej najlepszym jest zapisanie takich danych w wewnętrznych zmiennych serwera, a następnie pobranie ich do skryptu PHP z tablicy $_ENV. W przypadku takim - hasła wyciekną jedynie w przypadku włamania na konto w systemie serwera, gdzie atakujący uzyska dostęp do plików konfiguracyjnych webservera, np. Apache'a. W przypadku jednak tak krytycznego włamania, dane do bazy to już jedynie pikuś w porównaniu z resztą rzeczy jakie może zdobyć i zrobić cracker.

Rozwiązanie takie ma jednak taki minus, że musimy posiadać swój własny serwer, lub serwer dedykowany - na hostingu dzielonym nikt nie udostępni nam dostępu do plików konfiguracyjnych. To od strony "fizycznej" - bo zdarzyć się też może, że hasła możemy nieświadomie udostępnić sami - jeśli nie za pomocą swojego błędu to z powodu nieznajomości mechanizmów na jakich działają np. biblioteki osób trzecich, które dołączamy do swojej aplikacji. Nawet PDO może w prosty sposób wyświetlić dane dostępowe do bazy - wystarczy nieprawidłowo obsłużyć wyjątek połączenia lub nieobsłużyć go w ogóle i hasło oraz login wypluje się jawnym tesktem jako błąd na ekranie. Musimy zawsze o tym pamiętać i czasami wręcz "myśleć za innych" oraz dokładnie analizować dokumentację i kod bibliotek jakie dołączamy do swojej aplikacji.

Złota zasada - myśl za innych.
Bez wyjątków.

Dostęp do bazy danych

Z powyższym, czyli z hasłami do bazy wiąże się też sam dostęp do bazy. Zauważyłem, iż często popełnianym błędem jest praca aplikacji z bazą danych na koncie użytkownika bazy, którego uprawnienia przewyższają wymagania aplikacji, dość często nawet na koncie root, które to posiada pełne uprawnienia. Nigdy nie robimy czegoś takiego na serwerze produkcyjnym. Na serwerze produkcyjnym tworzymy w bazie danych użytkownika o jak najmniejszych uprawnieniach w stosunku do wymagań aplikacji. Nie dodajemy ANI JEDNEGO uprawenienia więcej, niż wymaga tego aplikacja. Strona o hodowaniu chomików nie wymaga przecież uprawnień do wykonania operacji DROP TABLE ;) Aplikacja na produkcji powinna więc działać z możliwie jak najmniejszymi uprawnieniami jeśli chodzi o dostęp do bazy danych.

Złota zasada - nie rusza się z bazooką na mrówki.
Bez wyjątków.

Środowiska produkcyjne i deweloperskie

Rozdzielenie sobie dwóch środowisk to sprawa kluczowa i należy się tego modelu pracy trzymać. Wszelką pracę, zmiany w kodzie, usprawnienia wykonujemy jedynie na serwerze deweloperskim, nigdy na serwerze produkcyjnym. Serwer produkcyjny powinien otrzymywać nowy kod jedynie po dokładnym przetestowaniu go na środowiskach deweloperskim i testowym. Niedopuszczalne jest wprowadzanie zmian "na gorąco" bezpośrednio na serwerze produkcyjnym. Środowisko testowe powinno być czymś w rodzaju środowiska deweloperskiego, ale imitujące zachowania środowiska produkcyjnego. Warto sobie utworzyć takie środowisko.

Złota zasada - rozdzielaj środowiska jak dwa odrębne światy.
Bez wyjątków.

Dostęp do środowiska deweloperskiego

Bardzo często spotykany błąd. Wiele z firm udostępnia np. swoim klientom wersje "deweloperskie" jako publiczne, gdzieś na swoich serwerach, pod adresami typu:
[code]http://firma_robiaca_strone.com/klientXYZ/test[/code].

Jest to totalnie niedopuszczalne działanie. Z doświadczenia wiem, że klient często wymaga jakiegoś dostępu do wglądu poczynionych prac, ale dostęp taki, o ile już taki musi być, to powinien być jedynie dla klienta, nie dla 7 miliardów ludzi na tej planecie. Jeśli już musimy udostępnić komuś wersję nie do końca ukończoną, to po pierwsze udostępniamy ją za pomocą jakiegoś sposobu uwierzytelnienia - np. za pomocą prostego HTTP Basic i white-listy IP.

Po drugie - niech to nie będzie nigdy środowisko deweloperskie, a specjalnie przygotowane testowe. Niesamowicie przydatnym rozwiązaniem jest określenie sobie w kodzie aplikacji jakiejś stałej, lub zmiennej, która określa na jakim środowisku pracuje aplikacja. Na deweloperskim możemy sobie wtedy np. włączyć obsługę błędów, a na produkcyjnym zablokować dostęp do danych opcji. Bardzo przydatna sprawa - stosowana np. we frameworkach jak Symfony.

Pamiętajmy także zawsze, że wszystko co udostępniamy w sieci pozostaje tam na wieki. Jeśli np. przypadkiem udostępnimy wersję deweloperską, lub testową bez zabezpieczenia jej, to istnieje realna szansa, że aplikacja/strona wyląduje w cache np. Google lub webarchive.org. Kolejną sprawą jest to, że dostęp dla crackera do środowiska deweloperskiego danej aplikacji, którą postanowi później zaatakować w wersji produkcyjnej jest jak udostępnienie mu książki pt. "How to hack me...". Pamiętajmy o tym!

Złota zasada - klient może sobie chcieć, Ty bądż mądrzejszy.
Bez wyjątków.

To tyle tytułem absolutnego wstępu.
Opisałem bardzo mało tak na dobrą metę - są to absolutne podstawy.
Niebawem część 2, w której obszerniej opiszę pozostałe, już trochę bardziej złożone aspekty.