Samouczek dotyczący testowania SQL Injection (przykład i zapobieganie atakowi SQL Injection Attack)

sql injection testing tutorial example

Przykłady iniekcji SQL i sposoby zapobiegania atakom typu SQL Injection na aplikacje internetowe

Podczas testowania strony internetowej lub systemu celem testera jest zapewnienie, że testowany produkt jest tak dobrze chroniony, jak to tylko możliwe.

W tym celu zwykle przeprowadza się testy bezpieczeństwa. Aby przeprowadzić tego typu testy, najpierw musimy rozważyć, które ataki są najbardziej prawdopodobne. SQL Injection jest jednym z takich ataków.

SQL Injection jest uważany za jeden z najczęstszych ataków, ponieważ może przynieść poważne i szkodliwe konsekwencje dla systemu i poufnych danych.

Czego się nauczysz:

• Co to jest iniekcja SQL?
• Ryzyko wstrzyknięcia SQL
• Istota tego ataku
• Zalecane narzędzie
  • 1) Kiuwan
• Testowanie bezpieczeństwa aplikacji internetowych pod kątem iniekcji SQL
• Wrażliwe części tego ataku
• Automatyzacja testów iniekcji SQL
• Porównanie z innymi atakami
• Wniosek
• rekomendowane lektury

Co to jest iniekcja SQL?

Niektóre dane wejściowe użytkownika mogą zostać użyte w ramkach Instrukcje SQL które są następnie wykonywane przez aplikację w bazie danych. Aplikacja może NIE obsługiwać poprawnie danych wejściowych podanych przez użytkownika.

Jeżeli o to chodzi, złośliwy użytkownik może wprowadzić nieoczekiwane dane wejściowe do aplikacji, które są następnie wykorzystywane do tworzenia ramek i wykonywania instrukcji SQL w bazie danych. Nazywa się to wstrzyknięciem SQL. Konsekwencje takiego działania mogą być niepokojące.

Jak sama nazwa wskazuje, celem ataku SQL Injection jest wstrzyknięcie złośliwego kodu SQL.

Każde pole witryny internetowej jest jak brama do bazy danych. W formularzu logowania użytkownik wpisuje dane logowania, w polu wyszukiwania wpisuje szukany tekst, w formularzu zapisu danych wpisuje dane do zapisania. Wszystkie te wskazane dane trafiają do bazy danych.

Zamiast poprawnych danych, jeśli wprowadzony zostanie jakikolwiek szkodliwy kod, to istnieje możliwość poważnego uszkodzenia bazy danych i całego systemu.

SQL Injection jest wykonywany w języku programowania SQL. SQL (Structured Query Language) służy do zarządzania danymi przechowywanymi w bazie danych. Dlatego podczas tego ataku ten kod języka programowania jest wykorzystywany jako złośliwy zastrzyk.

Jest to jeden z najpopularniejszych ataków, ponieważ prawie wszystkie technologie wykorzystują bazy danych.

Wiele aplikacji korzysta z pewnego typu bazy danych. Testowana aplikacja może mieć interfejs użytkownika, który akceptuje dane wejściowe użytkownika, który jest używany do wykonywania następujących zadań:

# 1) Pokaż odpowiednie zapisane dane użytkownikowi, np. aplikacja sprawdza dane uwierzytelniające użytkownika za pomocą danych logowania wprowadzonych przez użytkownika i udostępnia użytkownikowi tylko odpowiednią funkcjonalność i dane

#dwa) Zapisz wprowadzone przez użytkownika dane do bazy danych np. po wypełnieniu przez użytkownika formularza i wysłaniu go aplikacja przechodzi do zapisania danych do bazy danych; dane te są następnie udostępniane użytkownikowi w tej samej sesji, jak również w kolejnych sesjach

Ryzyko wstrzyknięcia SQL

W dzisiejszych czasach baza danych jest używana dla prawie wszystkich systemów i stron internetowych, ponieważ dane powinny być gdzieś przechowywane.

