Która praktyka NIE zwiększa bezpieczeństwa aplikacji internetowej korzystającej z bazy danych?
Pełny komunikat błędu bazy danych zdradza nazwy tabel i kolumn, fragment zapytania, a czasem ścieżki plików na serwerze. Dla atakującego to gotowa mapa aplikacji, która ułatwia np. wstrzykiwanie SQL. Dlatego ta praktyka nie zwiększa bezpieczeństwa, tylko je obniża.
Poprawnie użytkownik dostaje krótki, ogólny komunikat, np. „Wystąpił błąd, spróbuj później”, a szczegóły trafiają do dziennika na serwerze, np. przez error_log(). Na serwerze produkcyjnym w pliku php.ini ustawia się display_errors = Off. Szczegółowe błędy na ekranie są dopuszczalne tylko na komputerze programisty.
Ta sama zasada dotyczy stron z błędem 404 czy 500: pokazują prosty komunikat, bez szczegółów technicznych.
Każda z błędnych odpowiedzi opisuje środek, który realnie chroni aplikację. Zapytania przygotowane, np. mysqli_prepare() z bind_param(), przesyłają dane oddzielnie od treści zapytania, więc wpisany w formularz fragment SQL nie zostanie wykonany.
Funkcja password_hash() zamienia hasło na skrót z losową solą. Nawet po wycieku bazy hasła nie da się po prostu odczytać, a sprawdza się je funkcją password_verify().
Zasada najmniejszych uprawnień oznacza, że konto, którym aplikacja łączy się z bazą, ma tylko potrzebne prawa, np. SELECT i INSERT, bez DROP. Udany atak wyrządzi wtedy mniejsze szkody.
Szczegółowe komunikaty działają dokładnie odwrotnie: niczego nie blokują, a tylko podpowiadają atakującemu, jak zbudowana jest baza.
Te trzy środki uzupełniają się: zapytania przygotowane blokują atak, skróty chronią hasła, a ograniczone prawa zmniejszają szkody, gdyby atak jednak się udał.