Die Sicherheit, die bei der Website-Front-End-Entwicklung auftritt, wird von den Leuten leicht ignoriert, da die meisten Leute denken, dass diese im Client-Browser ausgeführten Codes keine serverseitigen Sicherheitsrisiken verursachen. In diesem Artikel werden die häufig auftretenden Sicherheitsprobleme kurz erläutert das Website-Frontend und einige Bewältigungsstrategien
Mit der Entwicklung der Front-End-Technologie sind im Stillen Sicherheitsprobleme für jeden Benutzer vom Server aufgetreten, die Benutzerdaten stehlen, böswilligen, sich selbst reproduzierenden Wurmcode erstellen, die Ausbreitung von Viren unter Benutzern ermöglichen und zum Ausfall des Servers führen. Darüber hinaus können Benutzer zu Angreifern werden, ohne dass der Benutzer es merkt. Das ist definitiv nicht schockierend. Der Einsatz von Rich Clients wird immer weiter verbreitet und auch die Front-End-Sicherheitsprobleme nehmen zu. Heute werde ich kurz einige gängige Angriffsmethoden und Methoden zur Verhinderung von Angriffen vorstellen.
Häufige Angriffe
XSS (Cross Site Script), Cross-Site-Scripting-Angriff. Es bezieht sich darauf, dass ein böswilliger Angreifer bösartigen HTML-Code in eine Webseite einfügt. Wenn ein Benutzer die Seite durchsucht, wird der eingebettete bösartige HTML-Code ausgeführt, wodurch der spezielle Zweck des böswilligen Benutzers erreicht wird. Da XSS ein passiver Angriff ist und schwer auszunutzen ist, ignorieren viele Menschen seine Schädlichkeit. Mit der kontinuierlichen Weiterentwicklung der Frontend-Technologie und der zunehmenden Anzahl von Rich-Client-Anwendungen hat dieses Problem jedoch immer mehr Aufmerksamkeit auf sich gezogen. Um ein einfaches Beispiel zu nennen: Wenn Sie derzeit ein Benutzer auf der SNS-Site sind, besteht eine Sicherheitslücke in der Funktion zum Veröffentlichen von Informationen, die js ausführen kann Ihre neuen Informationen führen dieses Skript aus und ein Popup-Fenster wird angezeigt (sehr coole Popup-Anzeigen :)). Wenn Sie sich radikaler verhalten, sind die Konsequenzen unvorstellbar.
CSRF (Cross Site Request Forgery), standortübergreifende gefälschte Anfrage. Wie der Name schon sagt, ermöglicht es Benutzern, ihre eigene Identität zu verwenden, um einige der Ziele zu erreichen, die der Angreifer erreichen muss, indem er Verbindungsanfragen ohne Wissen des Benutzers fälscht. CSRF-Angriffe unterscheiden sich von XSS. CSRF muss durch das aktive Verhalten des Angreifers ausgelöst werden. Das hört sich so an, als ob der Verdacht bestehe, „gefischt“ zu werden, haha.
Mehrfensterbrowser scheinen in dieser Hinsicht zur Tyrannei beizutragen, da das neu geöffnete Fenster alle aktuellen Sitzungen enthält. Wenn es sich um ein einzelnes Browserfenster ähnlich dem IE6 handelt, wird es kein solches Problem geben, da jedes Fenster über ein solches verfügt ein unabhängiger Prozess. Lassen Sie uns ein einfaches Beispiel geben: Sie spielen White Society und sehen, wie jemand einen Link sendet. Dann wird in diesem Link ein Formular zum Senden von Geschenken gefälscht .
Cookie-Hijacking, indem Sie die Berechtigungen der Seite einholen, eine einfache Anfrage an die bösartige Website auf der Seite schreiben und das Cookie des Benutzers übertragen, nachdem Sie die Identität des Benutzers direkt angenommen haben Der gestohlene Benutzer meldet sich über das Cookie auf der Website an. Das ist Cookie-Hijacking. Um ein einfaches Beispiel zu nennen: Jemand hat ein sehr interessantes Tagebuch geschrieben und es dann mit allen geteilt. Alles schien normal zu sein. In dem Tagebuch hatte A Die Anfrage nach außen wird heimlich im Protokoll versteckt. Dann sendet jeder, der dieses Protokoll liest, sein Cookie an jemanden, ohne es zu wissen, und kann sich dann über das Cookie einer beliebigen Person bei dieser Person anmelden.
Was sollen wir tun?
Es lässt sich grob in zwei Kategorien einteilen: 1. Allgemeine Benutzer 2. Website-Entwickler.
Lassen Sie uns zunächst darüber sprechen, dass wir als allgemeiner Benutzer von Webprodukten oft passiv sind und ausgebeutet werden, ohne es zu wissen. Dann können wir:
1 Für den Zugriff auf Webanwendungen mit höheren Sicherheitsstufen müssen Sie ein separates Browserfenster öffnen.
2 Bei Links, die von Fremden gepostet wurden, ist es am besten, sie zu kopieren und in einem neuen Fenster zu öffnen. Am besten ist es natürlich, sie zu ignorieren - -.
Für Entwickler müssen wir es aus einer relativ detaillierten Perspektive analysieren:
Das Merkmal von XSS-Angriffen ist, dass der Code des Angreifers in der Lage sein muss, Ausführungsberechtigungen im Browser des Benutzers zu erhalten. Woher kommt der Code? Um solche Angriffe zu verhindern, können wir tatsächlich eine strenge Filterung am Ein- und Ausgang durchführen. Bei dieser Art der Doppelversicherung ist zu sagen, dass 99 % der ähnlichen Probleme von uns gelöst wurden und die anderen 1 % Ich glaube, dass diese Art von Problemen in Zukunft immer weniger auftreten werden, da die Folgeerscheinungen dieser beschissenen Browser immer geringer werden.
Hier habe ich die Formen von XSS-Schwachstellen sortiert
Der Schadcodewert wird als Inhalt eines bestimmten Tags angezeigt (wenn die Eingabe HTML ist, wird die HTML-Datei analysiert, nachdem Sie den Benutzernamen eingegeben und aktualisiert haben, wird der Benutzername angezeigt). ein bestimmtes Tag auf der Seite, wenn Sie
eingebenpopper.w
Wenn es also ohne Filterung direkt auf der Seite angezeigt wird, wird ein JS-Code eines Drittanbieters eingeführt und ausgeführt.
Strategie: Filtern Sie HTML-Tags und einige Sonderzeichen (" < > & usw.), bei denen keine HTML-Eingabe erforderlich ist, und konvertieren Sie sie in Zeichen, die vom Browser nicht interpretiert und ausgeführt werden
Schädlicher Code wird als Attribut eines bestimmten Tags angezeigt (durch Verwendung von „, um das Attribut zu kürzen, um neue Attribute oder bösartige Methoden zu öffnen). Diese Situation wird häufig durch Entwickler verursacht, die möglicherweise einige Informationen zu bestimmten DOM-Tags der Reihe nach aufzeichnen Um Funktionen zu implementieren, werden die vom Benutzer eingegebenen Informationen, z. B. der von Ihnen eingegebene Benutzername, in Form eines Titels im Tag auf der Seite angezeigt. Wenn Sie sorgfältig gestaltete Inhalte eingeben, sehen Sie sich dies an
Was ich hier tatsächlich eingegeben habe, ist „popper.w“ onclick="alert(1)". Natürlich können Sie oben weitere Inhalte schreiben.
Strategie: Filtern Sie einige Zeichen, die im Attribut abgeschnitten sein können. Sowohl einfache als auch doppelte Anführungszeichen, die im Attribut selbst vorhanden sind, müssen transkodiert werden.
Der Schadcode wird als HTML-Code selbst angezeigt (üblicher HTML-Editor). In dieser Situation treten die meisten Probleme auf, daher werde ich hier kein Beispiel nennen.
Strategie: Am besten filtern Sie die vom Benutzer eingegebenen HTML-Tags und Tag-Attribute auf die Whitelist. Sie können auch eine spezielle Filterung für einige anfällige Tags und Attribute durchführen.
Der Schadcode wird als JSON-String angezeigt (wodurch durch Variablenkürzung neue Schadcodes oder sogar ausführbarer Code erstellt werden). Der Schlüssel zu diesem Problem besteht darin, dass die vom Benutzer eingegebenen Informationen Teil des JS-Codes auf der Seite werden können .
Strategie: Filtern Sie einige Zeichen, die im Attribut abgeschnitten sein können. Sowohl einfache als auch doppelte Anführungszeichen, die im Attribut selbst vorhanden sind, müssen transkodiert werden.
Für CRSF- und Cookie-Hijacking
Merkmale: Hohe Verschleierung. Manchmal werden XSS-Schwachstellen zuerst ausgenutzt und dann ausgenutzt
Strategie
Erkennen Sie Benutzerbeiträge über Referrer, Token oder Bestätigungscode.
Versuchen Sie, im Link auf der Seite keine Informationen zur eindeutigen Nummer (Benutzer-ID) des Benutzers preiszugeben.
Für Benutzeränderungs-, Lösch- und Übermittlungsvorgänge verwenden Sie am besten den Post-Vorgang.
Vermeiden Sie standortweite Cookies und setzen Sie Cookies ausschließlich für die Domain.
ok, ich schreibe es einfach hier~
Die oben genannten sind einige häufige Sicherheitsprobleme, hauptsächlich aus der Perspektive des JS-Hacks. Mit der kontinuierlichen Entwicklung und dem Fortschritt der Front-End-Technologie können für Entwickler die meisten Probleme vermieden werden Das Beängstigende sind also nicht die Hacks. Was beängstigend ist, ist unsere Nachlässigkeit in Bezug auf die Sicherheit unserer Produkte.