Ponieważ w bazie danych przechowywane są dane wrażliwe, bezpieczeństwo systemu wiąże się z większym ryzykiem. Jeśli jakakolwiek prywatna witryna lub dane bloga zostałyby skradzione, nie byłoby dużych szkód w porównaniu z danymi, które zostałyby skradzione z systemu bankowego.

Głównym celem tego ataku jest włamanie do bazy danych systemu, dlatego konsekwencje tego ataku mogą być naprawdę szkodliwe.

Następujące rzeczy mogą wynikać z wstrzyknięcia SQL

• Włamanie się na konto innej osoby.
• Kradzież i kopiowanie wrażliwych danych z witryny lub systemu.
• Zmiana poufnych danych systemu.
• Usuwanie poufnych danych z systemu.
• Użytkownik może zalogować się do aplikacji jako inny użytkownik, nawet jako administrator.
• Użytkownik może przeglądać prywatne informacje należące do innych użytkowników, np. szczegóły profili innych użytkowników, szczegóły transakcji itp.
• Użytkownik może zmieniać informacje o konfiguracji aplikacji i dane innych użytkowników.
• Użytkownik może modyfikować strukturę bazy danych; nawet usuwać tabele w bazie danych aplikacji.
• Użytkownik mógł przejąć kontrolę nad serwerem bazy danych i dowolnie wykonywać na nim polecenia.

Wymienione powyżej zagrożenia można naprawdę uznać za poważne, ponieważ przywrócenie bazy danych lub jej danych może dużo kosztować. Przywrócenie utraconych danych i systemu może kosztować Twoją firmę reputację i pieniądze. Dlatego zdecydowanie zaleca się ochronę systemu przed tego typu atakami i uznanie testów bezpieczeństwa za dobrą inwestycję w reputację produktu i firmy.

Jako tester chciałbym skomentować, że testowanie pod kątem możliwych ataków jest dobrą praktyką, nawet jeśli Testowanie bezpieczeństwa nie było zaplanowane. W ten sposób możesz chronić i testować produkt przed nieoczekiwanymi przypadkami i złośliwymi użytkownikami.

Istota tego ataku

Jak wspomniano wcześniej, istotą tego ataku jest włamanie się do bazy danych w złośliwym celu.

Aby przeprowadzić te testy bezpieczeństwa, należy najpierw znaleźć podatne na ataki części systemu, a następnie wysłać za ich pośrednictwem złośliwy kod SQL do bazy danych. Jeśli taki atak jest możliwy dla systemu, zostanie wysłany odpowiedni złośliwy kod SQL i mogą zostać wykonane szkodliwe działania w bazie danych.

Każde pole witryny internetowej jest jak brama do bazy danych. Wszelkie dane lub dane wejściowe, które zwykle wprowadzamy w dowolnym polu systemu lub strony internetowej, trafiają do zapytania do bazy danych. Dlatego zamiast poprawnych danych, jeśli wpiszemy jakiś złośliwy kod, to może on zostać uruchomiony w zapytaniu do bazy danych i przynieść szkodliwe konsekwencje.

Zalecane narzędzie

1) Kiuwan

Z łatwością znajduj i naprawiaj luki w zabezpieczeniach, takie jak wstrzyknięcie SQL w kodzie na każdym etapie SDLC. Kiuwan jest zgodny z najbardziej rygorystycznymi standardami bezpieczeństwa, w tym OWASP, CWE, SANS 25, HIPPA i nie tylko.

Zintegruj Kiuwan ze swoim IDE, aby uzyskać natychmiastową informację zwrotną podczas programowania. Kiuwan obsługuje wszystkie główne języki programowania i integruje się z wiodącymi narzędziami DevOps.

=> Zeskanuj swój kod za darmo

