Nie da się całkowiecie zabezpieczyć przed "włamaniem się do bazy danych". Można jedynie utrudnić to pewnej grupie użytkowników. Żeby potencjalne zagrożenie wycieku danych z bazy przezornie zabezpieczyć powinieneś stosować się do zasad, które normalizują to zjawisko, czyli powodują, że coś takiego w bardzo krótkim czasie jest prawie niemożliwe ze względu ograniczeń czasowych jak i technologicznych.
Powinieneś zatem śledzić najnowsze i najstabilniejsze funkcje do haszowania haseł i innych kryptograficznych funkcjonalności i implementować je we własnym systemie - zastępować je w miejsce starych instrukcji. Najlepiej jeszcze czytać odpowiednie artykuły, które mówią o tym zagadnieniu, żeby uciekać się do tego, co jest naprawdę w miarę sensowne i bezpieczne z punktu widzenia bezpieczeństwa.
Kroki, które powinno się podjąć, by przeciwdziałać atakom na własne strony WWW i nie tylko, to:
- "bindowanie" - wiązanie danych, które są wysyłane do parsera oddzielnie, zapobiega to w dużej mierze takim atakom jak SQL Injection. Należałoby też poczytać o słabych punktach takiego zastosowania, bo nic nie zostaje bez konsekwencji, coś za coś.
- nie ufanie każdym przychodzącym danym do serwera. Wszystkie dane, a to wszystkie powinny być odpowiednio spreparowane, przefiltrowane i w takiej formie powinny trafić do najbardziej newralgicznych miejsc po stronie back-endu.
- sprawdzanie zapytań SQL pod kątem podatności na "zamulenie" odczytu danych z bazy i nie tylko. Niepoprawnie napisane zapytanie może przysporzyć wiele i to naprawdę wiele kłopotów.
- zabezpieczenie sesji, napisanie jej w miarę unikalnej po stronie serwera jak i front-endu, jeśli front-end, np. cookies korzystają z takiego rozwiązania, a nawet jeśli front nie korzysta z sesji, to także trzeba wziąć pod uwagę atak na sam back-end.
- testowanie napisanego systemu, testy automatyczne i manualne, żeby czasem się nie okazało, że jest jakaś luka.
Na koniec dodam, jak wszyscy wiedzą powinno się pisać także czysty kod, aby był czytelny dla nas i dla innych. Wyeliminuje to zapewne większość błędów na etapie produkcji.
Ostatnia wzmianka o której wspomnę, to jest to, że "końcowym korzystającym z danego produktu jest sam użytkownik" - Gynvael Coldwind o tym mówił na którymś streamie. Czyli nic się nie da do końca uchronić przed niejakimi atakami na produkt, który finalnie trafia do nas użytkowników. Są to, np. cheaty do gier (oszustwa) i nic się z tym nie zrobi. Były, są i będą takie rozwiązanie stosowane przez niektórych. Funkcje kryptograficzne rozkodowujące np. sesję z PHP, która jest wykorzystywane przez cookies po stronie przeglądarki (front-end). Takie przykłady można by mnożyć.