SQL INJECTION

Wykorzystanie błędów w językach skryptowych

Pomiędzy warstwą programistyczną a warstwą danych

Bezradne niskopoziomowe mechanizmy bezpieczeństwa

JSP, ASP, XML, XSL, XSQL, Perl, CGI, JavaScript, VB, narzędzia do obsługi baz danych, C, COBOL ...

Przykład 1

Skrypt w JSP połączony z Oracle

W polu formularza wczytywane sal

Konstruowane zapytanie (dla sal=800):

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

Przykład 1

W polu sal wpisujemy:

sal=800 UNION SELECT username, user_id from all_users

Uzyskujemy zapytanie:

SELECT ename, sal FROM scott.emp WHERE sal=800 UNION SELECT username, user_id from all_users

Zagrożenia

Dostęp do dowolnych danych w bazie

Możliwość modyfikacji i usunięcia danych

Atak wysokiego poziomu

Omija firewalle i zabezpieczenia na poziomie IP

Omija skanery antywirusowe i filtry treści

Nie istnieją sygnatury dla tego ataku

Przykład – zagrożenia Oracle

Można:

Dodać wyrażenie za pomocą UNION

Dodać podzapytania do istniejących

Uzyskać wszystkie dane z bazy

Uzyskać dostęp do zainstalowanych procedur i pakietów (np. pozwalających na zapisywanie i czytanie plików systemowych

Przykład – zagrożenia Oracle

Można:

Dodać instrukcje INSERT, UPDATE, DELETE

Dodać języki DDL (do definicji danych)

Dołączyć inną bazę danych

Nie są wykonalne:

Wielokrotne instrukcje

Odwołanie do bind variables

Przykład 2

LoginPage.php:

<HTML>

<BODY>

<FORM ACTION=LoginPage2.php>

Użytkownik: <INPUT NAME=”username”> <br>

Hasło: <INPUT NAME=”password”> <br>

<INPUT TYPE=”submit” VALUE=”Zaloguj”>

</FORM>

Przykład 2

LoginPage2.php:

...

function MyAuth( $conn,$username,$password) {

$query = ”SELECT id FROM users WHERE”;

$query .= ”username = '” . $username . ”'AND ”;

$query .= ”password = '” . $password . ”'”;

$res = pg_query( $query);

if (pg_num_rows( $res) == 1) {

$row = pg_fetch_array( $res);

$id = $row['id'];

}

else {

$id = 0;

}

}

Przykład 2

Tworzone zapytanie:

”SELECT id FROM users WHERE username = '” . $username . ”' AND password = '” . $password .”'”

. - operator konkatenacji

” - ograniczają poszczególne ciągi znaków

' - fragmenty danych wprowadzane przez użytkownika

Przykład 2

Złośliwe dane:

Użytkownik: 'delete from users--

Hasło:

Uzyskujemy zapytanie:

”SELECT id FROM users WHERE username = '” . '; delete from users--” . ”' AND password = '” . . ”'”;

Przykład 1

W efekcie uzyskujemy:

”SELECT id FROM users WHERE username = '” . '; delete from users--” . ”' AND password = '” . . ”'”;

' - zakończenie pojedynczego cudzysłowu

; - zakończenie zapytania i rozpoczęcie nowego

-- - początek komentarza

Przykład 1

Wygenerowane zapytanie:

SELECT id FROM users WHERE username = ''; delete from users

Zawartość tablicy users zostanie usunięta, uniemożliwiając innym dostęp do systemu

Można doklejać dowolne zapytania, o ile pozwala na to API i składnia bazy danych

Metody zapobiegania

Wszystkie dane z zewnątrz aplikacji powinny być filtrowane (przede wszystkim słowa kluczowe)

Stosowanie zasady najmniejszych przywilejów

Precyzyjne określenie funkcji dostępnych użytkownikowi za pośrednictwem interfejsu

Oddzielenie dostępu do bazy danych od interfejsu

Usuwanie zbędnych plików (*.bak)

Przykład 3

Im więcej intruz wie o strukturze bazy danych, tym większe prawdopodobieństwo skuteczności ataku

Podajemy:

Użytkownik: ' HAVING 1 = 1--

Uzyskujemy zapytanie:

SELECT id FROM users WHERE username = '' HAVING 1 = 1

Przykład 3

Zapytanie:

SELECT id FROM users WHERE username = '' HAVING 1 = 1

Jest poprawne składniowo, ale niepoprawne ze względu na strukturę danych.

Zwrócony komunikat:

Attribute users.id must be GROUPed or used in an aggregate function

Podsumowanie

Dane z zewnątrz aplikacji powinny być filtrowane

Przy nadawaniu uprawnień należy stosować zasadę najmniejszych przywilejów

Precyzyjne określenie funkcji dostępnych użytkownikowi za pośrednictwem interfejsu

W środowisku aplikacji nie powinno być żadnych zbędnych plików

Tematy pokrewne

HTML injection

Niedostateczne sprawdzanie danych wejściowych przez aplikacje sieciowe

Pozwala na zostawianie swoich pułapek na stronie, przechwytywanie danych

Second-order code injection

Dostarczenie aplikacji sieciowej potencjalnie niebezpiecznego kodu, który nie jest od razu wykonywany lecz przechowany

Przechowany kod (cache, baza danych) niebezpieczny przy wczytaniu i uruchomieniu przez ofiarę

Wojciech Sikora-Kobyliński

2005-01-18T17:48:30