Aby wykonać ten atak, musimy zmienić działanie i cel odpowiedniego zapytania do bazy danych. Jedną z możliwych metod jest ustawienie zapytania zawsze prawdziwego, a następnie wstawienie złośliwego kodu. Zmianę zapytania bazy danych na zawsze prawdziwe można przeprowadzić za pomocą prostego kodu, takiego jak „lub 1 = 1; -.

Testerzy powinni pamiętać, że sprawdzając, czy można zmienić zapytanie na zawsze prawdziwe, czy nie, należy wypróbować różne cudzysłowy - pojedyncze i podwójne. Dlatego, jeśli wypróbowaliśmy kod taki jak „lub 1 = 1; -, powinniśmy również wypróbować kod z podwójnymi cudzysłowami” lub 1 = 1; -.

Na przykład, rozważmy, że mamy zapytanie, czyli wyszukanie wpisanego słowa w tabeli bazy danych:

wybierz * z notatek nt, gdzie nt.subject = ‘search_word’;

Dlatego zamiast wyszukiwanego słowa, jeśli wprowadzimy zapytanie SQL Injection „lub 1 = 1; -, wówczas zapytanie będzie zawsze prawdziwe.

wybierz * z notatek nt, gdzie nt.subject = ‘’ lub 1 = 1; -

W tym przypadku parametr „subject” jest zamykany cudzysłowem, a następnie mamy kod lub 1 = 1, co sprawia, że ​​zapytanie jest zawsze prawdziwe. Znakiem „-” komentujemy pozostałą część kodu zapytania, która nie zostanie wykonana. Jest to jeden z najpopularniejszych i najłatwiejszych sposobów na rozpoczęcie kontroli zapytania.

Można również użyć kilku innych kodów, aby zapytanie było zawsze prawdziwe, na przykład:

• „Lub„ abc ”=„ abc ”; -
• „Lub„ „=„ ”; -

Najważniejsze jest to, że po znaku przecinka możemy wprowadzić dowolny złośliwy kod, który chcielibyśmy wykonać.

Na przykład, może wynosić „lub 1 = 1; upuść notatki do tabeli; -

Jeśli to wstrzyknięcie jest możliwe, może zostać napisany inny złośliwy kod. W tym przypadku będzie to zależeć tylko od wiedzy i intencji złośliwego użytkownika. Jak sprawdzić iniekcję SQL?

Sprawdzanie tej luki można wykonać bardzo łatwo. Czasami wystarczy wpisać „lub” w testowanych polach. Jeśli zwróci jakiś nieoczekiwany lub niezwykły komunikat, możemy być pewni, że SQL Injection jest możliwy dla tego pola.

Na przykład , Jeśli jako wynik wyszukiwania pojawi się komunikat o błędzie, taki jak „Wewnętrzny błąd serwera”, możemy być pewni, że ten atak jest możliwy w tej części systemu.

Inne wyniki, które mogą powiadomić o możliwym ataku, obejmują:

• Załadowano pustą stronę.
• Brak komunikatów o błędach lub powodzeniu - funkcjonalność i strona nie reagują na wprowadzone dane.
• Komunikat o powodzeniu dotyczący złośliwego kodu.

Przyjrzyjmy się, jak to działa w praktyce.

Na przykład, Sprawdźmy, czy odpowiednie okno logowania jest podatne na wstrzyknięcie SQL. W tym celu w polu adresu e-mail lub hasła wpisujemy tylko znak, jak pokazano poniżej.

Jeśli takie dane wejściowe zwracają wynik, taki jak komunikat o błędzie „Wewnętrzny błąd serwera” lub inny wymieniony niewłaściwy wynik, możemy być prawie pewni, że ten atak jest możliwy dla tego pola.

Bardzo trudne Kod iniekcji SQL można również spróbować. Pragnę nadmienić, że w swojej karierze nie spotkałem się z żadnym przypadkiem, w którym w wyniku znaku pojawił się komunikat „Internal Server Error”, ale czasami pola nie reagowały na bardziej skomplikowany kod SQL.

