Juniper Netscreen IDP – Atak SQL Injection Signature Evasion

W wyniku prowadzonych przez nasz zespół badań, zostanie zaprezentowany atak omijania mechanizmów bezpieczeństwa na przykładzie produktu światowego lidera w dziedzinie systemów IDS/IPS – Systemu IDP firmy Juniper Networks.

Analiza działania testowanego systemu IDS/IPS

W celu przeprowadzenia badań na wykrywanie różnych wariantów ataków typu SQL Injection wykorzystaliśmy system wykrywania i zapobiegania włamaniom – IDP firmy Juniper Netscren. Z wykorzystaniem implementacji podatnej aplikacji oraz dwóch skryptów umożliwiających wykonanie zautomatyzowanych ataków przeprowadzono szereg testów działania urządzenia (Skrypty oraz ich opis dostępne tutaj).

Dlaczego system Juniper?

Wybraliśmy system firmy Juniper aby zademonstrować, że nawet bardzo zaawansowane rozwiązania źle skonfigurowane mogą dawać złudzenie ochrony. Systemy Juniper są jednymi z najlepszych na świecie komercyjnych rozwiązań, a mimo to trzeba dużej pracy aby chroniony system był dobrze zabezpieczony.
Poniższy opis nie ma na celu zachwalać żadnego z rozwiązań, jest to opis na przykładzie praktycznym problemów związanych z implementacją bezpiecznych środowisk, z mechanizmami ataków na systemy bezpieczeństwa. Taki opis przedstawiamy na wybranym przykładzie jednym z wielu i pokazujemy pewne słabości systemu. Zachęcamy czytelnika do własnych eksperymentów z innymi systemami co pozwala najdokładniej zrozumieć istotę problemów i pozwala lepiej przygotować się do wdrażania własnych zabezpieczeń.
Przedstawimy pewne sposoby oszukania systemu IDP. Mam nadzieję, że ten opis przyczyni się do pewnych refleksji na temat skuteczności stosowanych zabezpieczeń w wielu firmach i korporacjach.
Zachęcamy czytelnika to zastanowienia się jak w opisanym przypadku można zapobiec włamaniu, kradzieży haseł z bazy danych, wykonaniu bardzo niebezpiecznego ataku SQL Injection.

W celu zrozumienia zasad działania systemów IDS/IPS poniżej opisana zostanie architektura systemu Juniper.

System Juniper ­Netscreen IDP (Intrusion Detection and Prevention) jest rozwiązaniem pozwalającym w aktywny sposób chronić zasoby systemowe przed atakami warstwy od drugiej do siódmej włącznie. Aktywna ochrona oznacza, że każdy atak, wykryty przez urządzenie, może zostać zablokowany lub podjęta inna zdefiniowana akcja. System potrafi analizować ruch począwszy od warstwy łącza danych ISO/OSI, a skończywszy na warstwie aplikacyjnej. Dlatego też największe zastosowanie znajduje w analizie protokołów w najwyższych warstwach – to znaczy tam, gdzie kończą się możliwości inspekcji klasycznych systemów firewall. Analiza ruchu może być realizowana w oparciu o aktualizowaną na bieżąco bazę sygnatur, ale także w oparciu o mechanizmy detekcji anomalii protokołów (odstępstw od standardów RFC), czy też anomalii ruchu.

Zasady funkcjonowania mechanizmów systemu IDP określa Polityka Bezpieczeństwa, definiowana zgodnie z potrzebami przez administratora. Polityka składa się z reguł i realizowana jest w sposób zbliżony do systemów firewall (opiera się na adresie źródłowym, docelowym, oraz nazwie usługi).

Architektura rozwiązania:

System Juniper ­ Netscreen IDP posiada architekturę trójwarstwową:

1. Sensory sieciowe (lub klastry sensorów) ­ realizujące monitoring / filtrację ruchu
2. Serwer zarządzający ­ odpowiedzialny za zbieranie informacji z sensora oraz implementację reguł polityki
3. Konsola GUI ­ umożliwiająca konfigurację, dostęp do rejestru zdarzeń, definicję polityki, itp.

Sensory systemu Juniper ­ Netscreen IDP mogą funkcjonować w jednym z 4 dostępnych trybów:

