pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 2
w
Zaawansowane metody manipulacji kodu SQL
1 Wstęp
da
.b
w
w
Streszczenie. Aplikacje internetowe zazwyczaj korzystają z warstwy danych,
którą prawie zawsze jest baza danych. Jednym z rodzajów ataków poprzez
aplikacje internetowe jest wstrzykiwanie przekazywanego przez aplikacje do
baz danych kodu SQL. W rozdziale omówiono zaawansowane warianty ataku metodą iniekcji kodu SQL, przedstawiono klasyfikację tego typu ataków,
wskazując jednocześnie możliwości uchronienia się przed manipulacjami
przekazywanego kodu SQL.
Rozdział poświęcony jest atakom poprzez wstrzykiwanie kodu SQL (ang. SQL injection),
nazywanymi też atakiem poprzez iniekcję kodu SQL, stanowiącym duże zagrożenie dla
systemów z bazami danych.
W rozdziale opisano, na czym polegają ataki poprzez wstrzykiwanie kodu SQL. Zamieszczono również krótką historię tych ataków.
Omówione zostały techniki używane w atakach techniką iniekcji kodu SQL oraz możliwości obrony.
W celu demonstracji wybranych metod iniekcji SQL posłużono się
PHP 5.2.5/MySQL 5.1 (pod Apache 2.0.58).
pl
s.
1.1 Przykładowe dane
Wygenerowana do celów demonstracyjnych tabela wygląda następująco:
mysql> DESCRIBE towary;
+-------+----------------------+------+-----+---------+-------+
| Field | Type
| Null | Key | Default | Extra |
+-------+----------------------+------+-----+---------+-------+
| id
| int(11)
| NO
| PRI | 0
|
|
| nazwa | varchar(40)
| YES |
| NULL
|
|
| data | date
| YES |
| NULL
|
|
| cena | float(12,2) unsigned | YES |
| NULL
|
|
+-------+----------------------+------+-----+---------+-------+
4 rows in set (0.00 sec)
Wprowadzone zostały dane:
Anna Kotulla
Politechnika Śląska, Instytut Informatyki, ul. Akademicka 16, 44-100 Gliwice, Polska
email:[email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
A. Kotulla
w
mysql> SELECT * FROM towary;
+----+-------------------+------------+---------+
| id | nazwa
| data
| cena
|
+----+-------------------+------------+---------+
| 1 | klawiatura
| 2007-12-05 |
48.95 |
| 2 | mysz
| 2008-01-05 |
19.99 |
| 3 | monitor 22"
| 2008-01-03 | 1512.50 |
| 4 | dysk twardy 500GB | 2007-12-03 | 888.00 |
| 5 | nagrywarka
| 2007-11-15 | 166.23 |
+----+-------------------+------------+---------+
w
2 Atak poprzez wstrzykiwanie kodu SQL
2.1 Historia ataków techniką iniekcji SQL
da
.b
w
Pierwsze informacje [4] na temat ataków poprzez wstrzykiwanie kodu SQL pojawiły się
w grudniu 1998 w 54 wydaniu czasopisma Phrack. Wówczas opisano ataki przeprowadzone na aplikacje IDC oraz ASP pod Microsoft Internet Information Server, bazą danych był
SQL Server 6.5. Wstrzykiwanie kodu SQL początkowo nazywane było m.in. SQL Insertion
(wstawianie kodu SQL) . Sam termin SQL Injection pojawił się pod koniec 1999 roku,
wprowadzony został prawdopodobnie przez Chipa Andrewsa w jego artykule „SQL
Injection FAQ”, opublikowanym na SQLSecurity.com.
2.2 Na czym polegają ataki techniką wstrzykiwania kodu SQL
pl
s.
Wstrzykiwanie kodu SQL [1], [2], [3], [4], [5], [6], [9], [11], jest metodą ataku na systemy
baz danych i polega na skłonieniu bazy danych do wykonania niepożądanego kodu SQL,
wprowadzonego poprzez rozszerzenie istniejących zapytań SQL o dodatkowe elementy.
Zmienione zapytania SQL wprowadzane są przez aplikacje, najczęściej internetowe, korzystające z bazy danych. Atak poprzez iniekcję kodu SQL jest możliwy, kiedy aplikacja
akceptuje wprowadzone przez użytkownika dane i wbudowuje je do zapytania SQL. Zapytanie to wysyłane jest do bazy danych i tam wykonywane.
Aby zilustrować atak poprzez iniekcję kodu SQL, załóżmy, że w bazie danych istnieje
tabela pracownicy, a jej kolumnami są m.in. nazwisko, imie, data_urodzenia,
data_zatrudnienia, natomiast intencją autora było zwrócenie wartości kolumny
data_zatrudnienia dla podanego imienia i nazwiska pracownika to dane wstawiane są
w odpowiednie pola formularza. Wówczas dane mogą być przekazywanie poprzez URL
postaci
http://chroniona_strona/przykladowy_skrypt.php?nazw=<podane_nazwisko>&
imie=<podane_imie>
Niech aplikacja zmienia to na zapytanie
SELECT data_zatrudnienia
FROM pracownicy
WHERE nazwisko=’podane_nazwisko’ AND imie=’podane_imie’
Jeżeli nie jest sprawdzane, jakiego typu dane zostają przekazywanie, atakujący może
próbować zmodyfikować zapytanie na przykład w taki sposób:
24
http://chroniona_strona/przykladowy_skrypt.php?nazw=<podane_nazwisko_r
azem_z_dodatkowym_kodem_SQL>&imie=<podane_imie>
W przypadku braku kontroli przekazywanych danych, zmodyfikowane może być również
zapytanie SQL skierowanie do bazy danych, w sposób przewidziany przez atakującego.
2.3 Przygotowanie ataku
w
da
.b
w
w
Przygotowanie ataku polega na określeniu tzw. wektora ataku [4], [7], czyli wykonanie
wstępnego rozpoznania, jak poważna jest luka. W ramach przygotowania przykładowo
obserwowana jest reakcja aplikacji na zmodyfikowane parametry wejściowe, podejmowane
są próby uzyskania komunikatów błędów bezpośrednio w aplikacji, czy przeglądarce.
W trakcie rekonesansu uzyskuje się wektor ataku. Otrzymywane mogą być informacje
o wykorzystanych w aplikacji zapytaniach SQL, stosowanych technikach zabezpieczających – np. sprawdzaniu wprowadzanych wartości. Bywa, że otrzymywane informacje pozwalają określić strukturę bazy danych.
W przypadku, kiedy aplikacja nie zwraca informacji o błędzie, stosowana jest technika
zwana ślepym wstrzykiwaniem kodu SQL [8], [9] (ang. blind SQL Injection) – ślepym
z powodu niedostatecznych dla atakującego informacji o błędzie. Bywa, że atakujący jednak i w takiej sytuacji potrafi stwierdzić czy zapytanie było wykonane, np. na podstawie
czasów odpowiedzi lub zwróconych różniących się komunikatów (np. informacji o błędzie
przygotowanych przez autora aplikacji). Dalsze informacje o tej groźnej technice znajdują
się w [8].
2.4 Rodzaje ataku SQL Injection – podział ze względu ukierunkowanie ataku na
elementy zapytania SQL
pl
s.
Biorąc pod uwagę, w jaki aspekt zapytania SQL skierowany jest atak [7], można dokonać
podziału na:
− ataki wymierzone na składnię zapytania,
− ataki ukierunkowane na składnię języka SQL,
− ataki na logikę zapytania,
Wymienione powyższe techniki ataku bywają łączone. Metody ataku, pogrupowane ze
względu na sposób dostępu, omówione są w podrozdzale 3.
2.5 Rodzaje ataku SQL Injection – podział ze względu na sposób dostępu
Innym możliwym podziałem jest zestawienie ze względu na sposób dostępu. Ataki SQL
Injection podzielone są na [6]:
− próbę dostępu przez stronę logowania, za pomocą:
− warunku OR,
− klauzuli HAVING,
− złożonych zapytań,
− użycia zewnętrznych procedur sterujących (ang. stored procedures),
− próbę dostępu poprzez URL, za pomocą:
− manipulowania składni zapytania bezpośrednio w URL,
− użycia wyrażeń SELECT wraz z UNION.
25
A. Kotulla
3 Metody ataku
w
Biorąc pod uwagę, w jaki aspekt zapytania SQL skierowany jest atak [7], można dokonać
podziału na:
− ataki wymierzone na składnię zapytania, polegające na wstawianiu znaków burzących składnię zapytania, co ma na celu wygenerowanie błędów, pomagających uzupełnić wektor ataku. Do tego celu stosowane bywają znaki specjalne, takie jak znaki
komentarza, cudzysłowy, apostrofy, średniki. Znaki podawane bywają również w postaci niebezpośredniej (aby ominąć filtry), np. CHAR(0x3B). 0x3B jest szesnastowym
oznaczeniem kodu ASCII dla średnika, czy częściej jeszcze stosowany kod apostrofu
CHAR(0x27).
− ataki ukierunkowane na składnię języka SQL. Celem jest wygenerowanie błędów
bazy danych lub wykonanie zapytań poprzez manipulację językiem SQL. Przykładowo do tej grupy ataków zalicza się wykonywanie własnych zapytań (typu SHOW
TABLES;) dołączonych do właściwego zapytania.
− ataki na logikę zapytania, polegające na takim zmodyfikowaniu kwerendy, aby otrzymać dane z tabel, których programiści nie mieli zamiaru udostępnić. Do tej grupy
zaliczają się ataki z wykorzystaniem operatora UNION.
w
w
da
.b
3. 1 Ataki na składnię zapytań
pl
s.
Podczas filtrowania danych wejściowych w skryptach PHP [7] możliwe są błędy, wynikające z niedostecznego filtrowania, kiedy np. szukany jest tylko znak apostrofu, a pominięte
są inne, potencjalnie niebezpieczne znaki, do których zaliczyć można [4] znaki spacji, <, >,
&, czy =. Uwzględnić należy, że znaki te mogą być zastąpione innymi wyrażeniami.
Przykładowo dla MySQL zamiast SELECT * FROM towary WHERE ID=4 używane może
być wyrażenie SELECT * FROM towary WHERE ID BETWEEN 4 AND 4.
Problem sprawiać mogą zbyt ostre kryteria filtrowania [7]. Można otrzymać błędnie
sformatowane zapytanie, jeżeli użyte będą funkcje:
− magic_quotes(), która automatycznie kasuje wszystkie apostrofy za wyjątkiem
znaku \,
− oraz strip_slashes(), usuwającą znaki kasowania,
Newralgicznym elementem zapytań są zmienne [7], szczególnie numeryczne, lub typu
DATE. Sprawdzane są szczególnie potencjalnie obiecujące kombinacje, do których przykładowo należą:
− liczby ujemne,
− sprawdzanie ślepe: duże lub małe liczby zmiennoprzecinkowe, np. 4.78326123e-421,
9.23343213e+308,
− sprawdzanie systematyczne: liczby mogące być poza zakresem, np. 28+n, 216+n,
232+n, 264+n (gdzie n oznacza jakąś liczbę całkowitą dodatnią). Inną możliwością są
znane ograniczenia liczb jakiegoś typu, na przykład jeżeli kolumnie w MySQL [11]
przypisane zostały dane typu FLOAT, wówczas dozwolonymi wartościami są:
− -3.402823466E+38 do -1.175494351E-38,
− 0,
− 1.175494351E-38 do 3.402823466E+38.
Dla języka PHP standardowo typem parametru dla wszystkich zmiennych jest łańcuch
znaków, co powodować może problemy w przypadku oczekiwanych wartości liczbowych,
czy typu DATE.
26
Zwracać uwagę należy również na niebezpieczne znaki przemycane za pomocą
rozbudowanych wyrażeń i przez to trudniejsze do znalezienia [7], np. cH%41r(0x68-0x41)
odpowiada CHAR(0x27).
3. 2 Ataki na składnię języka SQL
w
Język SQL [7], ze względu na swoje właściwości, jak przykładowo rozbudowane możliwości tworzenia składniowych odpowiedników zapytań, jest sam w sobie dosyć dobrym
celem ataku. Ataki tego typu bywają dobrym źródłem informacji pomagających rozbudować wektory ataku.
Najczęściej w pierwszym rzędzie podejmowane są próby manipulowania danych numerycznych [7]. Reakcja sprawdzana jest przykładowo techniką tzw. surowych parametrów.
Technika ta używa odpowiedników jakiejś liczby/wyrażenia, np. zamiast wyrażenia
numer=83 można próbować na miejsce 83 podstawiać takie wartości jak 0123 (liczba
przedstawiona ósemkowo), czy 0x53 (liczba przedstawiona szesnastkowo). Jeżeli uzyskane
od aplikacji odpowiedzi są identyczne, wskazuje to na przetwarzanie surowych wartości
parametrów.
Do ataków na składnię języka SQL zaliczyć można takie, które zastępują wymienione
już wcześniej znaki potencjalnie niebezpieczne, filtrowane przez aplikację, innymi [4].
da
.b
w
w
pl
s.
Rys. 1. Wynik zapytania SELECT id, nazwa, cena FROM towary WHERE id=4 or id=3
Przykładowo, niech fragment kodu w PHP pytający przykładową bazę danych ma postać:
<?php
$przekazany_parametr1 = "4";
$sql = "SELECT id, nazwa, cena FROM towary WHERE
id=$przekazany_parametr1" or id=$przekazany_parametr2";
$towary_query = mysql_query($sql) or die("Zapytanie nie moglo zostac
wykonane.");
$Liczba_linii = mysql_num_rows($towary_query);
echo "Zwrocono linii: $Liczba_linii";
?>
<table cellpadding="1" cellspacing="3" border="1">
<tr>
27
A. Kotulla
w
= mysql_fetch_array($towary_query)){
$towary['id']?></td>
$towary['nazwa']?></td>
$towary['cena']?></td>
w
<td>Id</td>
<td>Nazwa</td>
<td>Cena</td>
</tr>
<?php
while ($towary
?>
<tr>
<td><?php echo
<td><?php echo
<td><?php echo
</tr>
<?php
}
?>
</table>
w
W wyniku wykonania powyższego fragmentu kodu otrzymuje się wynik przedstawiony na
rys. 1.
Można próbować uzyskać ten sam wynik, podstawiając wyrażenie równoważne.
Np. w przypadku, kiedy filtrowane są spacje, a chce uzyskać się wyniki dla id=1, id=3,
id=4 można spróbować to zrobić w sposób następujący, otrzymując wynik przedstawiony
na rys. 2:
da
.b
$przekazany_parametr1 = "(4)or(id)=1";
pl
s.
Rys. 2. Wynik zapytania SELECT id, nazwa, cena FROM towary WHERE id=4 or id=1 or
id=3
Zagrożenie stanowią również znaki, które mogą przedwcześnie zakończyć zapytanie, jak
/* czy --. Przykładowo wynik zwrócony dla poniższego wyrażenia przedstawiono na rys. 3.
$przekazany_parametr1 = "4 /*";
28
w
w
w
Rys. 3. Wynik zapytania SELECT id, nazwa, cena FROM towary WHERE id=4/* or id=3
da
.b
Zabezpieczyć się przed atakami na składnię języka SQL można stosując przemyślany system filtrowania danych wejściowych, ograniczając długość wprowadzanych parametrów do
określonej liczby znaków, oraz koniecznie zamieniając zmienne łańcuchowe na liczby
w samej aplikacji, oraz blokując np. liczby postaci innej niż dziesiętna, jak 0x57.
3. 3 Ataki na logikę zapytania
Ataki przy użyciu UNION zademonstrowane zostaną na konkretnym przykładzie. Załóżmy,
że dla podanego przykładowego kodu PHP warunek WHERE otrzymuje wartość wprowadzoną przez użytkownika i przekazaną przez aplikację bez należytego filtrowania. Jest wiele potencjalnie interesujących danych, w przykładzie wyczytane zostaną po prostu dane
z innej tabeli, wynik przedstawiony jest na rys. 4.
pl
s.
$przekazany_parametr1="4";
$przekazany_parametr2="3 UNION SELECT nazwisko,1,data_urodzenia FROM
pracownicy";
id=$przekazany_parametr1 or id=$przekazany_parametr2";
Wartość 1 wprowadzono celowo, demonstrując, jak radzić sobie można w przypadku, kiedy właściwe zapytanie zwraca więcej kolumn, niż uzyskane ma być poprzez zmanipulowany kod. W odwrotnym przypadku używane jest CONCAT().
Atakujący może czasem otrzymać wystarczające informacje o sposobie wykonywania
zapytania po prostu podglądając kod strony.
Obrona przed takiego typu atakami możliwa jest poprzez używanie zapisanych procedur
(oddzielających dane od logiki zapytań) oraz wykorzystywanie spreparowanych wyrażeń.
29
A. Kotulla
w
da
.b
w
w
Rys. 4. Wynik zapytania SELECT id, nazwa, cena FROM towary WHERE id=4 or id=3
UNION SELECT nazwisko,1,data_urodzenia FROM pracownicy
3. 4 Ataki na strukturę bazy danych
mysql> SHOW DATABASES;
+--------------------+
| Database
|
+--------------------+
| information_schema |
| mysql
|
| przyklad
|
| test
|
+--------------------+
pl
s.
Ataki na strukturę bazy danych celowo wymieniono w osobnym podpunkcie. Zidentyfikowanie, jaki system baz danych jest atakowany, jest dla atakującego cennym uzupełnieniem
wektora ataku, ponieważ systemy baz danych różnią się pomiędzy sobą strukturą – np.
standardowymi tabelami, użytkownikami, perspektywami.
Przed zdobyciem informacji na temat baz danych warto się dodatkowo zabezpieczyć,
filtrując wprowadzone wartości na obecność „typowych” zapytań, przedstawionych poniżej
wraz z przykładowymi odpowiedziami:
30
mysql> SHOW TABLES;
+--------------------+
| Tables_in_przyklad |
+--------------------+
| pracownicy
|
| towary
|
+--------------------+
w
w
mysql> EXPLAIN towary;
+-------+----------------------+------+-----+---------+-------+
| Field | Type
| Null | Key | Default | Extra |
+-------+----------------------+------+-----+---------+-------+
| id
| int(11)
| NO
| PRI | 0
|
|
| nazwa | varchar(40)
| YES |
| NULL
|
|
| data | date
| YES |
| NULL
|
|
| cena | float(12,2) unsigned | YES |
| NULL
|
|
+-------+----------------------+------+-----+---------+-------+
da
.b
w
mysql> SELECT CURTIME();
+-----------+
| CURTIME() |
+-----------+
| 19:55:30 |
+-----------+
1 row in set (0.06 sec)
Składnie dla innych systemów baz danych oraz kompletne listy takich poleceń znaleźć
można np. w dokumentacji bazy danej.
4 Podsumowanie
pl
s.
Ataki SQL Injection w pierwszym rzędzie nie są skierowane przeciwko konkretnej bazie
danych, tylko wykorzystują język SQL, który stosowany jest do zapytań w różnych bazach
danych. Poznanie sposobu atakowania przez iniekcję kodu SQL i używanych coraz to nowych technik jest potrzebne, gdyż umożliwia skuteczną ochronę przed takimi atakami.
Z biegiem czasu nie tylko sposoby ataku stają się coraz bardziej skomplikowane, również metody ochrony są coraz bardziej kompleksowe i łatwiejsze do stosowania. Istnieją
przykładowo słowniki potencjalnie niebezpiecznych wyrażeń, do których zaliczyć można
przytoczone wcześniej cH%41r(0x68-0x41).
Trudno jest oszacować, jaka liczba aplikacji internetowych kierujących zapytania do baz
danych jest podatna na wstrzykiwanie kodu SQL. Sam jednak rozwój ataków tą techniką
pokazuje, że nie jest to problem marginalny. Litchfield [4] podaje, że w latach 2003/2004
ok. 60% testowanych poprzez Next Generation Security Software Ltd aplikacji było podatnych na wstrzykiwanie kodu SQL.
Metody używane do atakowania aplikacji za pomocą iniekcji kodu SQL mogą również
okazać się przydatne do zupełnie innych celów – na przykład do testowania aplikacji, przykładem jest tu ślepe wstrzykiwanie kodu SQL [9].
31
A. Kotulla
Literatura
1.
w
Anley Ch.: Advanced SQL Injection In SQL Server Applications. An NGSSoftware Insight
Security Research (NISR) Publication. Next Generation Security Software Ltd 2002.
2. Anley Ch.: (more) Advanced SQL Injection. An NGSSoftware Insight Security Research (NISR)
Publication. Next Generation Security Software Ltd 2002.
3. Kost S.: An Introduction to SQL Injection Attacks for Oracle Developers. Integrity Corporation.
Chicago 2004.
4. Litchfield D.: Data-mining with SQL Injection and Interference. An NGSSoftware Insight
Security Research (NISR) Publication. Next Generation Security Software Ltd 2005.
5. Litchfield D., Anley Ch., Haesman J., Grindlay B.: The Database Hacker’s Handbook,
Defending Database Servers. Wiley Publishing, Inc., Indianapolis 2005.
6. Sharma P.: SQL Injection Techniques & Countermeasures. Department of Information
Technology, Ministry of Communications and Information Technology, Government of India,
2005.
7. Shema M.: Zaawansowane ataki SQL Injection. Hakin9 Nr5/2005.
8. Spett K.: Blind SQL Injection. Are you web applications vulnerable? SPI Dynamics, Inc. 2005.
9. Stender S. T.: Blind Security Testing – An Evolutionary Approach. iSEC Partners, Inc. 2007.
10. Strobel S.: Tückische Eingaben. Angriffsmöglichkeiten auf Webapplikationen und
Abwehrtechniken. iX Extra 11/2007.
11. MySQL 5.1 Reference Manual.
da
.b
w
w
pl
s.
32

pobierz plik referatu

Transkrypt

Podobne dokumenty

Programista aplikacji biznesowych VB/C# .NET

NET Developer

Customer support / helpdesk

Programista SQL, PL/SQL, PHP - Polisa

02-scenariusz-projek..

Inżynier Systemowy IT

PL/SQL - Imperium Szkoleniowe