Dlatego sprawdzanie pojedynczego cudzysłowu pod kątem SQL Injection „jest dość godnym zaufania sposobem sprawdzenia, czy ten atak jest możliwy, czy nie.

Jeśli pojedynczy cudzysłów nie zwróci niewłaściwego wyniku, możemy spróbować wprowadzić podwójne cudzysłowy i sprawdzić wyniki.

Ponadto kod SQL zmieniający zapytanie na zawsze prawdziwe można uznać za sposób sprawdzenia, czy ten atak jest możliwy, czy nie. Zamyka parametr i zmienia zapytanie na „prawda”. Dlatego jeśli nie zostanie zweryfikowany, takie wejście może również zwrócić dowolny nieoczekiwany wynik i poinformować to samo, że ten atak jest w tym przypadku możliwy.

Sprawdzanie pod kątem możliwych ataków SQL można również przeprowadzić przy użyciu łącza witryny internetowej. Załóżmy, że mamy łącze do witryny internetowej jako http://www.testing.com/books=1 . W tym przypadku „książki” to parametr, a „1” to jego wartość. Gdybyśmy w podanym linku napisali „znak zamiast 1, sprawdzilibyśmy, czy nie ma wtrysku.

Dlatego link http://www.testing.com/books= będzie jak test, czy atak SQL jest możliwy dla serwisu WWW http://www.testing.com albo nie.

W tym przypadku, jeśli link http://www.testing.com/books= zwraca komunikat o błędzie, taki jak „Internal Server Error”, pustą stronę lub inny nieoczekiwany komunikat o błędzie, a następnie możemy być pewni, że SQL Injection jest możliwy dla tej witryny. Później możemy spróbować wysłać bardziej skomplikowany kod SQL za pośrednictwem łącza witryny.

Aby sprawdzić, czy ten atak jest możliwy za pośrednictwem linku do witryny internetowej, czy nie, można również wysłać kod „lub 1 = 1; -”.

Jako doświadczony tester oprogramowania chciałbym przypomnieć, że nie tylko nieoczekiwany komunikat o błędzie można uznać za lukę SQL Injection. Wielu testerów sprawdza możliwe ataki tylko na podstawie komunikatów o błędach.

Należy jednak pamiętać, że żaden komunikat o błędzie walidacji lub komunikat o powodzeniu złośliwego kodu również nie może oznaczać, że ten atak jest możliwy.

Testowanie bezpieczeństwa aplikacji internetowych pod kątem iniekcji SQL

Testowanie bezpieczeństwa aplikacji internetowych wyjaśnione prostymi przykładami:

Ponieważ konsekwencje dopuszczenia tej techniki podatności mogą być poważne, wynika z tego, że ten atak powinien zostać przetestowany podczas testowania bezpieczeństwa aplikacji. Teraz, omawiając tę ​​technikę, przyjrzyjmy się kilku praktycznym przykładom wstrzykiwania SQL.

Ważne: ten test SQL Injection należy testować tylko w środowisku testowym.

Jeśli aplikacja ma stronę logowania, możliwe, że aplikacja używa dynamicznego języka SQL, takiego jak poniższa instrukcja. Oczekuje się, że ta instrukcja zwróci co najmniej jeden wiersz ze szczegółami użytkownika z tabeli Users jako zestaw wyników, jeśli istnieje wiersz z nazwą użytkownika i hasłem wprowadzonymi w instrukcji SQL.

SELECT * FROM Users WHERE User_Name = ‘” & strUserName & „‘ AND Password = ’” & strPassword & „”; ”

Jeśli tester wprowadziłby John jako strUserName (w polu tekstowym dla nazwy użytkownika) i Smith jako strPassword (w polu tekstowym dla hasła), powyższa instrukcja SQL stałaby się:

Jeśli tester wprowadziłby John’– jako strUserName i bez strPassword, instrukcja SQL zmieniłaby się w:

