In einem früheren Artikel habe ich vorgeschlagen, dass der Leser weiß, wie die SQL-Abfragesprache im Detail strukturiert ist und wie das HTTP-Protokoll funktioniert. Dies ist jedoch normalerweise nicht der Fall. Und ich erinnerte mich sofort an die Geschichte, die Rob Brotherton in einem meiner Lieblingsbücher „Untrustworthy Minds“ beschrieben hatte. Es beschreibt das folgende Experiment. Die Psychologin Rebecca Lawson fragte eine Gruppe von Probanden, ob sie in ihrem Leben jemals Fahrrad gefahren seien. Die meisten antworteten mit Ja. Sie fragte weiter, ob sie wissen, wie das Fahrrad funktioniert. Es gab bereits weniger positive Antworten, aber immer noch die überwiegende Mehrheit. Und dann schlug sie das folgende Bild vor und bat darum, es zu ergänzen, damit dieses Fahrrad fahren könne.
Und dann passierte das Interessanteste - mehr als die Hälfte der Menschen konnte dies nicht tun. Diese täuschend einfache Aufgabe zeigt, dass sich die meisten Menschen einfach nicht vorstellen können, wie ein Fahrrad funktioniert. Das Interessanteste ist jedoch, dass sie nicht verstehen, dass sie dies nicht wissen, sondern dies erst in dem Moment verstehen, in dem sie dieses Wissen demonstrieren müssen.
Bei HTTP und SQL passiert dasselbe. 90% der IT-Experten haben SQL-Abfragen geschrieben, zumindest in Laboratorien in ihren Bildungseinrichtungen, Menschen arbeiten jeden Tag als Benutzer mit HTTP, und von Zeit zu Zeit konfigurieren dieselben IT-Experten Webserver, die tatsächlich mit HTTP arbeiten. Wenn Sie jedoch eine bestimmte Frage beantworten müssen, tritt regelmäßig eine Betäubung auf.
Ein Analyst für Informationssicherheit muss die Technologie im Detail kennen und die Nuancen und Feinheiten kennen. Wenn wir nicht wissen, wie diese oder jene Technologie funktionieren soll, wie können wir dann herausfinden, was daran falsch ist?
Auch eine "Injektion"
Ich erwähnte, dass die Überprüfung der Eingabe auf dem Server erfolgen sollte, nicht jedoch auf dem Client. Von Zeit zu Zeit kann es zu Eingabeformularen kommen, bei denen einzelne Elemente inaktiv sind. Und es wird angenommen, dass sie aktiv werden, wenn bestimmte Bedingungen erfüllt sind. Das Eingabefeld für den Benutzernamen ist beispielsweise 7 Zeichen lang, wodurch die maximale Länge des Benutzernamens begrenzt wird. All dies ist eine sehr schlechte Praxis, und hier ist der Grund: Die Elemente auf der Seite, die bereits empfangen wurden, können vor dem Senden ohne spezielle technische Mittel willkürlich bearbeitet werden. In OWASP Mutillidae II ist dies im Beispiel "Andere"> "Clientseitige" Sicherheitskontrollen "zu sehen.
Hier ist ein Formular, in dessen Feldern Sie eine Zufallszahl eingeben müssen, diesmal 2056694312. Die „Schwierigkeit“ hierbei ist, dass die Felder Einschränkungen aufweisen. Es gibt ein schreibgeschütztes Feld, in dem die Nummer 42 nicht ersetzt werden kann, ein zu kurzes Feld für ein kurzes Textfeld, in das unsere Nummer einfach nicht passt, ein deaktiviertes Feld für deaktiviertes Textfeld, das inaktiv ist, und so weiter.
In der Tat ist die Aufgabe sehr einfach gelöst. Rufen Sie im Browser (in meinem Fall Mozilla Firefox) die Entwicklerkonsole (F12) auf und überprüfen Sie die Formularelemente.
Ein schreibgeschütztes Feld sieht beispielsweise folgendermaßen aus:
<input HTMLandXSSInjectionPoint="1" type="text" name="readonly_textbox" id="id_readonly_textbox" size="15" maxlength="15" required="required" autofocus="autofocus" readonly="readonly" value="42" />
Readonly = ”readonly” und voila löschen: Das Formular ist beschreibbar, wir können unsere Nummer eingeben.
Unser Wert passt einfach nicht in das nächste Feld. Schauen wir uns dieses Element an:
<input HTMLandXSSInjectionPoint="1" type="text" name="short_textbox" id="id_short_textbox" size="3" maxlength="3" required="required" />
Hier bemerken wir maxlength = "3". Ersetzen Sie 3 durch 333, jetzt können wir unsere Nummer eingeben, ohne befürchten zu müssen, dass sie nicht passt.
Übrigens geht es nicht nur um Eingabefelder. Ebenso können Sie beliebige Elemente ändern, z. B. Kontrollkästchen. Der Seitencode sieht folgendermaßen aus:
<input type="checkbox" name="checkbox" id="id_checkbox" value="2056694312" required="required" disabled="disabled" />
Hier ist es ganz einfach: Wir ersetzen den Wert durch unsere Nummer. Jetzt wird er gesendet, wenn der Benutzer auf die Schaltfläche klickt.
Wenn Sie wissen, wie HTML aufgebaut ist, fällt es Ihnen insgesamt nicht schwer, dieses Formular so zu korrigieren, dass Sie dort alle erforderlichen Daten eingeben. Lesen Sie einfach den Abschnitt über das Fahrradsyndrom erneut =)
Nicht nur SQL
Bei der Injektion geht es nicht immer um Datenbanken. Im Großen und Ganzen können Sie aus jedem Formular, das eingehende Daten nicht filtert, einige zusätzliche Informationen erhalten. Im Beispiel "Application Log Injection"> "DNS Lookup" gibt es ein praktisches Formular für DNS-Abfragen:
Wenn Sie dort die Adresse eingeben, z. B. google.com, erhalten wir alle erforderlichen Informationen:
Die Sicherheitsanfälligkeit besteht jedoch darin, dass wir zusätzlich zum ersten gültigen Befehl noch etwas anderes eingeben können. Geben Sie beispielsweise Folgendes an:
google.com && dir
und jetzt ist die Ausgabe des Befehls viel interessanter:
Wir haben eine Anfrage an den DNS-Server gestellt, aber zusätzlich den Befehl dir ausgeführt und uns angesehen, was sich in dem Ordner mit unserer Site befindet. Es ist nicht schwierig, verschiedene Befehle zu kombinieren, um auf der Festplatte des Webservers herumzuwandern und nach Fehlern zu suchen.
Das nächste Mal werden wir weitere Beispiele analysieren und sehen, wie Sie Ihre Arbeit automatisieren können.
Lesen Sie den Blog des Autors unter
diesem Link .