Programowanie po stronie serwera (PHP)

Dlaczego: Metoda GET umieszcza parametry w adresie URL po znaku zapytania, więc adres z wynikami można skopiować, wysłać komuś i dodać do ulubionych. Metoda POST przenosi dane w treści żądania, dzięki czemu hasło nie trafia do paska adresu, historii przeglądarki ani logów serwera. Kusi odpowiedź o szyfrowaniu, ale POST niczego nie szyfruje - dane chroni dopiero HTTPS.

Dlaczego: Protokół HTTP jest bezstanowy, więc serwer musi jakoś rozpoznać kolejne żądania tego samego użytkownika. Sesja przechowuje dane po stronie serwera, a przeglądarka otrzymuje wyłącznie identyfikator sesji. Ciasteczko przechowuje samą wartość u klienta, ma limit rzędu 4 kB i przetrwa zamknięcie przeglądarki. Ostatnia odpowiedź kusi, bo zamienia role obu mechanizmów miejscami.

Dlaczego: Aby zniszczyć sesję, trzeba ją najpierw wczytać - dopiero funkcja session_start udostępnia bieżącą sesję skryptowi. Musi ona wystąpić przed wysłaniem czegokolwiek do przeglądarki, bo operuje na nagłówkach HTTP; nawet pusta linia albo spacja przed znacznikiem otwierającym PHP daje komunikat headers already sent. Ta sama zasada dotyczy funkcji setcookie oraz header.

Dlaczego: Dane od użytkownika sklejone z treścią zapytania stają się jego częścią, więc mogą zmienić strukturę warunku i pominąć sprawdzenie hasła. Zapytanie z parametrami działa dwuetapowo: najpierw do serwera bazy trafia szkielet ze znakami zapytania, potem osobno wartości, których serwer nigdy nie interpretuje jako kodu SQL. Walidacja w JavaScripcie i atrybut maxlength działają u klienta i da się je ominąć.

Dlaczego: Funkcja password_hash sama dokłada losową sól, więc to samo hasło daje za każdym razem inny skrót o długości około 60 znaków - dlatego ponowne zahashowanie i porównanie napisów zawsze zawiedzie, a sól z gotowego skrótu wyciąga dopiero funkcja password_verify. Skrót md5 jest szybki i łamany z gotowych tablic, więc nie nadaje się do haseł.

Dlaczego: Atak XSS polega na tym, że przeglądarka odbiera wstrzyknięty tekst jako kod i go wykonuje. Zamiana znaków specjalnych na encje sprawia, że przeglądarka traktuje je jako zwykłe znaki do wyświetlenia, a treść w bazie pozostaje nietknięta. Usuwanie znaczników to zadanie funkcji strip_tags, a ucieczka apostrofów w zapytaniu to real_escape_string - to inne narzędzia i inne zagrożenie.

Dlaczego: Funkcja explode dzieli napis w miejscach separatora i tworzy tablicę indeksowaną o kluczach liczonych od zera, więc pierwszy fragment ma indeks 0, a drugi indeks 1. Separator wystąpił dwa razy, co daje trzy fragmenty, a funkcja count podaje liczbę elementów, nie liczbę separatorów. Najczęstsza pomyłka to liczenie indeksów od jedynki.

Dlaczego: Metoda fetch_assoc zwraca jeden wiersz jako tablicę asocjacyjną, w której kluczami są nazwy kolumn, i przesuwa wskaźnik na następny wiersz; gdy wierszy zabraknie, zwraca null i warunek pętli while staje się fałszywy. Pętla foreach ma sens dopiero na gotowej tablicy wierszy, a właściwość num_rows podaje wyłącznie ich liczbę.

Dlaczego: Puste pole formularza z atrybutem name i tak zostaje wysłane, tylko z pustym napisem jako wartością - dlatego klucz w tablicy istnieje. Funkcja isset odpowiada na pytanie, czy klucz istnieje i nie jest nullem, a funkcja empty na pytanie, czy wartość jest pusta. Uwaga na pułapkę: dla wpisanego ciągu 0 funkcja empty również zwraca prawdę, choć użytkownik coś podał.

Dlaczego: Serwer WWW po rozpoznaniu rozszerzenia pliku nie odsyła jego zawartości, tylko przekazuje ją interpreterowi PHP. Wynikiem wykonania jest czysty HTML i tylko on wędruje do klienta, więc kod nigdy nie opuszcza serwera. Na tym polega różnica względem JavaScriptu, który jest widoczny w źródle, bo wykonuje go przeglądarka użytkownika.