Jak się bronić przed SQL Injection

Podstawowym sposobem zabezpieczania przed tym atakiem jest niedopuszczenie do nieuprawnionej zmiany wykonywanego zapytania, czyli ochrona przed "ucieczką" kodu SQL z treści parametrów. W najpopularniejszym języku tworzenia aplikacji webowych, PHP, można to osiągnąć przez użycie wbudowanej funkcji addslashes(). Używając jej z każdym parametrem tekstowym, wykorzystywanym później do konstrukcji zapytania SQL, uzyskuje się automatyczne oznaczanie znaków specjalnych, takich jak apostrof, cudzysłów czy slash. W wyniku tej operacji, znaki specjalne "przemycane" w treści parametrów tekstowych są traktowane jak tekst i nie powodują zmian w treści zapytania. Przy pracy ze zmiennymi liczbowymi warto skorzystać z funkcji is_numeric(). Po pozytywnym wyniku sprawdzenia, taką zmienną można bezpiecznie wykorzystać przy budowie zapytania SQL. Podobne narzędzia są dostępne także dla języka PERL.

Opracowano również lepszą metodykę, nazywaną "zaślepką", która polega na tym, że zmienne nie są używane do bezpośredniego budowania zapytania, ale przekazywane do niego przy odwołaniu. Można do tego celu użyć API danego motoru albo w warstwie aplikacji wykorzystać odpowiednie zacytowanie wszystkich parametrów. Wykorzystanie procedur składowanych w bazie bardzo podwyższa bezpieczeństwo, gdyż utrudnia modyfikację zapytań.

Bardzo ważną techniką, która utrudnia wykorzystanie istniejących luk w bezpieczeństwie, jest wyłączenie wszystkich komunikatów o błędach oraz sygnaturki serwera. Chociaż atak w dalszym ciągu będzie możliwy, wykrycie podatności oraz sposobu jej wykorzystania wymaga o wiele więcej pracy.

Sesja do przejęcia

Jedną z ważnych luk w bezpieczeństwie jest niedostateczna ochrona sesji użytkownika. Gdy informacja o sesji (zachowana na przykład w pliku cookie) nie będzie dostatecznie chroniona, napastnik może próbować przejąć sesję poprawnie zalogowanego użytkownika, przez wywołanie adresu typowego dla otwartej sesji serwisu. Nie jest tajemnicą, że niektóre ataki tą drogą kierowane przeciw aplikacjom webowym (nawet systemom transakcyjnym bankowości elektronicznej), udawały się. Czasami informacje na temat cookie i sesji są zawarte w kodzie HTML. Na początku wykorzystywania tej technologii można było nawet spotkać sprawdzanie poprawności połączenia po stronie przeglądarki za pomocą skryptu w języku JavaScript. Takie praktyki są niedopuszczalne.

Aby uniknąć przejęcia sesji klienta, należy wdrożyć szyfrowanie informacji o sesji przechowywanych w cookie, wprowadzić zabezpieczenia w samej aplikacji lub kontrolerze jej dostarczania (application delivery controller) lub inne mechanizmy w firewallu aplikacyjnym. Najskuteczniej działa agregowanie informacji o sesji, takie jak: adres IP, informacje o wykorzystywanej przeglądarce (UserAgent), akceptowane przez nią języki strony czy rozdzielczość ekranu. Po agregowaniu tych danych i ochronie za pomocą mechanizmów kryptograficznego skrótu oraz połączeniu z szyfrowanym cookie, można uzyskać dość dobry poziom bezpieczeństwa. Niektóre rozwiązania rozszerzają tę funkcjonalność o ochronę aplikacji przed nieautoryzowaną zmianą parametrów - urządzenia tej klasy produkuje firma F5 Networks.

Przy planowaniu ochrony sesji należy pamiętać, że niekiedy adres IP klienta może się zmienić nawet w czasie sesji.

W przypadku wykrycia prawdopodobnego naruszenia sesji, można wymagać ponownego uwierzytelnienia, wyświetlając przy okazji informacje o alarmie sesji. Można też wysłać alert administracyjny. Niezależnie od wybranego rozwiązania, należy monitorować próby manipulacji związane z przejęciem sesji.

Smaczne ciasteczko

Pewna część aplikacji webowych korzysta z plików cookie do identyfikacji uprawnień użytkownika. Jeśli te informacje nie są zaszyfrowane, napastnik może je zmodyfikować w ten sposób, by zmienić swój poziom uprawnień. Te zmiany można wykonać za pomocą odpowiedniego, lokalnego serwera proxy albo po wyposażeniu przeglądarki w skrypty, które potrafią modyfikować sesję (to umożliwia dodatek Greasemonkey dla Firefoksa, technologię skryptów użytkownika wspierają wszystkie nowoczesne przeglądarki). Dobrze napisana aplikacja musi sprawdzać autentyczność cookie i nie wolno w ten sposób przekazywać wprost informacji o uprawnieniach. To samo dotyczy przekazania informacji o uprawnieniach wprost przez POST lub GET.