Zauważ, że część instrukcji SQL po Johnie zostaje zamieniona na komentarz. Jeśli w tabeli Users byłby jakikolwiek użytkownik o nazwie użytkownika John, aplikacja mogłaby pozwolić testerowi zalogować się jako użytkownik John. Tester mógł teraz przeglądać prywatne informacje użytkownika John.

Co jeśli tester nie zna nazwy żadnego z istniejących użytkowników aplikacji? W takim przypadku tester może wypróbować popularne nazwy użytkownika, takie jak admin, administrator i sysadmin. Jeśli żaden z tych użytkowników nie istnieje w bazie danych, tester może wpisać John ”lub„ x ”=” x jako strUserName and Smith ”lub„ x ”=” x jako strPassword. Spowodowałoby to, że instrukcja SQL stałaby się podobna do poniższej.

Ponieważ warunek „x” = „x” jest zawsze prawdziwy, zestaw wyników zawierałby wszystkie wiersze w tabeli Users. Aplikacja mogłaby umożliwić testerowi zalogowanie się jako pierwszy użytkownik w tabeli Użytkownicy.

Ważne: tester powinien poprosić administratora bazy danych lub programistę o skopiowanie danej tabeli przed przystąpieniem do następujących ataków.

Jeśli tester wprowadziłby Jana ”; DROP table users_details; ”- jako strUserName i cokolwiek jako strPassword, instrukcja SQL będzie taka jak ta poniżej.

Ta instrukcja może spowodować trwałe usunięcie tabeli „user_details” z bazy danych.

Chociaż powyższe przykłady dotyczą użycia techniki SQL injection tylko strony logowania, tester powinien przetestować tę technikę na wszystkich stronach aplikacji, które akceptują dane wejściowe użytkownika w formacie tekstowym, np. strony wyszukiwania, strony opinii itp.

Wstrzyknięcie SQL może być możliwe w aplikacjach korzystających z SSL. Nawet zapora może nie być w stanie chronić aplikacji przed tą techniką.

Próbowałem wyjaśnić tę technikę ataku w prostej formie. Chciałbym powtórzyć ten atak, powinien być testowany tylko w środowisku testowym, a nie w środowisku programistycznym, produkcyjnym lub innym.

przypadki testowe w przykładach testowania oprogramowania

Zamiast ręcznie testować, czy aplikacja jest podatna na atak SQL, można użyć pliku Web Vulnerability Scanner który sprawdza tę lukę.

Powiązana lektura: Testowanie bezpieczeństwa aplikacji internetowej . Sprawdź to, aby uzyskać więcej informacji na temat różnych luk w zabezpieczeniach internetowych.

Wrażliwe części tego ataku

Przed rozpoczęciem procesu testowania każdy szczery tester powinien mniej więcej wiedzieć, które części będą najbardziej narażone na możliwy ten atak.

Dobrą praktyką jest również zaplanowanie, które pole systemu ma zostać dokładnie przetestowane iw jakiej kolejności. Podczas mojej kariery testowej nauczyłem się, że nie jest dobrym pomysłem testowanie pól pod kątem ataków SQL w sposób losowy, ponieważ niektóre pola mogą zostać pominięte.

Ponieważ atak jest przeprowadzany w bazie danych, wszystkie części systemu wprowadzania danych, pola wejściowe i łącza do witryn internetowych są podatne na ataki.

Wrażliwe części obejmują:

• Pola logowania
• Pola wyszukiwania
• Pola komentarzy
• Wszelkie inne pola wprowadzania i zapisywania danych
• Linki w witrynie

Należy zauważyć, że podczas testowania tego ataku nie wystarczy sprawdzić tylko jedno lub kilka pól. Dość często zdarza się, że jedno pole może być chronione przed wstrzyknięciem SQL, a inne nie. Dlatego ważne jest, aby nie zapomnieć o przetestowaniu wszystkich pól witryny.

Automatyzacja testów iniekcji SQL