1. Router – sensor jest ”widoczny” w warstwie III ISO/OSI i forwarduje przefiltrowane pakiety zgodnie ze zdefiniowaną tabelą routingu.
2. Transparentny – z punktu widzenia sieciowego sensor realizuje funkcje w sposób analogiczny do repeater’a sieciowego – powiela cały ruch otrzymany na jednym interfejsie na drugi interfejs forward’ujący
3. Bridge – z punktu widzenia sieciowego sensor realizuje funkcje w sposób analogiczny do bridge’a sieciowego – powiela ruch otrzymany na jednym interfejsie na drugi interfejs forward’ujący, jeżeli wynika to z wpisów w tablicy adresów MAC
4. ARP­ Proxy – sensor odpowiada własnym adresem MAC na zapytania o adresy IP, znajdujące się w segmencie przyłączonym do przeciwległego interfejsu. Następnie, forwarduje otrzymane w ten sposób pakiety do docelowego hosta.

Detekcja ataków

System Juniper ­ Netscreen IDP oferuje różnorodne techniki detekcji / prewencji ataków:

1. Wykrywanie anomalii ruchu – wszelkie specyficzne charakterystyki ruchu sieciowego, które występują przy znanych atakach sieciowych (skanowanie portów, skanowanie sieciowe, rozproszone skanowanie, ICMP Sweep) mogą być w inteligentny sposób rozpoznawane i blokowane przez system IDP
2. Wykrywanie ataków DoS typu SYN Flood – próby wrogiego zablokowania usług udostępnianych na serwerach w strefach DMZ poprzez inicjowanie dużej liczby połączeń klienckich o statusie ”półotwartym” mogą być wykrywane i blokowane przez system IDP
3. Sygnaturowe wykrywanie ataków – ruch sieciowy, odpowiadający sygnaturom ataków może być blokowany, bądź unieszkodliwiany w inny sposób. Dopasowywanie sygnatur jest realizowane kontekstowo – co oznacza, że dana sygnatura jest wyszukiwana jedynie w takim kontekście aplikacyjnym ruchu, w którym jej obecność mogłaby stanowić realne zagrożenie (np. ataki typu POP3 Overflow, będą wyszukiwane jedynie dla ruchu zgodnego z protokołem POP3, w polach danych pakietów zawierających zapytania do serwerów pocztowych)
4. Wykrywanie ataków w oparciu o anomalie protokołów – ruch sieciowy, w którym występują odstępstwa od standardów przyjętych dla konkretnego protokołu (np. niezgodności z RFC), może być wykrywany i blokowane przez system IDP.
5. Wykrywanie wrogiego oprogramowania typu Backdoor – ruch sieciowy, może być w sposób heurystyczny analizowany pod kątem specyfiki typowej dla programowania szpiegowskiego (interakcje pakietów wysyłanych/odbieranych, rozmiar pakietów, itp) i w przypadku zaistnienia podejrzenia w odpowiedni sposób unieszkodliwiany.
6. Utrudnianie enumeracji usług oraz wychwytywanie intruzów prowadzących działania rekonesansowe (Network Honeypot) – poprzez symulowanie nieistniejących usług na istniejących serwerach, możliwe jest lepsze rozpoznanie profili prowadzonych ataków, a jednocześnie sytuacja taka prowadzi do utrudnienia działań rozpoznawczych, realizowanych przez potencjalnych intruzów.
7. Eliminowanie sytuacji typu false positive – w sytuacjach, w których system IDP działa w oparciu o mechanizmy bezsygnaturowe (heurystyka, wykrywanie anomalii), zdarzają się klasyfikacje błędnej klasyfikacji ruchu. W takich przypadkach niezbędne jest zdefiniowanie reguł wyjątków, które spowodują, że poprawny ruch nie będzie traktowany jako działania intruza.

Poniższy schemat ilustruje powiązania funkcjonalne poszczególnych systemów IDP:

Zaimplementowane sygnatury wykrywające atak SQL Injection:

Sygnatura w systemie IDP, to wyrażenie regularne oraz szereg parametrów konfiguracyjnych dotyczących analizowanego ruchu sieciowego.
Zaimplementowane sygnatury współpracującej z system IDP mają zdefiniowany kontekst aplikacyjny, którego te sygnatury mają dotyczyć. Kontekst aplikacyjny jest to określone pole nagłówka. Sensor IDP dokonuje pseudo reasemblacji fragmentów IP w pakiety IP. Pakiety te są następnie konwertowane w strumień TCP, jeśli zawierają pola danych. Strumień TCP jest to uporządkowana sekwencja danych, które są przesyłane z jednej aplikacji do drugiej przez sieć.

