O tym typie ataku każdy kto tworzy strony powinien słyszeć. Powinien go znać. Powinien się go bać. Jest wiele opracowań na jego temat, nie chcę powielać całej teorii, o czym jest on, jaka jest podstawowa obrona.
No dobra, podstawowa obrona to odpowiednie eskejpowanie znaków specjalnych. Brzmi prosto prawda? I w sumie jest proste. Są jednak sytuacje trudne do przewidzenia, wyszukiwania i miejsca gdzie naprawdę skomplikowaliśmy dane zapytanie. W takich miejscach, możemy przejrzeć całość, możemy dodać wiele testów a i tak za, załóżmy, 5 miesięcy zjawi się osoba która przypadkowo lub celowo odkryje problem w danym miejscu. Problem który sprawi, że zapytanie wywoła się błędnie. Możemy się czarować i oszukiwać – ja jestem doskonały, ja nie popełniam błędów.
Ja wychodzę z podobnego założenia. Jednak mam świadomość, że każdy może mieć gorszy dzień (kac, dzieci biegające w koło, ktoś z bliskiej rodziny w szpitalu, czy masa innych powodów na rozkojarzenia). Możemy z jakiegoś powodu nie dokończyć danej funkcjonalności, wrócić do niej za kilka dni i zwyczajnie zapomnieć o prostym wywołaniu jakiejś funkcje eskejpującej dla któregoś parametru. Zawsze się znajdzie powód, najdrobniejsze rozkojarzenie które utrudni nam pracę.
Tak miałem nawet nie wiem kiedy. Ale dzisiaj, włączyłem komputer, przeglądam maile i ustalam sobie plan dnia. W pewnym momencie zaczynam dostawać kilkanaście wiadomości – przeważnie to spam, więc mało chętnie sprawdzam. Jedna, druga, trzecia skrzynka pusta… o kurde, to maile o błędach SQL. I to jest to zabezpieczenie o którym chciałbym opowiedzieć więcej.
Większość zabezpieczeń jakie stosuje się w systemach informatycznych to logowanie. Kiedy z takiego systemu jesteśmy w stanie wyciągnąć informacje o błędach? Gdy się zalogujemy, gdy sprawdzimy. Może być to 5 minut po, może to być 30 minut po, może to być dzień po, a może to być i miesiąc po. W takim przypadku, zidentyfikowanie problemu, jego rozwiązanie jest już za późno. Włamanie dawno miało miejsce, szkody poczynione.
W przypadku powiadomienia mailowego (można wykorzystać inne komunikatory zaimplementowane w dany CMS), mamy to powiadomienie natychmiastowo. Mamy możliwość aktywnego zareagowania. Mamy możliwość wyłączenia strony, zrobienia szybkiego patcha i włączenia strony – a 99% użytkowników nawet nie zauważy że coś miało miejsce.
Bylibyście zainteresowani przykładową implementacją?