Ponieważ niektóre testowane systemy lub strony internetowe mogą być dość skomplikowane i zawierać poufne dane, ręczne testowanie może być naprawdę trudne i zajmuje dużo czasu. Dlatego testowanie tego ataku za pomocą specjalnych narzędzi może być czasami bardzo pomocne.

Jednym z takich narzędzi SQL Injection jest SOAP UI . Jeśli mamy zautomatyzowane testy regresji na poziomie API, możemy również przełączyć sprawdzanie przed tym atakiem za pomocą tego narzędzia. W narzędziu SOAP UI są już przygotowane szablony kodu do sprawdzania przed tym atakiem. Te szablony można również uzupełnić własnym napisanym kodem.

To dość niezawodne narzędzie.

Jednak test powinien być już zautomatyzowany na poziomie API, co nie jest takie proste. Innym możliwym sposobem automatycznego testowania jest użycie różnych wtyczek do przeglądarek.

Należy wspomnieć, że nawet jeśli zautomatyzowane narzędzia oszczędzają Twój czas, to nie zawsze są one uważane za bardzo niezawodne. Jeśli testujemy system bankowy lub jakąkolwiek stronę internetową z bardzo wrażliwymi danymi, zdecydowanie zalecamy przetestowanie go ręcznie. Gdzie możesz zobaczyć dokładne wyniki i je przeanalizować. Również w tym przypadku możemy być pewni, że nic nie zostało pominięte.

Porównanie z innymi atakami

SQL Injection można uznać za jeden z najpoważniejszych ataków, ponieważ wpływa na bazę danych i może spowodować poważne uszkodzenie danych i całego systemu.

Z pewnością może to mieć poważniejsze konsekwencje niż iniekcja JavaScript lub HTML, ponieważ oba są wykonywane po stronie klienta. Dla porównania z tym atakiem możesz mieć dostęp do całej bazy danych.

Należy wspomnieć, że aby przetestować ten atak, należy mieć dość dobrą znajomość języka programowania SQL i ogólnie wiedzieć, jak działają zapytania do baz danych. Również podczas wykonywania tego ataku iniekcyjnego należy być bardziej ostrożnym i spostrzegawczym, ponieważ wszelkie niedokładności mogą zostać pozostawione jako luki w zabezpieczeniach SQL.

Wniosek

Mam nadzieję, że masz jasny obraz tego, czym jest SQL Injection i jak powinniśmy zapobiegać tym atakom.

Jednak zdecydowanie zaleca się testowanie tego typu ataku za każdym razem, gdy testowany jest system lub witryna internetowa z bazą danych. Każda pozostawiona baza danych lub luki w systemie mogą kosztować reputację firmy i wiele zasobów, aby przywrócić cały system.

Ponieważ testowanie tego zastrzyku pomaga znaleźć najwięcej ważne luki w zabezpieczeniach , warto również zainwestować w swoją wiedzę i narzędzia testowe.

Jeśli planowane jest testowanie bezpieczeństwa, to testowanie w kierunku SQL Injection powinno być zaplanowane jako jedna z pierwszych części testowych.

Czy spotkałeś się z typowym wstrzyknięciem SQL? Zapraszam do podzielenia się swoimi doświadczeniami w sekcji komentarzy poniżej.

rekomendowane lektury

• Samouczek dotyczący wstrzykiwania HTML: typy i zapobieganie z przykładami
• Najlepsze narzędzia do testowania oprogramowania 2021 (Narzędzia do automatyzacji testów QA)
• Dogłębne samouczki dotyczące Eclipse dla początkujących
• Testy niszczące i samouczek dotyczący testów nieniszczących
• Testing Primer Pobierz eBook
• Testy funkcjonalne a testy niefunkcjonalne
• Samouczek testowania SOA: Metodologia testowania modelu architektury SOA
• Testowanie w parach lub samouczek testowania we wszystkich parach z narzędziami i przykładami