Sposób reasemblacji fragmentów pakietów IP wygląda następująco:

W systemie IDP sygnatury posiadają informację, jaki kontekst aplikacyjny ma być przeszukiwany. Dla protokołu HTTP, zdefiniowanych jest wiele kontekstów aplikacyjnych. Poniżej przedstawionych jest kilka wybranych kontekstów aplikacyjnych (protokół HTTP):

1. http­-request­-method,
2. http­-url,
3. http­-url­-parsed,
4. http­-url­-parsed­param,
5. http­-variable,
6. http­-variable­-parsed,
7. http­-header­-host,
8. http­-header,
9. http­-header­-referer,
10. http­-authorization,
11. http­-header­-accept­-encoding,
12. http­-header­content­-encoding,
13. http­-header­-content­-language,
14. http­-header­-content­-location,
15. http­-data,
16. http­-text­-plain,
17. http­-param­-parsed.

Aby dokładniej wyjaśnić istotę kontekstów, czyli pól protokołu HTTP, poniżej przedstawiony zostanie przykład:

GET /test.php?id=%49
Host:10.0.0.2
Content­Type: application/x­www­form­urleWWW­Authenticate: Basic realm=”TEST”
Referer: http://10.0.0.1/
Accept­Encoding: gzip,deflate
Content­Encoding: gzip
Content­Language: pl
Content­Location: /
Connection: close

Konfiguracja systemu do testów:

Routery wirtualne

Do celów testów systemu IDP zdefiniowano jedynie jeden router wirtualny, skojarzony z interfejsami forwardującymi Eth2 oraz Eth3:

Router wirtualny ”Test” obsługuje ruch pomiędzy serwerem z podatną na atak aplikacją, a hostem z którego wykonywano symulację ataków. Tryb pracy sensora ustawiono na całkowicie przeźroczysty dla protokołów, ponieważ taka konfiguracja nie wpływa w żadnym stopniu na ruch sieciowy przepuszczany przez urządzenie. Jest to konfiguracja najczęściej stosowana przy implementacji tego typu rozwiązań.

Implementacja polityki bezpieczeństwa:

W celu przeprowadzenia testów wykrywania ataków typu SQL Injection zdefiniowano dwa obiekty – obiekt źródła ataku oraz obiekt jakim jest host docelowy. Adresy IP ustawiono na 10.0.0.1 dla hosta źródłowego oraz 10.0.0.2 dla hosta docelowego. Na sensorze zainstalowano politykę, zawierającą jedynie cztery reguły reagujące na różne formy ataku SQL Injection, mogącego zagrozić aplikacji używającej serwera MySQL.

Wybór reguł

Zostały zaimplementowane cztery reguły wykrywające ataki typu SQL Injection. Są to reguły przeznaczone do różnych środowisk aplikacyjnych, nie są one dedykowane do określonej aplikacji. System IDP posiada znacznie więcej reguł wykrywających ataki SQL Injection, lecz te reguły dotyczą specyficznych aplikacji (np. phpBB, PHP-Nuke, itp.) i ich wykorzystanie do aplikacji w której nie została potwierdzona luka lub aplikacji dedykowanej konkretnemu odbiorcy byłoby błędem implementacyjnym jeśli chodzi o stosowanie zabezpieczeń.
Zaimplementowane reguły stanowią wszystkie dostępne reguły do zabezpieczania każdej aplikacji WWW przed atakami typu SQL Injection.
Jest to o tyle istotne, że jak pokażemy poniżej, żadna z nich nie wykrywa skutecznego ataku na testową aplikację!
Skąd więc taki brak w zabezpieczeniach? Czemu nie zostały zaprojektowane lepsze sygnatury?

Jako ciekawostkę podam, że jako referencję do tych czterech sygnatur, firma Juniper podaje następujący artykuł:
Bugtraq
Po dalszej części opisu czytelnicy na pewno znajdą kilka drobnych niuansów, które nie zostały zawarte w artykule jak i również w zaimplementowanych sygnaturach 🙂

