In früheren Zeiten, als die Webentwicklung auf der Tatsache beruhte, dass Serveranwendungen Anforderungen an relationale Datenbanken sendeten und HTML-Ausgaben ausgaben, wurde dieser Code häufig gefunden:
oder so:
Seitdem haben wir gelernt, sicherere Ansätze zu verwenden.
Weit verbreitet sind Tools wie Template-Engines und Parameterbindung. Heutzutage ist es selten, gefährliche String-Verkettungen zu finden.
In diesem Artikel möchte ich meine Gedanken zu Angriffen durch Einfügen von Code mitteilen. Anscheinend sind sie in JavaScript immer noch eine Bedrohung.
Um zu verstehen, warum, teilen wir eines der erfolglosen Beispiele in einfachere Fragmente auf. So:
function f(userInput: A): A { const firstCommand: A = ...; const secondCommand: A = ...; return firstCommand.concat(userInput.concat(secondCommand)); }
Offensichtlich ist die
Hauptursache für die Angriffe durch die Einführung des Codes, dass es keinen Unterschied zwischen einem Befehl und Benutzereingaben für einen Computer gibt! Daher kann ein Angreifer Daten eingeben, die als Code weiterverarbeitet werden.Natürlich gibt es, wie gesagt, bekannte Abwehrmechanismen gegen solche Angriffe. Stattdessen:
"SELECT name FROM users WHERE login = \"" + login + "\""
besser so etwas schreiben:
query("SELECT name FROM users WHERE login = :login", {login})
Daher ist der Befehl
SELECT name FROM users WHERE login =:login klar von den
{login} -Daten getrennt. Gleichzeitig stellen interne Mechanismen sicher, dass Daten für die Verwendung in einer SQL-Abfrage vorbereitet werden. Das Entkommen von Anführungszeichen und das Einfügen von Schadcode schlägt fehl.
Die Entwicklung von Webanwendungen boomt jedoch. Nicht nur das wird zunehmend gefunden:
{ paramA: "the value of the A parameter", paramB: "the value of the A parameter", }
aber auch das:
{ paramA: "the value of the A parameter", paramB: {$in: [ "the value of the B parameter", "the value of the C parameter", ]}, }
Ein wesentlicher Unterschied zwischen den beiden Optionen besteht darin, dass der Parameterwert ein Objekt ist, das einen Befehl enthält!
userInput , die Werte werden aus
userInput gelesen:
{ paramA: userInput.paramA, paramB: {$in: [ userInput.paramB[0], userInput.paramB[1], ]}, }
Sie müssen sich keine Sorgen machen, dass der Benutzer eine schädliche Zeichenfolge bereitstellt. Alles wird sicher gehandhabt.
Das Problem ist, dass Parameterwerte nicht nur einfache Werte wie
the value of the A parameter , sondern auch Befehle, zum Beispiel
{$in: ["B", "C"]} . Der Benutzer kann eine Anfrage auf verschiedene Arten senden, nach deren Entschlüsselung ein Objekt erhalten wird (Formular, JSON oder XML), und daher kann der Code durch Injektion angegriffen werden.
Angenommen,
userInput.paramA ist
{$empty: false} . Dann lautet die Abfrage wie folgt:
{ paramA: {$empty: false}, paramB: {$in: [ userInput.paramB[0], userInput.paramB[1], ]}, }
Wiederum stellt sich heraus, dass für einen Computer zuverlässige Befehle nicht von unzuverlässigen Benutzereingaben zu unterscheiden sind.
Erst jetzt geht es nicht um zuverlässige und unzuverlässige Zeichenfolgen, sondern um zuverlässige und unzuverlässige Objekte.Um dieses Problem zu vermeiden, sollten Sie immer Befehle schreiben, damit sie nicht vom Benutzer empfangen werden können. Dies kann unter anderem mithilfe des in
React and
Snabbdom-Signature verwendeten Ansatzes (dies ist eine kleine Bibliothek zum Schutz vor dem Injizieren in das virtuelle DOM) realisiert werden, indem
jedes Symbolbefehlsobjekt so markiert wird, dass es nicht über das Netzwerk gesendet werden kann.
Ich gebe zu, ich selbst habe oft gedacht, dass Angriffe durch Einfügen von Code mich nicht bedrohen, da es keine SQL-Datenbank gibt oder wenn ich das virtuelle DOM verwende. Wie falsch ich war!
LOOKING.HOUSE - Das Projekt sammelte mehr als 150 Spiegel in 40 Ländern. Sie können Host-, Ping-, Traceroute- und mtr-Befehle schnell ausführen.
