Uszczelnianie bazy

Zapytanie SQL jest wykonywane z uprawnieniami wskazanymi przez programistę w skrypcie wykonującym połączenie do bazy. Bezpieczeństwo aplikacji WWW zależy więc głównie od tego, jak precyzyjnie uprawnienia te zostaną określone. Nie ulega wątpliwości, że powinny one być możliwie jak najmniejsze, a w każdym razie nie większe niż jest to niezbędne do wykonania działań przewidzianych przez projektanta aplikacji. Dotyczy to w szczególności uprawnień do wykonywania procedur składowanych oraz uprawnień do modyfikowania danych. Niestety, ingerencja administratora w zakres uprawnień nadanych użytkownikowi przez programistę nie zawsze jest możliwa. Nawet wtedy jednak nie zapobiega to atakowi, lecz jedynie ogranicza jego skutki.

Z punktu widzenia protokołu HTTP atak SQL injection nie różni się niczym od standardowego odwołania do serwera HTTP. W swojej istocie atak polega bowiem na doklejeniu zapytania SQL do jednego bądź kilku parametrów przekazywanych w metodzie GET lub POST. Oto przykład, wykorzystujący skrypt demonstracyjny standardowej wersji bazy Oracle:

serwer_oracle/demo/sql/tag/sample2.jsp?cond=sal%3D800+union+select+username%2C+user_id+from+all_users

Oczywiście może to dotyczyć każdego innego środowiska:

serwer.gdzies.tam/sklep/pokaz_cennik.jsp?produkt=mlotek%20union%20select%20username%2C%20user_id%20from%20all_users

Znak "%20" - to zakodowany w formacie UNICODE znak spacji, a "%2C" - znak przecinka.

Ponieważ celem włamywacza jest, najogólniej, doklejenie swojego zapytania SQL do zapytania standardowego, dobrym sposobem ochrony jest filtrowanie zleceń płynących do serwera WWW pod kątem słów kluczowych. Najczęściej są to:

SELECT, DELETE, INSERT, UPDATE

UNION SELECT

OR 1=1

OR A=A

-- znak komentarza

' pojedynczy cudzysłów

%00 znacznik końca ciągu znaków

Powyższe "słowa kluczowe" mogą również oznaczać normalną aktywność użytkownika. Przykładowo, "Update Magic" czy "Selector" mogą być nazwami produktów. Aby uniknąć fałszywych alarmów, konstrukcja filtrów musi być bardzo precyzyjna. O ile to możliwe, zamiast pojedynczych słów kluczowych, należy używać całych wyrażeń, np. SELECT * FROM * w miejsce SELECT. Filtrowanie można wykonywać w różnych miejscach, np. na zaawansowanym systemie zaporowym lub na serwerze WWW .

Pierwsza linia obrony

Typowy firewall przepuszcza bądź odrzuca pakiety na podstawie danych z nagłówków warstwy: 3 (np. IP, ICMP) i 4 (np. TCP, UDP). Nas interesuje jednak rozwiązanie, które umożliwia analizę zawartości sesji HTTP, a więc mające możliwość działania w wyższych warstwach modelu OSI.

Przykładem takiego systemu jest oprogramowanie Check Point Firewall-1, a konkretnie jeden z jego modułów - HTTP Security Server, pozwalający na prostą analizę ruchu HTTP pod względem zawartości URI. Aby stworzyć odpowiednią regułę, należy najpierw zdefiniować zasób - w tym przypadku jest to opis ataku. Z poziomu Check Point Policy Editor należy wykonać następujący ciąg poleceń: Manage -> Resources -> New -> URI.

W pole Name należy wpisać nazwę definiowanego zasobu - np. Atak SQL injection, zaś w polu URI Match Specification Type trzeba zaznaczyć opcję Wild Cards. W zakładce Match mamy możliwość zdefiniowania szczegółów tworzonego zasobu. W tym miejscu należy jak najdokładniej opisać atak SQL injection, który chcemy zablokować: Schemes: HTTP, Methods: GET, POST, Query: *SELECT*FROM*. Ponadto w zakładce Action w polu Replacement URI można zdefiniować stronę, na którą będzie przekierowany intruz. Istnieje również możliwość importowania wyrażeń z pliku. Regułę blokującą zdefiniowany przed chwilą zasób o nazwie SQL injection dodajemy tak, jak każdą inną regułę filtrowania, z tym że w polu Service, po kliknięciu prawym klawiszem myszy wybieramy opcję Add with resource. Następnie wybieramy usługę HTTP, a w polu Resource - zdefiniowany wcześniej zasób Atak SQL injection.

W Internecie
  • http://ngsec.com/ngproducts/ngsw/

  • http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=2&tabid=3

  • http://online.securityfocus.com/infocus/1646

  • http://www.owasp.org/codeseeker

TOP 200