Jako kolejną ciekawostkę podam również, że sygnatury IDP są zbudowane w oparciu o sygnatury systemu Snort.

Poniższy schemat ilustruje zaimplementowaną politykę bezpieczeństwa:

W przypadku wykrycia ataku żadna akcja prócz logowania nie jest podejmowana. Typ akcji ustawiono na NONE. W przypadku wykrytego ataku następuje logowanie zdarzenia, oraz jednego pakietu sprzed i jednego po rozpoczęciu ataku, co jest wystarczające do analizy przebiegu ataku.

Sygnatury

Analiza sygnatur IDP:

Reguły ataków opierają się na sygnaturach będących wyrażeniami regularnymi. Jeżeli w odpowiednim polu pakietu zostanie dopasowany ciąg do wzorca, atak zostaje wykryty i odpowiednio ustalona akcja zostaje wykonana. System IDP wykorzystuje bibliotekę PCRE do pracy z wyrażeniami regularnymi.
Implementacja obsługi wyrażeń regularnych w przypadku systemu IDP różni się nieco od powszechnie stosowanych implementacji.

Poniżej przedstawiono wyrażenia regularne wspierane przez system IDP:

Notacja, dla wyrażeń regularnych różni się nieco od powszechnie stosowanych implementacji.
Powszechnie stosowana składnia dla wyrażeń w zapisie heksadecymalnym jest następująca:
\xliczba_szesnastkowa

Sensor IDP nie wspiera następujących wyrażeń regularnych:

1. Ograniczenie słowa: zapis \<>
2. Powrotne odwołanie: zapis \1
3. Ograniczniki zakresów: zapis { , }

Implementacja testowanych reguł:

Reguła 1

Pierwsza z ustawionych reguł to reguła o nazwie HTTP: Generic SQL Injection Detection. Jest to najbardziej ogólna ze wszystkich ustawionych reguł.

Wyrażenie regularne używane w tej regule jest następujące:

