sql injection testing tutorial example
Beispiele und Möglichkeiten zur Verhinderung von SQL-Injection-Angriffen auf Webanwendungen
Beim Testen einer Website oder eines Systems möchte der Tester sicherstellen, dass das getestete Produkt so gut wie möglich geschützt ist.
Zu diesem Zweck werden normalerweise Sicherheitstests durchgeführt. Um diese Art von Tests durchführen zu können, müssen wir zunächst überlegen, welche Angriffe am wahrscheinlichsten sind. SQL Injection ist einer dieser Angriffe.
SQL Injection gilt als einer der häufigsten Angriffe, da es schwerwiegende und schädliche Folgen für Ihr System und vertrauliche Daten haben kann.
Was du lernen wirst:
- Was ist SQL Injection?
- Risiken der SQL-Injektion
- Die Essenz dieses Angriffs
- Empfohlenes Werkzeug
- Sicherheitstests von Webanwendungen gegen SQL Injection
- Anfällige Teile dieses Angriffs
- Automatisieren von SQL-Injektionstests
- Vergleich mit anderen Angriffen
- Fazit
- Literatur-Empfehlungen
Was ist SQL Injection?
Einige der Benutzereingaben können beim Framing verwendet werden SQL-Anweisungen Diese werden dann von der Anwendung in der Datenbank ausgeführt. Es ist möglich, dass eine Anwendung die vom Benutzer eingegebenen Eingaben NICHT ordnungsgemäß verarbeitet.
Wenn dies der Fall ist, Ein böswilliger Benutzer kann unerwartete Eingaben in die Anwendung bereitstellen, die dann zum Einrahmen und Ausführen von SQL-Anweisungen in der Datenbank verwendet werden. Dies wird als SQL Injection bezeichnet. Die Folgen einer solchen Aktion könnten alarmierend sein.
Wie der Name selbst schon sagt, besteht der Zweck des SQL Injection-Angriffs darin, den schädlichen SQL-Code einzufügen.
Jedes Feld einer Website ist wie ein Tor zur Datenbank. Im Anmeldeformular gibt der Benutzer die Anmeldedaten ein, im Suchfeld gibt der Benutzer einen Suchtext ein, im Datenspeicherformular gibt der Benutzer die zu speichernden Daten ein. Alle diese angegebenen Daten gehen in die Datenbank.
Wenn anstelle von korrekten Daten schädlicher Code eingegeben wird, besteht die Möglichkeit, dass die Datenbank und das gesamte System ernsthaft beschädigt werden.
SQL Injection wird mit der Programmiersprache SQL ausgeführt. SQL (Structured Query Language) wird zum Verwalten der in der Datenbank gespeicherten Daten verwendet. Daher wird dieser Programmiersprachencode während dieses Angriffs als böswillige Injektion verwendet.
Dies ist einer der beliebtesten Angriffe, da Datenbanken für fast alle Technologien verwendet werden.
Viele Anwendungen verwenden eine Art Datenbank. Eine zu testende Anwendung verfügt möglicherweise über eine Benutzeroberfläche, die Benutzereingaben akzeptiert, mit denen die folgenden Aufgaben ausgeführt werden:
# 1) Zeigen Sie dem Benutzer die relevanten gespeicherten Daten, z. Die Anwendung überprüft die Anmeldeinformationen des Benutzers anhand der vom Benutzer eingegebenen Anmeldeinformationen und stellt dem Benutzer nur die relevanten Funktionen und Daten zur Verfügung
#zwei) Speichern Sie die vom Benutzer eingegebenen Daten in der Datenbank, z. Sobald der Benutzer ein Formular ausfüllt und abschickt, speichert die Anwendung die Daten in der Datenbank. Diese Daten werden dem Benutzer dann in derselben Sitzung sowie in nachfolgenden Sitzungen zur Verfügung gestellt
Risiken der SQL-Injektion
Heutzutage wird eine Datenbank für fast alle Systeme und Websites verwendet, da Daten irgendwo gespeichert werden sollten.
Da vertrauliche Daten in der Datenbank gespeichert werden, besteht ein höheres Risiko für die Sicherheit des Systems. Wenn die Daten einer persönlichen Website oder eines Blogs gestohlen werden, entsteht im Vergleich zu den Daten, die aus dem Bankensystem gestohlen werden, kein großer Schaden.
Der Hauptzweck dieses Angriffs besteht darin, die Datenbank des Systems zu hacken. Daher können die Folgen dieses Angriffs wirklich schädlich sein.
Die folgenden Dinge können sich aus SQL Injection ergeben
- Das Konto einer anderen Person hacken.
- Stehlen und Kopieren der sensiblen Daten der Website oder des Systems.
- Ändern der vertraulichen Daten des Systems.
- Löschen der sensiblen Daten des Systems.
- Der Benutzer kann sich als anderer Benutzer bei der Anwendung anmelden, auch als Administrator.
- Der Benutzer könnte private Informationen anzeigen, die anderen Benutzern gehören, z. Details zu Profilen anderer Benutzer, Transaktionsdetails usw.
- Der Benutzer kann die Anwendungskonfigurationsinformationen und die Daten der anderen Benutzer ändern.
- Der Benutzer kann die Struktur der Datenbank ändern. Löschen Sie sogar Tabellen in der Anwendungsdatenbank.
- Der Benutzer kann die Kontrolle über den Datenbankserver übernehmen und nach Belieben Befehle ausführen.
Die oben aufgeführten Risiken können wirklich als schwerwiegend angesehen werden, da die Wiederherstellung einer Datenbank oder ihrer Daten viel kosten kann. Die Wiederherstellung der verlorenen Daten und des verlorenen Systems kann Ihrem Unternehmen einen guten Ruf und Geld kosten. Daher wird dringend empfohlen, Ihr System vor dieser Art von Angriff zu schützen und Sicherheitstests als eine gute Investition in den Ruf Ihres Produkts und Ihres Unternehmens zu betrachten.
Als Tester möchte ich kommentieren, dass das Testen gegen mögliche Angriffe eine gute Praxis ist, auch wenn Sicherheitstests war nicht geplant. Auf diese Weise können Sie das Produkt vor unerwarteten Fällen und böswilligen Benutzern schützen und testen.
Die Essenz dieses Angriffs
Wie bereits erwähnt, besteht der Kern dieses Angriffs darin, die Datenbank mit böswilligem Zweck zu hacken.
Um diese Sicherheitstests durchführen zu können, müssen Sie zunächst die anfälligen Systemteile suchen und dann schädlichen SQL-Code über diese an die Datenbank senden. Wenn dieser Angriff für ein System möglich ist, wird geeigneter schädlicher SQL-Code gesendet und schädliche Aktionen können in der Datenbank ausgeführt werden.
Jedes Feld einer Website ist wie ein Tor zur Datenbank. Alle Daten oder Eingaben, die wir normalerweise in ein Feld des Systems oder der Website eingeben, gehen an die Datenbankabfrage. Wenn wir also anstelle korrekter Daten schädlichen Code eingeben, wird dieser möglicherweise in der Datenbankabfrage ausgeführt und hat schädliche Folgen.
Empfohlenes Werkzeug
# 1) Kiuwan
Finden und beheben Sie Schwachstellen wie SQL-Injection in Ihrem Code in jeder Phase des SDLC. Kiuwan erfüllt die strengsten Sicherheitsstandards, darunter OWASP, CWE, SANS 25, HIPPA und mehr.
Integrieren Sie Kiuwan in Ihre IDE, um sofortiges Feedback während der Entwicklung zu erhalten. Kiuwan unterstützt alle wichtigen Programmiersprachen und lässt sich in führende DevOps-Tools integrieren.
=> Scannen Sie Ihren Code kostenlos
Um diesen Angriff auszuführen, müssen wir die Handlung und den Zweck einer geeigneten Datenbankabfrage ändern. Eine der möglichen Methoden, um dies durchzuführen, besteht darin, die Abfrage immer wahr zu machen und danach Ihren Schadcode einzufügen. Das Ändern der Datenbankabfrage auf immer true kann mit einfachem Code wie ‘oder 1 = 1; - durchgeführt werden.
Tester sollten berücksichtigen, dass bei der Überprüfung, ob die Abfrage auf immer wahr geändert werden kann oder nicht, verschiedene Anführungszeichen verwendet werden sollten - einfach und doppelt. Wenn wir also Code wie 'oder 1 = 1; - ausprobiert haben, sollten wir auch den Code mit doppelten Anführungszeichen' oder 1 = 1; - versuchen.
Zum Beispiel, Nehmen wir an, wir haben eine Abfrage, die nach dem in der Datenbanktabelle eingegebenen Wort sucht:
Wählen Sie * aus den Notizen nt, wobei nt.subject = 'search_word';
Wenn wir daher anstelle des Suchworts eine SQL Injection-Abfrage eingeben 'oder 1 = 1; -, wird die Abfrage immer wahr.
Wählen Sie * aus den Noten nt, wobei nt.subject = '' oder 1 = 1; -
In diesem Fall wird der Parameter „subject“ mit dem Anführungszeichen geschlossen und dann haben wir Code oder 1 = 1, wodurch eine Abfrage immer wahr wird. Mit dem Zeichen „-“ kommentieren wir den Rest des Abfragecodes, der nicht ausgeführt wird. Dies ist eine der beliebtesten und einfachsten Methoden, um die Abfrage zu steuern.
Es können auch nur wenige andere Codes verwendet werden, um die Abfrage immer wahr zu machen, wie z.
- 'Oder' abc '=' abc '; -
- 'Oder' = '; -
Der wichtigste Teil hier ist, dass wir nach dem Kommazeichen jeden schädlichen Code eingeben können, den wir ausführen möchten.
Zum Beispiel, es kann „oder 1 = 1 sein; Tabellen Notizen fallen lassen; - -
Wenn diese Injektion möglich ist, kann jeder andere Schadcode geschrieben werden. In diesem Fall hängt dies nur vom Wissen und der Absicht des böswilligen Benutzers ab. Wie überprüfe ich SQL Injection?
Das Überprüfen auf diese Sicherheitsanfälligkeit kann sehr einfach durchgeführt werden. Manchmal reicht es aus, in die getesteten Felder ein Zeichen „oder“ einzugeben. Wenn eine unerwartete oder außergewöhnliche Nachricht zurückgegeben wird, können wir sicher sein, dass SQL Injection für dieses Feld möglich ist.
Zum Beispiel , Wenn Sie als Suchergebnis eine Fehlermeldung wie 'Interner Serverfehler' erhalten, können wir sicher sein, dass dieser Angriff in diesem Teil des Systems möglich ist.
Weitere Ergebnisse, die einen möglichen Angriff melden können, sind:
- Leere Seite geladen.
- Keine Fehler- oder Erfolgsmeldungen - Funktionalität und Seite reagieren nicht auf die Eingabe.
- Erfolgsmeldung für Schadcode.
Schauen wir uns an, wie dies in der Praxis funktioniert.
Zum Beispiel, Testen wir, ob ein geeignetes Anmeldefenster für SQL Injection anfällig ist. Zu diesem Zweck geben wir im Feld E-Mail-Adresse oder Passwort einfach das Zeichen wie unten gezeigt ein.
Wenn eine solche Eingabe ein Ergebnis wie die Fehlermeldung 'Interner Serverfehler' oder ein anderes aufgeführtes unangemessenes Ergebnis zurückgibt, können wir fast sicher sein, dass dieser Angriff für dieses Feld möglich ist.
Ein sehr kniffliger SQL Injection Code kann auch versucht werden. Ich möchte erwähnen, dass ich in meiner Karriere keinen Fall festgestellt habe, in dem aufgrund des Vorzeichens die Meldung 'Interner Serverfehler' angezeigt wurde, die Felder jedoch manchmal nicht auf komplizierteren SQL-Code reagierten.
Daher ist die Überprüfung auf SQL Injection mit einem einfachen Anführungszeichen eine vertrauenswürdige Methode, um zu überprüfen, ob dieser Angriff möglich ist oder nicht.
Wenn das einfache Anführungszeichen kein unangemessenes Ergebnis liefert, können wir versuchen, doppelte Anführungszeichen einzugeben und die Ergebnisse zu überprüfen.
Außerdem kann SQL-Code zum Ändern der Abfrage in 'Immer wahr' als Möglichkeit angesehen werden, um zu überprüfen, ob dieser Angriff möglich ist oder nicht. Es schließt den Parameter und ändert die Abfrage in 'true'. Wenn diese Eingabe nicht validiert wird, kann sie daher auch jedes unerwartete Ergebnis zurückgeben und dasselbe darüber informieren, dass dieser Angriff in diesem Fall möglich ist.
Die Überprüfung auf mögliche SQL-Angriffe kann auch über den Link der Website erfolgen. Angenommen, wir haben den Link einer Website als http://www.testing.com/books=1 . In diesem Fall ist 'Bücher' ein Parameter und '1' ist sein Wert. Wenn wir in den angegebenen Link ein Zeichen anstelle von 1 schreiben würden, würden wir nach einer möglichen Injektion suchen.
Deshalb verlinken http://www.testing.com/books= wird wie ein Test sein, wenn der SQL-Angriff für die Website möglich ist http://www.testing.com oder nicht.
In diesem Fall wenn Link http://www.testing.com/books= Gibt eine Fehlermeldung wie 'Interner Serverfehler' oder eine leere Seite oder eine andere unerwartete Fehlermeldung zurück. Dann können wir auch sicher sein, dass SQL Injection für diese Website möglich ist. Später können wir versuchen, kniffligeren SQL-Code über den Link der Website zu senden.
Um zu überprüfen, ob dieser Angriff über den Link der Website möglich ist oder nicht, kann auch Code wie 'oder 1 = 1; -' gesendet werden.
Als erfahrener Software-Tester möchte ich daran erinnern, dass nicht nur die unerwartete Fehlermeldung als SQL Injection-Sicherheitsanfälligkeit angesehen werden kann. Viele Tester prüfen mögliche Angriffe nur anhand von Fehlermeldungen.
Es sollte jedoch beachtet werden, dass keine Validierungsfehlermeldung oder Erfolgsmeldung für bösartigen Code auch ein Zeichen dafür sein kann, dass dieser Angriff möglich ist.
Sicherheitstests von Webanwendungen gegen SQL Injection
Sicherheitstests von Webanwendungen anhand einfacher Beispiele erläutert:
Da die Konsequenzen des Zulassens dieser Sicherheitsanfälligkeitstechnik schwerwiegend sein können, sollte dieser Angriff während des Sicherheitstests einer Anwendung getestet werden. Lassen Sie uns nun mit einem Überblick über diese Technik einige praktische Beispiele für die SQL-Injection verstehen.
Wichtig: Dieser SQL Injection Test sollte nur in der Testumgebung getestet werden.
Wenn die Anwendung über eine Anmeldeseite verfügt, verwendet die Anwendung möglicherweise dynamisches SQL wie die folgende Anweisung. Es wird erwartet, dass diese Anweisung mindestens eine einzelne Zeile mit den Benutzerdetails aus der Users-Tabelle als Ergebnismenge zurückgibt, wenn in der SQL-Anweisung eine Zeile mit dem Benutzernamen und dem Kennwort eingegeben wird.
SELECT * FROM Users WHERE User_Name = '' & strUserName & '' AND Password = '' & strPassword & '’; '
Wenn der Tester John als strUserName (im Textfeld für den Benutzernamen) und Smith als strPassword (im Textfeld für das Kennwort) eingeben würde, würde die obige SQL-Anweisung wie folgt lauten:
SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;
Wenn der Tester John als strUserName und kein strPassword eingeben würde, würde die SQL-Anweisung wie folgt lauten:
SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;
Beachten Sie, dass der Teil der SQL-Anweisung nach John in einen Kommentar umgewandelt wird. Wenn sich in der Benutzertabelle ein Benutzer mit dem Benutzernamen John befindet, kann sich der Tester mit der Anwendung möglicherweise als Benutzer John anmelden. Der Tester konnte nun die privaten Informationen des Benutzers John anzeigen.
Was ist, wenn der Tester den Namen eines vorhandenen Benutzers der Anwendung nicht kennt? In einem solchen Fall könnte der Tester gängige Benutzernamen wie admin, Administrator und sysadmin ausprobieren. Wenn keiner dieser Benutzer in der Datenbank vorhanden ist, kann der Tester John oder 'x' = 'x' als strUserName und Smith 'oder' x '=' x 'als strPassword eingeben. Dies würde dazu führen, dass die SQL-Anweisung der folgenden entspricht.
SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;
Da die Bedingung 'x' = 'x' immer erfüllt ist, besteht die Ergebnismenge aus allen Zeilen in der Benutzertabelle. Die Anwendung kann es dem Tester ermöglichen, sich als erster Benutzer in der Benutzertabelle anzumelden.
Wichtig: Der Tester sollte den Datenbankadministrator oder den Entwickler auffordern, die betreffende Tabelle zu kopieren, bevor die folgenden Angriffe ausgeführt werden.
Wenn der Tester John betreten würde; DROP-Tabelle users_details; ’- als strUserName und alles als strPassword würde die SQL-Anweisung wie folgt aussehen.
SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';
Diese Anweisung kann dazu führen, dass die Tabelle 'users_details' dauerhaft aus der Datenbank gelöscht wird.
Obwohl sich die obigen Beispiele mit der Verwendung der SQL-Injektionstechnik nur auf der Anmeldeseite befassen, sollte der Tester diese Technik auf allen Seiten der Anwendung testen, die Benutzereingaben im Textformat akzeptieren, z. Suchseiten, Feedbackseiten usw.
In Anwendungen, die SSL verwenden, ist möglicherweise eine SQL-Injection möglich. Selbst eine Firewall kann die Anwendung möglicherweise nicht vor dieser Technik schützen.
Ich habe versucht, diese Angriffstechnik in einer einfachen Form zu erklären. Ich möchte diesen Angriff wiederholen und sollte nur in einer Testumgebung und nicht in der Entwicklungsumgebung, Produktionsumgebung oder einer anderen Umgebung getestet werden.
youtube zu mp3 mehr als 20 min
Anstatt manuell zu testen, ob die Anwendung für SQL-Angriffe anfällig ist oder nicht, könnte man a verwenden Web Vulnerability Scanner das prüft auf diese Schwachstelle.
Verwandte Lektüre: Sicherheitstests der Webanwendung . Überprüfen Sie dies, um weitere Informationen zu verschiedenen Web-Schwachstellen zu erhalten.
Anfällige Teile dieses Angriffs
Vor Beginn des Testprozesses sollte jeder aufrichtige Tester mehr oder weniger wissen, welche Teile für einen möglichen Angriff am anfälligsten sind.
Es ist auch eine gute Praxis, zu planen, welcher Bereich des Systems genau und in welcher Reihenfolge getestet werden soll. In meiner Testkarriere habe ich gelernt, dass es keine gute Idee ist, Felder zufällig gegen SQL-Angriffe zu testen, da einige Felder übersehen werden können.
Da dieser Angriff in der Datenbank ausgeführt wird, sind alle Teile des Dateneingabesystems, Eingabefelder und Website-Links anfällig.
Zu den gefährdeten Teilen gehören:
- Anmeldefelder
- Suchfelder
- Kommentarfelder
- Alle anderen Dateneingabe- und Speicherfelder
- Links der Website
Es ist wichtig zu beachten, dass es beim Testen gegen diesen Angriff nicht ausreicht, nur ein oder mehrere Felder zu überprüfen. Es ist durchaus üblich, dass ein Feld gegen SQL Injection geschützt ist, ein anderes jedoch nicht. Daher ist es wichtig, nicht zu vergessen, alle Felder der Website zu testen.
Automatisieren von SQL-Injektionstests
Da einige getestete Systeme oder Websites sehr kompliziert sein können und vertrauliche Daten enthalten, kann das manuelle Testen sehr schwierig sein und auch viel Zeit in Anspruch nehmen. Daher kann das Testen gegen diesen Angriff mit Spezialwerkzeugen manchmal sehr hilfreich sein.
Ein solches SQL Injection-Tool ist SOAP-Benutzeroberfläche . Wenn wir automatisierte Regressionstests auf API-Ebene haben, können wir mit diesem Tool auch die Überprüfung gegen diesen Angriff umschalten. Im SOAP-UI-Tool sind bereits Codevorlagen zur Überprüfung gegen diesen Angriff vorbereitet. Diese Vorlagen können auch durch Ihren eigenen geschriebenen Code ergänzt werden.
Es ist ein ziemlich zuverlässiges Werkzeug.
Ein Test sollte jedoch bereits auf API-Ebene automatisiert werden, was nicht so einfach ist. Eine andere Möglichkeit, automatisch zu testen, ist die Verwendung verschiedener Browser-Plugins.
Es sollte erwähnt werden, dass automatisierte Tools, auch wenn sie Ihre Zeit sparen, nicht immer als sehr zuverlässig angesehen werden. Wenn wir ein Bankensystem oder eine Website mit sehr sensiblen Daten testen, wird dringend empfohlen, diese manuell zu testen. Hier können Sie die genauen Ergebnisse sehen und analysieren. Auch in diesem Fall können wir sicher sein, dass nichts übersprungen wurde.
Vergleich mit anderen Angriffen
SQL Injection kann als einer der schwerwiegendsten Angriffe angesehen werden, da es die Datenbank beeinflusst und Ihre Daten und das gesamte System ernsthaft beschädigen kann.
Sicherlich kann dies schwerwiegendere Konsequenzen haben als eine Javascript-Injection oder eine HTML-Injection, da beide clientseitig ausgeführt werden. Zum Vergleich: Mit diesem Angriff können Sie auf die gesamte Datenbank zugreifen.
Es sollte erwähnt werden, dass Sie zum Testen gegen diesen Angriff über gute Kenntnisse der SQL-Programmiersprache verfügen und im Allgemeinen wissen sollten, wie Datenbankabfragen funktionieren. Auch bei der Durchführung dieses Injection-Angriffs sollten Sie vorsichtiger und aufmerksamer sein, da Ungenauigkeiten als SQL-Schwachstellen zurückbleiben können.
Fazit
Ich hoffe, Sie hätten eine klare Vorstellung davon, was eine SQL-Injektion ist und wie wir diese Angriffe verhindern sollten.
Es wird jedoch dringend empfohlen, jedes Mal, wenn ein System oder eine Website mit einer Datenbank getestet wird, gegen diese Art von Angriff zu testen. Alle Schwachstellen in der linken Datenbank oder im System können den Ruf eines Unternehmens und viele Ressourcen kosten, um das gesamte System wiederherzustellen.
Da das Testen gegen diese Injektion hilft, das Beste zu finden wichtige Sicherheitslücken Es wird auch empfohlen, in Ihr Wissen und Ihre Testwerkzeuge zu investieren.
Wenn Sicherheitstests geplant sind, sollten Tests gegen SQL Injection als einer der ersten Testteile geplant werden.
Sind Sie auf eine typische SQL Injection gestoßen? Fühlen Sie sich frei, Ihre Erfahrungen in den Kommentaren unten zu teilen.
Literatur-Empfehlungen
- HTML Injection Tutorial: Typen & Prävention mit Beispielen
- Beste Software-Test-Tools 2021 (QA Test Automation Tools)
- Ausführliche Eclipse-Tutorials für Anfänger
- Tutorial für zerstörende Tests und zerstörungsfreie Tests
- Testen von Primer eBook Download
- Funktionstests gegen nichtfunktionale Tests
- SOA-Test-Tutorial: Testmethode für ein SOA-Architekturmodell
- Tutorial zum paarweisen Testen oder Testen aller Paare mit Tools und Beispielen