Zaletą blokowania ataków SQL injection przez system zaporowy jest możliwość ochronienia wielu serwerów WWW i aplikacji za pomocą jednego zestawu reguł. Upraszcza to wdrożenie aplikacji i późniejsze zarządzanie nimi, zwłaszcza w bardziej rozbudowanych środowiskach.

Podstawową wadą takiego rozwiązania jest fakt, że filtruje ono jedynie zawartość ścieżki URI. W konsekwencji możliwe jest jedynie zabezpieczenie aplikacji wykorzystujących metodę GET, w których dodatkowy kod zostaje doklejony do parametrów po znaku "?". Aplikacje wykorzystujące metodę POST nie będą chronione, ponieważ kod ataku jest w ich przypadku przekazywany poza ścieżką URI.

Barykada na serwerze

Ochrona serwisu na poziomie systemu zaporowego ma poważną wadę - brak możliwości analizy ruchu szyfrowanego za pomocą SSL. W tego typu zastosowaniach lepszym rozwiązaniem wydaje się blokowanie ataków na serwerze WWW . Jak pokazuje przykład oprogramowania NGSecureWeb, najlepiej zrobić to projektując rozwiązanie filtrujące w formie modułu rozszerzającego serwera Apache (tzw. DSO - Dynamic Shared Object).

NGSecureWeb to tzw. firewall aplikacyjny. Oprogramowanie takie działa podobnie jak system zaporowy (filtruje ruch), lecz pozwala na analizę protokołów wyższych warstw i ściśle współpracuje z serwerem aplikacyjnym (w tym przypadku z serwerem WWW ). NGSecureWeb współpracuje z następującymi serwerami: Apache 1.3, Microsoft IIS oraz iPlanet (Sun One). Do instalacji pakietu na serwerze Apache jest niezbędny program axps, umieszczający w pliku konfiguracyjnym serwera Apache odwołanie do modułu filtrującego.

Modułem można zarządzać za pomocą graficznej konsoli lub bezpośrednio, edytując pliki konfiguracyjne serwera.

Działanie modułu jest bardzo proste: przechwytuje on zlecenia płynące do serwera WWW w ostatniej fazie ich przetwarzania. Może więc analizować i ewentualnie blokować dane, które mają zostać przekazane do aplikacji. Tak działający filtr jest odporny na techniki polegające np. na kodowaniu części URI w formacie UNICODE. Pakiet NGSecureWeb potrafi wykrywać i blokować kilka typów ataków na serwery aplikacyjne.

Do obrony przed atakami SQL injection możemy wykorzystać filtr słów kluczowych Forbidden Words Protection. Po skonfigurowaniu słowa kluczowego SELECT, każda próba użycia go w dowolnej części zlecenia HTTP spowoduje zwrócenie przez serwer strony informującej o zablokowaniu ataku.

W odróżnieniu od Firewall-1 oprogramowanie NGSecureWeb potrafi analizować argumenty przekazywane metodą POST. Ponadto, oprócz ataków typu SQL injection, może ono blokować inne typy ataków na serwery aplikacyjne, np. wywoływanie zdalnych komend, przepełnienie bufora, manipulacje nagłówkami HTTP, directory traversal (wyjście poza domyślny katalog aplikacji/użytkownika) itd. Niestety, ono również nie jest wolne od wad. Największą z nich jest to, że można filtrować jedynie pojedyncze słowa, a nie np. całe wyrażenia. Z punktu widzenia polityki bezpieczeństwa błędem jest także fakt, że oprogramowanie zawsze informuje intruza o tym, że atak został zablokowany, wyświetlając stronę z odpowiednim komunikatem.

Nadzieja w nowej fali

Zagrożenie atakami typu SQL injection jest poważne, a grono narażonych na nie firm ogromne, dlatego można oczekiwać, że wkrótce powstanie nowa generacja narzędzi służących do ich neutralizacji. Jaskółką zwiastującą te zmiany jest firewall aplikacyjny CodeSeeker. Program stworzony przez firmę Butterfly Security jest obecnie rozwijany w ramach projektu OWASP - Open Web Application Security Project (http://www.owasp.org/codeseeker ) i rozpowszechniany na licencji GPL (open source).

CodeSeeker może działać w dwóch trybach: jako system wykrywania włamań - jedynie logujący próby ataków - lub też jako firewall - nie tylko wykrywający, lecz także blokujący nieautoryzowane działania. Największą zaletą oprogramowania CodeSeeker są rozbudowane możliwości definiowania ataków oraz reakcji na naruszenia zdefiniowanej polityki bezpieczeństwa. Ma też gotową bazę sygnatur ataków w postaci pliku w formacie XML z możliwością jej rozbudowy o własne wpisy. Trwają prace nad przystosowaniem CodeSeekera do współpracy z bazą sygnatur VulnXML, opracowywaną w ramach projektu OWASP.

CodeSeeker ma tę przewagę nad NGSecureWeb, że konsolę oddzielono w nim od agenta (Connector) bezpośrednio komunikującego się z serwerem WWW . Konsola jest aplikacją Java i może równolegle kontrolować wiele agentów. Same agenty są zaś zaimplementowane jako moduły współpracujące z różnymi serwerami WWW . Wersja obecnie udostępniona do testów współpracuje tylko z serwerem WWW Microsoft IIS (jako filtr ISAPI), jednak dokumentacja wspomina również o modułach dla Apache i iPlanet.