.(­­|’|#|;).

Opis wyrażenia regularnego:

Powyższe wyrażenie regularne dopasowuje każde wyrażenie zawierające przynajmniej jeden ze znaków:

­­–
‘
#
;

Sygnatura ta wykrywa znaki komentarzy zapytań SQL oraz próby zamknięcia oryginalnego ciągu znaków przy pomocy apostrofu. Reaguje również na znak średnika, który może zostać wykorzystany do zakończenia jednego zapytania w celu dołączenia kolejnego, spreparowanego. Jest bardzo prosta, przez co może powodować powstawanie fałszywych alarmów (ang. False Positives).

Fałszywe alarmy:

Przykładowe przyczyny powstawania fałszywych alarmów dla prawidłowego ruchu HTTP:
Saint John‘s,
Ocena semestralna ucznia: ­­–3
3,5;4,5;5,5

Słabość sygnatury:

Słabość tej sygnatury wynika, z braku implementacji wszystkich możliwych sposobów stosowania komentarzy. W testowanym ataku posłużono się komentarzem /**/, którego ta sygnatura nie wykryje.
Kolejną słabością jest bardzo słabo rozwinięte wyrażenie.
Dla przykładu – w ataku SQL Injection nie zawsze wymagane jest zastosowanie komentarza do wstrzyknięcia zapytania.
Następnym brakiem w powyższej sygnaturze jest brak zawartego w niej znaku cudzysłowu. W zależności od konstrukcji samego skryptu, atakujący nieraz wykorzystuje znak cudzysłowu zamiast apostrofu.
Słabość sygnatury przejawia się również tym, iż bardzo łatwo może zostać wywołany fałszywy alarm.

Reguła 2

Drugą z ustawionych reguł jest reguła o nazwie HTTP: SQL Command Chain in URL Detection (1)

Wyrażenie regularne używane w tej regule jest następujące:

(.*[^\060­\071\0101­\0132\0141­\0172])?\[(create|union|select|insert|update|delete|
drop|intersect|execute|minus|grant|\|\|)\](\040|\053)
(.*[^\060­\071\0101­\0132\0141­\0172])?\[(from|where|set|order|table| count|
function|into)\]([^\060­\071\0101­\0132\0141­\0172].*)?

Opis wyrażenia regularnego:
Powyższe wyrażenie regularne powoduje dopasowanie każdego ciągu zawierającego:

Na początku dowolny ciąg znaków, następnie dowolne znaki nie należące do zbioru znaków alfanumerycznych – zero lub jedno powtórzenie,
Następnie dowolne ze słów kluczowych: create, union, select, insert, update, delete, drop, intersect, execute, minus, grant, ||, lub ich kombinacji ­ nierozróżnialna wielkość znaków,
Następnie znak spacji lub +,
Następnie na początku dowolny ciąg znaków, następnie dowolne znaki nie należące do zbioru znaków alfanumerycznych – zero lub jedno powtórzenie,
Następnie dowolne ze słów kluczowych: from, where, set, order, table, count, function, into lub ich kombinacji ­ nierozróżnialna wielkość znaków,
Następnie na początku dowolny ciąg znaków, następnie dowolne znaki nie należące do zbioru znaków alfanumerycznych, następnie dowolny symbol występujący zero lub więcej razy – zero lub jedno powtórzenie.

Fałszywe alarmy:

Przykładowe możliwe przyczyny powstawania fałszywych alarmów dla prawidłowego ruchu HTTP:
European Union Set to Vote on Data Law,
Using Drag and Drop From JavaScript.

Słabość sygnatury:

Powyższa sygnatura nie wykryje zapytania, w którym spacje zostają zastąpione innymi separatorami.
Przykładami zapytań SQL, które nie zostaną dopasowane do wzorca mogą być:

select(dane)from(tabela),
select/**/dane/**/from/**/tabela,

Taka metoda ominięcia zabezpieczenia została użyta podczas testów podatnej aplikacji, za pomocą pierwszego exploita. Do wykorzystania podatności w testowanej aplikacji, za pomocą drugiego exploita nie wykorzystywano słów kluczowych zawartych w powyższym wyrażeniu regularnym. Wykorzystano jedynie operator logiczny and (również operator or mógł być użyty z powodzeniem), oraz funkcję systemową bazy danych MySQL, tym samym taka sygnatura nie była w stanie wychwycić ataku.

Reguła 3:

Trzecią ustawioną regułą jest reguła o nazwie HTTP: SQL Command Chain in URL Detection (2)
Wyrażenie regularne używane w tej regule jest następujące:

(.*[^\060­\071\0101­\0132\0141­\0172])?\[(create|union|select|insert|update|delete|
drop|intersect|execute|minus|grant|\|\|)\](\040|\053)
(.*[^\060­\071\0101­\0132\0141­\0172])?\[(into|from|where|set|order|table|
count)\].*\[(into|from|where|set|order|table|count|function|openrowset|
xp_cmdshell)\]([^\060­\071\0101­\0132\0141­\0172].*)?

Opis wyrażenia regularnego
Powyższe wyrażenie regularne powoduje dopasowanie każdego ciągu zawierającego:

Na początku dowolny ciąg znaków, następnie dowolne znaki nie należące do zbioru znaków alfanumerycznych – zero lub jedno powtórzenie,
Następnie dowolne ze słów kluczowych: create, union, select, insert, update, delete, drop, intersect, execute, minus, grant, ||, lub ich kombinacji – nierozróżnialna wielkość znaków,
Następnie znak spacji lub +,
Następnie na początku dowolny ciąg znaków, następnie dowolne znaki nie należące do zbioru znaków alfanumerycznych – zero lub jedno powtórzenie,
Następnie dowolne ze słów kluczowych: into, from, where, set, order, table, count lub ich kombinacji – nierozróżnialna wielkość znaków, zero lub więcej powtórzeń,
Następnie dowolne ze słów kluczowych: into, from, where, set, order, table, count, function, openrowset, xp_cmdshell lub ich kombinacji – nierozróżnialna wielkość znaków,
Następnie na początku dowolny ciąg znaków, następnie dowolne znaki nie należące do zbioru znaków alfanumerycznych, następnie dowolny symbol występujący zero lub więcej razy – zero lub jedno powtórzenie.

Fałszywe alarmy:
Możliwe przyczyny powstawania fałszywych alarmów dla prawidłowego ruchu HTTP:
How to Create Order from Chaos?

Słabość sygnatury:
Powyższa sygnatura nie wykryje zapytania, w którym spacje zostają zastąpione innymi separatorami.
Przykładami zapytań SQL, które nie zostaną dopasowane do wzorca mogą być:

select(dane)from(tabela),
select/**/dane/**/from/**/tabela.

Sygnatura ta również nie jest w stanie wykryć ataków typu Blind SQL Injection, wykorzystujących warunki logiczne, funkcje MySQL służące do manipulacji łańcuchami znaków oraz funkcje umożliwiające pobranie różnych istotnych informacji z serwera.

Reguła 4:

Ostatnią z ustawionych reguł jest reguła o nazwie HTTP: SQL Command in URL

(.*[^\060­\071\0101­\0132\0141­\0172])?\[(create|union|select|insert|update|delete|
drop|intersect|execute|minus|grant|\|\|)\](\040|\053).*

Opis wyrażenia regularnego:
Powyższe wyrażenie regularne powoduje dopasowanie każdego ciągu zawierającego:

Na początku dowolny ciąg znaków, następnie dowolne znaki nie należące do zbioru znaków alfanumerycznych – zero lub jedno powtórzenie,
Następnie dowolne ze słów kluczowych: create, union, select, insert, update, delete, drop, intersect, execute, minus, grant, ||, lub ich kombinacji – nierozróżnialna wielkość znaków,
Następnie znak spacji lub + zero lub więcej powtórzeń.

Fałszywe alarmy:
Możliwe przyczyny powstawania fałszywych alarmów dla prawidłowego ruchu HTTP:

What is execute ?,
Minus 10,
How to Create a solid archive?

Słabość sygnatury:
Powyższa sygnatura nie wykryje zapytania, w którym spacje zostają zastąpione innymi separatorami.

Przykładami zapytań SQL, które nie zostaną dopasowane do wzorca mogą być:

select(dane)from(tabela),
select/**/dane/**/from/**/tabela

Sygnatura ta również nie jest w stanie wykryć ataków typu Blind SQL Injection, wykorzystujących warunki logiczne, funkcje MySQL służące do manipulacji łańcuchami znaków oraz funkcje umożliwiające pobranie różnych istotnych informacji z serwera. Sygnatura ta również nie jest zbyt dobrze napisana, z powodu częstych możliwych wystąpień fałszywych alarmów.

Jaki atak nie zostanie wykryty?

Opisując tutaj słabość sygnatur systemu IDP nie opisałem przykładu ataku, jaki będzie bardzo skuteczny (np. pobranie dowolnego rekordu z bazy danych), a jednocześnie niezauważony przez system wykrywania włamań.

Nie będę się tutaj bardzo szczegółowo rozpisywał na temat analizy ataku. Zachęcam najpierw zapoznać się z artykułami dotyczącymi SQL Injection w sekcji Artykuły. W rozpatrywanym przypadku bardzo pomocne będzie przeczytanie części 5 artykułu dotyczącego SQL Injection (znajdują się tam także testowe aplikacje oraz exploity wraz z ich dokładnym opisem).

Jednym z przykładów ataków, które będą skuteczne, pomimo zastosowania zabezpieczeń może być:

http://host/test.php?id=1/**/and/**/ord(mid(version(),1,1))/**/=/**/77/*

Taki atak nie zostanie dopasowany do wzorca w wyrażeniach regularnych używanych przez IDP, które są szczegółowo opisane poniżej.

Złożone sygnatury:

System IDP umożliwia stworzenie sygnatury złożonej z kilku innych sygnatur. Sygnatury składowe można łączyć ze sobą warunkami logicznymi. Możliwe jest również ustawienie w odpowiedniej kolejności sygnatur składowych, tak aby jedynie odpowiednia sekwencja wykrytych ataków spowodowała odpowiednią reakcję.

Problem sygnatury uniwersalnej:

W przypadku ataków typu SQL Injection oraz Blind SQL Injection bardzo trudne, wręcz niemożliwe jest stworzenie uniwersalnej sygnatury. Tak naprawdę pojęcie uniwersalna sygnatura nie istnieje. Spowodowane jest to bardzo wieloma czynnikami.

Problem w stworzeniu uniwersalnej sygnatury spowodowany jest m.in.:

1. Możliwością używania różnego kodowania znaków w protokole HTTP,
2. Możliwością używania bardzo wielu wariantów zapytań SQL,
3. Dużym spadkiem wydajności systemów wykrywających włamania w przypadku bardzo rozbudowanych sygnatur,
4. Możliwością wystąpienia fałszywych alarmów w przypadku bardzo ogólnych sygnatur,
5. Wykorzystaniem bardzo dużej liczby wbudowanych funkcji w systemach bazodanowych
6. Powstawaniem coraz to nowszych funkcji oraz możliwości manipulacji danymi w systemach bazodanowych,
7. Wykorzystywaniem wielu różnych systemów bazodanowych, obsługujących aplikację webową,
8. Możliwością konstrukcji bardzo wielu wariantów warunków logicznych w zapytaniu SQL przez atakującego.

Zamiast próbować tworzyć uniwersalne sygnatury, które tak naprawdę będą w różnych przypadkach nieskuteczne, należy dążyć do wypracowania jak najlepszej metody zapobiegania włamaniom implementując wiele poziomów zabezpieczeń oraz dopasowując sygnatury do aplikacji, która ma być chroniona.

Pozostałe metody zabezpieczeń przed atakiem:

Oprócz systemów wykrywania włamań oraz zapobiegania włamaniom istnieje również kilka innych metod zabezpieczenia, przed atakami wstrzyknięcia kodu SQL.

Do takich zabezpieczeń należą:
Analiza kodu źródłowego i eliminacja popełnianych błędów,

Błędy typu SQL Injection najczęściej są popełniane przez programistów, którzy nie przywiązują większej uwagi do bezpieczeństwa swojej aplikacji, lub mają zbyt małą wiedzę z zakresu bezpieczeństwa aplikacji. Gdy aplikacja się rozrasta z upływem czasu, wiele zależności i znaczny poziom kodu utrudnia wykrycie i naprawę wcześniej popełnianych błędów. Dlatego należy zwracać uwagę od początku na aspekty bezpieczeństwa podczas tworzenia oprogramowania. Należy pamiętać o tym, żeby filtrować wszystkie dane jakie trafiają do skryptu. Można to robić na wiele sposobów, w zależności od tego jak wybierze programista.
Nie należy zapominać że dane trzeba filtrować nie tylko z formularzy ale z każdego miejsca z którego są one przetwarzane przez skrypt. Są to m.in. ukryte pola, dane przesyłane metodą get, post, poprzez ciasteczka i inne zasoby, które mogą być zmodyfikowane przed użytkownika. Powinno się jawnie zdefiniować miejsce pobieranych danych używając do tego tablic asocjacyjnych takich jak np.:

$_GET[], $_POST[], $_COOKIE[], $_REQUEST[].

Należy używać w skryptach takich typów danych, jakie maja zostać wykorzystane. Jeśli spodziewany jest typ numeryczny, należy zadbać o to aby jedynie taki typ był wykorzystany. Znacznie mocniejszym rozwiązaniem niż filtrowanie, jest odrzucanie nieprawidłowych wartości. Jeśli niespodziewana wartość trafi do skryptu, jeśli to jest możliwe należy taką wartość odrzucić, dopiero na drugim miejscu należy dane takie filtrować.

Firewalle aplikacyjne,

Oprócz systemów wykrywania włamań, istnieje możliwość zastosowania firewalla aplikacyjnego. Firewalle aplikacyjne używają logiki odwrotnej do logiki działania systemów wykrywania włamań. W przeciwieństwie do systemów IDS/IPS, firewalle blokują wszystko przepuszczając jedynie to, co jawnie zostało dozwolone. Systemy wykrywania włamań natomiast puszczają cały ruch, blokując tylko to co zawiera znamiona ataku.
Firewalle aplikacyjne mogą pracować, jako aplikacje lub moduły serwera WWW, lub być zewnętrznymi urządzeniami sieciowymi filtrującymi ruch HTTP. W przypadku serwera Apache, istnieje możliwość wykorzystania m.in. modułów mod_rewrite oraz mod_security.
Moduł mod_rewrite umożliwia przepisywanie adresów URL, co można wykorzystać do usuwania potencjalnie niebezpiecznych danych pochodzących od klienta. Moduł mod_security umożliwia wykonanie prostych operacji po przeanalizowaniu danych skierowanych do serwera HTTP. Umożliwia on m.in.: wysłanie użytkownikowi określonego statusu kodu, przekierowanie na inną stronę, zablokowanie dostępu do strony wykonanie odpowiedniego programu systemowego lub zalogowanie zdarzenia do logów.
Firewalle aplikacyjne pracujące, jako osobne urządzenia sieciowe posiadają bardzo duże możliwości reakcji na ataki w znacznym stopniu mogą podnieść poziom zabezpieczeń aplikacji webowej.

Procedury składowe systemu bazodanowego:

Należy używać procedur składowych, o ile to możliwe. Procedury składowe wywołują zapytania SQL, przyjmując jedynie sparametryzowane dane ze skryptu. Utrudnia to wyciek informacji poza bazą danych. Oczywiście należy stosować poprawne procedury składowe, ponieważ często panuje mit o bezwzględnym bezpieczeństwie procedur składowych. Źle napisana procedura składowa również może być wykorzystana w celu przeprowadzenia skutecznego ataku!

Hardening systemu bazodanowego,
Hardening systemu operacyjnego,
Hardening serwerów aplikacyjnych,
itd …

Podsumowanie

Bardzo skuteczną metodę ochrony mogą zapewnić jedynie kaskadowe zabezpieczenia, czyli łańcuch różnego rodzaju zabezpieczeń, które znacznie utrudniają wykonanie ataków. Ruch sieciowy skierowany do aplikacji powinien być stale monitorowany, należy również regularnie przeglądać logi pod kątem nieprawidłowości. Jeżeli aplikacja jest dostarczana przez zewnętrznego dostawcę, należy na bieżąco monitorować pojawiające się aktualizacje i aplikować je zaraz po ich ukazaniu się.
Okresowo powinny być dokonywane audyty aplikacji pod kątem bezpieczeństwa. Zarówno audyt kodu, jak i analiza podatności zainstalowanej aplikacji powinny wykazać ewentualne nieprawidłowości. Należy na bieżąco aktualizować serwery obsługujące aplikację, tak aby zminimalizować ryzyko ewentualnego włamania. Pojedyncze zabezpieczenie jest bardzo słabym rozwiązaniem, ponieważ jakakolwiek słabość takiego zabezpieczenia może doprowadzić do kompromitacji systemu.
Obrona przed atakami typu SQL Injection przy wykorzystaniu jedynie jednego zabezpieczenia jest niezwykle trudna. Nawet najlepszy system zabezpieczający może zostać oszukany, jak to zostało pokazane w niniejszej pracy. Dużym problemem w przypadku systemów bazujących na analizie sygnaturowej jest brak uniwersalnej sygnatury, która mogłaby wykrywać wszystkie odmiany ataków typu SQL Injection.
Reguły, które zbyt wąsko dopasowują wzorzec mogą nie wykrywać wszystkich ataków, a ich złożoność może doprowadzić do bardzo dużego spadku wydajności systemu wykrywania włamań, co nie jest dopuszczalne. Reguły zbyt ogólne generują z kolei bardzo dużo fałszywych alarmów. Problemem w wykrywaniu ataków typu SQL Injection jest również wiele funkcji systemów bazodanowych, umożliwiających potencjalny atak.
Żadna reguła nie jest w stanie dopasować wzorca wszystkich wbudowanych funkcji, tym bardziej, iż z każdą nowszą wersją systemu bazodanowego mogą pojawić się kolejne nowe funkcje. Również wiele systemów bazodanowych używa wiele własnych dialektów języka SQL, różniących się nieco między sobą, dlatego ciężko znaleźć wspólne wzorce dla zapytań stworzonych pod takie systemy.
W celu skutecznej obrony przed atakami typu SQL Injection należy wykorzystywać wiele zabezpieczeń równocześnie, które znacznie podnoszą skuteczność ochrony. Należy jednak pamiętać, że żaden, nawet najskuteczniejszy mechanizm nie jest w stanie zagwarantować stuprocentowego zabezpieczenia przed atakami.
Dobór odpowiedniego rozwiązania powinien być podyktowany wielkością chronionych zasobów. O ile niewielka aplikacja może zostać zabezpieczona poprzez analizę kodu źródłowego oraz funkcje parsujące dane i moduły serwera HTTP, to w przypadku bardzo dużych serwisów jest to wręcz niemożliwe. Również duże znaczenie ma koszt wdrożenia rozwiązania zabezpieczającego przed atakami. W przypadku niewielkich serwisów webowych koszt wdrożenia komercyjnych zabezpieczeń może przekroczyć wartość chronionych zasobów.