Piękny chwytliwy nagłówek. Podobnych używał w swoich książkach Scott Kelby, żeby przyciągnąć czytelników i zmusić do przeczytania wstępu. W przeciwieństwie do niego, tutaj krzykliwy nagłówek jest mocno związany z treścią artykułu. Może nie w taki sposób, w jaki można by się tego spodziewać, ale po kolei :).
Pierwsza zasada bezpieczeństwa tworzenia skryptów jakiej mnie uczyli – wyłącz register_globals w php.ini. Skąd się w ogóle register_globals wzięło? Chyba tylko z wiary w dobro natury ludzkiej. Tylko że programista powinien być z natury swojej paranoikiem poszukujących wszędzie wrogów chcących naruszyć bezpieczeństwo jego dzieła. Ważne jest to szczególnie tam, gdzie w grę wchodzą dane wrażliwe włączając w to (ale nie ograniczając tylko do) dane osobowe. O innych przypadkach danych wrażliwych i ich zabezpieczaniu – innym razem.
Wróćmy do tematu, bo powoli odbiegamy. Co to jest ten register_globals, o którym wszyscy krzyczą? W swojej idei jest to wspaniałe rozwiązanie ułatwiające robotę programiście. Oto bowiem odwołując się do zmiennych np. z przesłanego formularza nie musi już pisać
[code]if(isset($_POST[’nazwisko’])) (…)[/code]
zastąpić to można prostym
[code]if(isset($nazwisko))[/code]
Nie ograniczamy się przy tym tylko do zmiennych $_POST. Te same możliwości dostępu mamy do zmiennych $_GET, $_SESSION i $_COOKIE. Skoro więc jest tak dobrze to dlaczego jest tak źle? Przyjrzyjmy się fragmentowi kodu pliku, dajmy na to index.php:
[code]foreach($userdata as $ud) {
if($ud->user == $user && $ud->pass == $pass)
$zalogowany = 1;
}
if($zalogowany == 1) {
(…)
[/code]
Porównujemy sobie w pętli przetworzone (dlaczego, o tym też kiedyś napiszę) dane logowania z przygotowaną tablicą użytkowników. Jeżeli znajdujemy, to umieszczamy sobie flagę $zalogowany = 1 i kontynuujemy wyświetlanie treści tylko dla zalogowanych. Tymczasem wystarczy, by odwiedzający stronę wywołał ją w ten sposób:
[cci]index.php?zalogowany=1[/cci] i nieszczęście gotowe – nie podając żadnego hasła dostaje się do naszej strony tylko dla zalogowanych. Można temu zapobiegać na różne sposoby – najprościej dopisać [cci lang=”php]$zalogowany=0;[/cci] na początku naszego kodu – i już jesteśmy kryci. Ale głównym winowajcą jest flaga [cci]register_globals[/cci] w php.ini która programistów rozleniwia. Pamiętajmy że duże grono osób to uczyło się programowania samodzielnie. A tak nabrane złe nawyki bardzo ciężko wykorzenić.
Z niebezpieczeństw związanych z register_globals zaczęli sobie zdawać sprawę administratorzy serwerów wyłączając tę funkcję na serwerach hostingowych. Paradoksalnie – część użytkowników sprowadziła przez to na siebie jeszcze większe niebezpieczeństwo. Nie mając /czasu/środków/ochoty (niewłaściwe skreślić) na zmianę często znacznych ilości kodu poszli oni na łatwiznę stosując funkcję extract na początku każdej strony:
[code]if(!empty($_GET)) extract($_GET);
if(!empty($_POST)) extract($_POST);
if(!empty($_COOKIE)) extract($_COOKIE);
if(!empty($_SESSION)) extract($_SESSION);[/code]
Zastosowanie extract w odwrotnej kolejności niż wyżej spowoduje, że zmienne pobrane np. z tablicy sesji zostaną zastąpione przez te z tablic [cci]$_POST[/cci], a co gorsza także z [cci]$_GET[/cci]. Tu niebezpieczeństwo zmanipulowania danych jest ogromne, szczególnie w połączeniu z innymi technikami ataku. Ale o tym innym razem 😉
I na dobrą sprawę tu mógłbym zakończyć wpis. Pozostała jednak jeszcze jedna kwestia – trzeba się przed czytelnikami z tytułu rozliczyć. Nic z tego co powyżej, nie jest specjalnie odkrywcze, by uzasadniać tak krzykliwy nagłówek. O co więc chodzi? O postawę developerów PHP.
Od wersji PHP [cci]5.3.0[/cci] flaga register_globals została uznana za przestarzałą. Co za tym idzie – należy zrezygnować z jej stosowania.
Idąc dalej, w PHP od wersji [cci]6.0.0[/cci][cci]5.4.0[/cci] flaga ta nie jest stosowana! Nowe pokolenia programistów nie poznają tego dobrodziejstwa, ale dzięki temu ich aplikacje będą choć odrobinę odporniejsze na ataki.
Leave a Reply