Bezpieczeństwo web (część 6) – SQL Injection III, obchodzenie filtrów

W poprzednich postach opisałem ogólną zasadę działania SQL Injection. Niestety część programistów, próbując zapobiec atakowi, pisze własne filtry mające na celu usunięcie spreparowanego zapytania. Niestety w większości przypadków jest to bardzo zły i niebezpieczny pomysł. Dzisiaj przedstawię kilka sposobów na ominięcie typowych zabezpieczeń i filtrów stosowanych przez część programistów. Prawidłowe wykonanie zapytania polega na parametryzacji wszystkich dynamicznych części zapytania. Dzisiejszy wpis ma na celu pokazanie, jak bardzo skomplikowane jest zadanie napisania prawidłowych filtrów, działających we wszystkich sytuacjach.

1. Blokowanie komentarzy

Wcześniej wstrzykiwaliśmy kod za pomocą wykomentowania reszty zapytania tzn.

' or 1=1 --

W rezultacie tworzyło to:

SELECT * from Articles where Text='test' or 1=1 --'

Istnieje inny sposób, jeśli filtry usuwają wszelkie komentarze np.:

' or 'a'='a

W rezultacie da to:

SELECT * from Articles where Text='test' or 'a'='a'

2. Blokowanie spacji
Niektóre, bardzo proste filtry usuwają spacje np. jeśli przekażemy ‘ or 1=1–, otrzymamy ‘or1=1– co oczywiście jest błędną składnią. Podobnie SELECT * FROM table zostanie zamieniony na SELECT*FROMTABLE. Sztuczka wtedy polega na wstrzyknięciu komentarzy zamiast spacji, czyli:

SELECT/*Cokolwiek/*COL1/*COKOLWIEK*/FROM/*COKOLWIEK*/table

3. Blokowanie słów kluczowych
Niektóre systemy IDS (Intrusion detection system) blokują konkretne słowa kluczowe jak np. SELECT. Wtedy można użyć kodowania URI i zamiast SELECT spróbować można:
– %00SELECT
– %53%45%4c%45%43%54 (pojedyncze kodowanie)
– %2553%2545%254c%2545%2543%2554 (podwójne kodowanie)
4. Kodowanie apostrof
Naturalnie, filtry próbują pozbyć się apostrof, np. jeśli przekazujemy ‘ or 1=1– może zostać zamienione to na ” or 1=1–.
Na pierwszy rzut oka kod wydaje się bezpieczny. Apostrof zostanie uznany za zwykły tekst. Niestety, np. w MySQL istnieją dwa sposoby kodowania znaków. Pierwszy z nich widzimy wyżej – za pomocą dodania kolejnego apostrofa (‘->”). Drugi sposób to użycie slasha (‘ -> \’).
Jeśli zatem wstrzykniemy \’ or 1=1–, po filtrowaniu uzyskamy \” or 1 =1. Pierwszy apostrof zostanie uznany za tekst, a drugi zamknie frazę, umożliwiając przeprowadzenie ataku.
5. Wprowadzenie tekstu bez użycia apostrof
Inny sposób to wstrzyknięcie tekstu za pomocą ASCI. Na przykład zamiast:

SELECT * FROM Persons where name='piotr'

Możemy:

SELECT * FROM Persons where name=char(80)||char(73)||char(79)||char(84)||char(82)

6. Składnia
Co prawda jest to bardzo naiwne podejście, ale warto sprawdzić czy “SELECT” jest interpretowany tak samo jak np. “SeLeCT”. Większość skanerów, próbuje wstrzyknąć ten sam kod za pomocą małych i wielkich liter.
7. Zakończenie NULL byte
Część systemów IDS\WAF jest zaimplementowana w językach niezarządzanych takich jak CPP. String inaczej jest interpretowany w CPP niż w C#. W CPP \null kończy dany strumień znaków. W C#, istnieje osobne pole określające długość strumienia znaków (napisu).
W praktyce oznacza to, że “ABC\nullDEF” w CPP sprowadzi się do “ABC”, z kolei w C# będzie to oczywiście “ABC\nullDEF”.Innymi słowy, można tak przygotować zapytanie, że zostanie one przepuszczone przez IDS\WAF, a zarządzany kod (ASP.NET) wykona złośliwy kod.

Leave a Reply

Your email address will not be published.