Zastrzyk prosto w serce

Atakom typu SQL injection nie zapobiegną ani wielowarstwowe systemy zaporowe, ani nawet systemy wykrywania włamań.

Atakom typu SQL injection nie zapobiegną ani wielowarstwowe systemy zaporowe, ani nawet systemy wykrywania włamań.

Walka o bezpieczeństwo systemów informatycznych toczy się obecnie na wielu frontach. Sieć trzeba zabezpieczyć przed włamaniem - zarówno z zewnątrz jak i od wewnątrz, serwer pocztowy przed infekcją wirusową, serwer WWW przed modyfikacją publikowanej treści. Firmy, które zgodnie z regułami sztuki wdrożą skaner antywirusowy, kilka systemów zaporowych i system wykrywania włamań, mogą sądzić, że ich zasoby są bezpieczne. Niestety, istnieją zagrożenia, dla których wszystkie te zabezpieczenia nie stanowią żadnej przeszkody. Chodzi o ataki typu SQL injection - dosł. wstrzykiwanie kodu SQL. Metoda ta może zostać wykorzystana np. do wykradania istotnych informacji z serwisów internetowych, np. numerów kart kredytowych.

Przez ogień i zasieki

Atak typu SQL injection polega na takiej manipulacji aplikacją komunikującą się z bazą danych, aby ta umożliwiła atakującemu uzyskanie dostępu lub modyfikację danych, do których nie posiada on uprawnień. W praktyce polega to na wykorzystaniu interfejsu użytkownika (adresu URL, formularza HTML/XML, okna dialogowego itp.) do wprowadzenia do aplikacji spreparowanego ciągu znaków. W zależności od architektury aplikacji, może to być gotowe wyrażenie SQL, ale nie tylko. Może to być również sekwencja komend specyficznego dla danej bazy/platformy języka DML - Data Manipulation Language lub odwołanie do procedury składowanej, która samoczynnie utworzy właściwe wyrażenie SQL. Zagrożenie atakami typu SQL injection dotyczy przede wszystkim aplikacji internetowych z racji relatywnie łatwego dostępu do nich, jednak technikę tę można z powodzeniem zastosować do atakowania aplikacji typu klient, serwer.

Dlaczego ataki typu SQL injection są tak groźne? Po pierwsze, dlatego że większość programistów zwyczajnie nie zdaje sobie sprawy z ich istnienia. Ci zaś, którzy o nich słyszeli, nie są skłonni sądzić, że tworzone przez nich systemy są na nie podatne. Po drugie, ataki typu SQL injection to ataki wysokiego poziomu. Oznacza to, że zabezpieczenia działające na poziomie sieci IP np. systemy zaporowe (firewall) są wobec nich bezradne - mówiąc wprost - w ogóle ich nie zauważają. Wobec ataków SQL injection bezsilne są nawet systemy wykrywania włamań

W walce z atakami typu SQL injection bezużyteczne okazują się także, działające w wyższych warstwach, skanery antywirusowe oraz filtry treści wykorzystujące bazy sygnatur. Problem polega tu na tym, że ataki te nie wykorzystują znanych błędów w oprogramowaniu, dla których istnieją sygnatury, np. serwerach WWW czy serwerach baz danych, lecz błędy popełnione przez projektantów i programistów tworzących przy ich pomocy konkretne rozwiązania, np. internetowa aplikacja do obsługi zamówień w konkretnej firmie.

Przykład 1

Pozyskiwanie danych

Filozofię ataku SQL injection można prosto zilustrować atakując dostępny pod adresem: nasz_serwer/demo/sql/tag/sample2.jsp . demonstracyjny skrypt Java Server Pages (JSP) dostarczany wraz z bazą Oracle 9i. Skrypt pobiera od użytkownika dane poprzez prosty formularz, składający się z jednego pola tekstowego. Jeżeli w polu formularza wpiszemy: sal=800, jako wynik otrzymamy listę pracowników, których wynagrodzenie (pole SAL) wynosi 800. Oczywiście, rezultaty są generowane przez odpowiednie zapytanie SQL wykonywane bezpośrednio na bazie danych. To, co użytkownik wpisuje za pośrednictwem formularza WWW, jest jedynie "doklejane" do już zdefiniowanej formuły. Jeżeli więc w formularzu użytkownik wpisze "sal=800" to skrypt skonstruuje zapytanie:

SELECT ename, sal FROM scott.emp WHERE sal=800

Zapytanie SQL jest tworzone za pomocą konkatenacji dwóch ciągów znaków - jeden jest zapisany na stałe w skrypcie, zaś drugi pobierany jest od użytkownika. Być może użytkownik jest w stanie wpisywać w formularzu dowolne ciągi znaków. Sprawdźmy. W polu formularza wpisujemy poniższy ciąg znaków:

sal=800 union select username, user_id from all_users

W wyniku działania skryptu JSP, polegającego na sklejeniu dwóch ciągów znaków, w bazie zostanie wykonane następujące polecenie:

SELECT ename, sal FROM scott.emp WHERE sal=800

UNION SELECT username, user_id FROM all_users

W ten sposób, użytkownik (intruz) uzyskuje dostęp do widoku all_users, na co twórca interfejsu nie zezwolił bezpośrednio. Jego błąd polegał jednak na tym, że nie ograniczył tego przywileju.

Do doklejenia drugiej części wyrażenia SQL został w tym wypadku użyty specyficzny dla baz Oracle mechanizm UNION SELECT, jednak w przypadku innych baz, atak może być o wiele prostszy. Przykładowo, serwery baz danych: SQL Server, PostgreSQL i popularny w serwisach WWW MySQL umożliwiają wykonanie kilku zapytań SQL w jednej linii, oddzielonych od siebie średnikami. Dodając średnik, można więc dodać do oryginalnego zapytania dowolne zapytanie własnej konstrukcji, a przy tym, w przeciwieństwie do mechanizmu UNION SELECT, nie trzeba nawet dbać o zgodność typów danych z zapytaniami poprzedzającymi.

Powyższy przykład jest bardzo prosty, świetnie ilustruje jednak istotę ataku typu SQL injection: wykorzystanie możliwości dopisania swojego zapytania SQL do zapytania przewidzianego przez interfejs dostępu do danych. Do uzyskania podobnej funkcjonalności w praktyce nie stosuje się skryptów, lecz odwołania do nie znanych intruzowi składowanych procedur i to one generują ostateczną formę wyrażenia SQL. Istnieją jednak metody, by i ten problem ominąć.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200