Gängige Angriffe auf Web-Frontends und Möglichkeiten, sie zu verhindern

Die Sicherheitsprobleme, die bei der Frontend-Entwicklung von Websites auftreten, werden von den meisten Menschen leicht übersehen, da die meisten Menschen glauben, dass diese Codes, die im Client-Browser ausgeführt werden, keine Sicherheitsrisiken auf der Serverseite verursachen. In diesem Artikel werden kurz die Sicherheitsprobleme erläutert, die häufig im Frontend von Websites auftreten, sowie einige Bewältigungsstrategien.

Mit der Entwicklung der Front-End-Technologie sind Sicherheitsprobleme still und leise vom Server auf jeden Benutzer übergegangen. Benutzerdaten werden gestohlen, bösartige, sich selbst replizierende Wurmcodes erstellt, Viren können sich unter Benutzern verbreiten und Server stürzen ab. Darüber hinaus können Benutzer ohne ihr Wissen zu Angreifern werden, was definitiv nicht schockierend ist. Mit der zunehmenden Nutzung von Rich Clients nehmen auch die Front-End-Sicherheitsprobleme zu. Heute stellen wir kurz einige gängige Angriffsmethoden und Möglichkeiten zu ihrer Verhinderung vor.

Häufige Angriffe

XSS (Cross Site Script), Cross-Site-Scripting-Angriff. Dabei handelt es sich um böswillige Angreifer, die bösartigen HTML-Code in eine Webseite einfügen. Wenn ein Benutzer die Seite besucht, wird der eingebettete bösartige HTML-Code ausgeführt, wodurch das spezielle Ziel des böswilligen Benutzers erreicht wird. XSS ist ein passiver Angriff. Da es passiv und schwierig zu verwenden ist, wird seine Schädlichkeit von vielen Leuten oft ignoriert. Mit der kontinuierlichen Weiterentwicklung der Front-End-Technologie und der zunehmenden Anzahl von Rich-Client-Anwendungen erhalten Probleme in diesem Bereich jedoch immer mehr Aufmerksamkeit. Nehmen wir ein einfaches Beispiel: Sie sind Benutzer einer SNS-Site und in der Funktion zur Veröffentlichung von Informationen gibt es eine Sicherheitslücke, die die Ausführung von JS ermöglicht. Wenn Sie in diesem Moment ein bösartiges Skript eingeben, führen die Browser aller Personen, die Ihre neuen Informationen gerade sehen, dieses Skript aus und ein Eingabeaufforderungsfenster wird angezeigt (Popup-Werbung ist cool, oder? :)). Wenn Sie etwas Radikaleres tun, sind die Folgen unvorstellbar.

CSRF (Cross Site Request Forgery), Site-übergreifende gefälschte Anfrage. Wie der Name schon sagt, geht es dabei darum, Verbindungsanforderungen ohne das Wissen des Benutzers zu fälschen, sodass der Benutzer seine eigene Identität verwenden kann, um einige der Ziele des Angreifers zu erreichen. CSRF-Angriffe unterscheiden sich von XSS-Angriffen dadurch, dass CSRF durch aktives Verhalten des Angreifers ausgelöst werden muss. Das klingt nach einem Phishing-Fall, haha.
Browser mit mehreren Fenstern scheinen in dieser Hinsicht hilfreich zu sein, da das neu geöffnete Fenster alle aktuellen Sitzungen enthält. Bei einem einzelnen Browserfenster wie IE6 gibt es dieses Problem nicht, da jedes Fenster ein unabhängiger Prozess ist. Nehmen wir ein einfaches Beispiel: Sie spielen Baishehui und sehen, dass jemand einen Link gesendet hat. Sie klicken darauf und dann befindet sich im Link ein gefälschtes Formular zum Senden von Geschenken. Dies ist nur ein einfaches Beispiel und das Problem ist offensichtlich.

Beim Cookie-Hijacking erhalten Sie die Berechtigungen der Seite , schreiben eine einfache Anfrage an die bösartige Site auf der Seite und übertragen das Cookie des Benutzers. Nachdem Sie das Cookie erhalten haben, können Sie sich über das Cookie direkt als gestohlener Benutzer bei der Site anmelden. Dies ist Cookie-Hijacking. Nehmen wir ein einfaches Beispiel: Jemand hat einen interessanten Blogbeitrag geschrieben und ihn mit allen geteilt. Viele Leute haben darauf geklickt, um ihn anzusehen und zu teilen. Alles schien normal. Die Person, die den Blogbeitrag geschrieben hat, hatte jedoch andere Absichten und versteckte heimlich eine Anfrage an eine externe Site im Blogbeitrag. Dann schickte jeder, der den Blogbeitrag gelesen hatte, unwissentlich seine Cookies an jemand anderen, und er konnte sich über das Cookie dieser Person in das Konto jeder Person einloggen.

Was sollen wir tun?

Es kann grob in zwei Kategorien unterteilt werden: 1. Allgemeine Benutzer 2. Website-Entwickler.

Lassen Sie uns zunächst darüber sprechen, dass wir als allgemeine Benutzer von Webprodukten häufig passiv sind und ausgenutzt werden, ohne es zu wissen. Dann können wir:
1 Um auf Webanwendungen mit einer höheren Sicherheitsstufe zuzugreifen, müssen Sie ein separates Browserfenster öffnen.
2 Links, die von Fremden gepostet wurden, kopieren Sie am besten und öffnen Sie sie in einem neuen Fenster. Am besten ist es natürlich, sie zu ignorieren.

Für Entwickler müssen wir aus einigen relativ detaillierten Perspektiven analysieren:
Das Merkmal von XSS-Angriffen besteht darin, dass der Code des Angreifers Ausführungsberechtigungen für den Browser des Benutzers erhalten muss. Woher kommt also der Code? Um solche Angriffe zu verhindern, können Sie tatsächlich strenge Filter am Eingang und Ausgang durchführen. Diese doppelte Versicherung sollte bedeuten, dass 99 % der ähnlichen Probleme von uns gelöst wurden. Die anderen 1 % sind die Folgen dieser beschissenen Browser. Ich glaube, dass solche Probleme in Zukunft immer seltener auftreten werden.

Hier habe ich die Formen der XSS-Schwachstellen sortiert

Der Schadcodewert wird als Inhalt eines bestimmten Tags angezeigt (wenn die Eingabe HTML ist, wird das HTML analysiert). Wenn Sie beispielsweise einen Benutzernamen eingeben, wird dieser Benutzername nach der Aktualisierung in einem bestimmten Tag auf der Seite angezeigt. Wenn Sie eingeben

popper.w<script src="hack.js" type="text/javajscript"></script>

Wenn es 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 (" < > & etc.), 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 Tags angezeigt (indem das Attribut mit " abgeschnitten wird, um ein neues Attribut oder eine bösartige Methode zu erstellen). Diese Situation liegt häufig daran, dass Entwickler einige Benutzereingabeinformationen in bestimmten DOM-Tags aufzeichnen, um Funktionen zu implementieren. Beispielsweise wird der von Ihnen eingegebene Benutzername als Titel im Tag auf der Seite angezeigt. Wenn Sie zu diesem Zeitpunkt sorgfältig gestaltete Inhalte eingeben, sehen Sie sich dies an

<a title="popper.w" onclick="alert(1)">popper.w" onclick="alert(1)</a>

Was ich hier tatsächlich eingegeben habe ist „popper.w“ onclick="alert(1)“, natürlich kannst du oben mehr Inhalt schreiben.

Strategie: Filtern Sie einige Zeichen heraus, die im Attribut abgeschnitten sein könnten. Sowohl einfache als auch doppelte Anführungszeichen im Attribut selbst müssen transkodiert werden.

Schädlicher Code wird als HTML-Code selbst angezeigt (gängige HTML-Editoren). Diese Situation ist am problematischsten, daher werde ich hier kein Beispiel geben.

Strategie: Am besten ist es, die von Benutzern eingegebenen HTML-Tags und Tag-Attribute auf eine Whitelist zu setzen oder gezielt einige Tags und Attribute herauszufiltern, die Schwachstellen aufweisen.

Der Schadcode wird als JSON-Zeichenfolge angezeigt (erstellt neue schädliche JS-Variablen oder sogar ausführbaren Code durch Variablenkürzung). 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 heraus, die im Attribut abgeschnitten sein könnten. Sowohl einfache als auch doppelte Anführungszeichen im Attribut selbst müssen transkodiert werden.

Für CRSF- und Cookie-Hijacking

Funktionen: Sehr gut verborgen. Manchmal wird zuerst die XSS-Sicherheitslücke ausgenutzt und dann der Betrug begangen.

Die Strategie prüft Benutzereingaben per Referrer, Token oder Bestätigungscode.
Versuchen Sie, im Link auf der Seite keine Informationen preiszugeben, die mit der eindeutigen Nummer (Benutzer-ID) des Benutzers in Zusammenhang stehen.
Für Änderungen, Löschungen und Übermittlungen durch den Benutzer werden Post-Operationen am besten verwendet.
Vermeiden Sie Website-weite Cookies. Seien Sie streng hinsichtlich der Domäne, die Cookies setzt.

Ok, ich höre hier auf~

Oben sind einige häufige Sicherheitsprobleme aufgeführt, hauptsächlich aus der Perspektive des JS-Hackings. Mit der kontinuierlichen Entwicklung und dem Fortschritt der Front-End-Technologie können weitere Sicherheitsprobleme auftreten. Für Entwickler können die meisten Probleme während der Entwicklungsphase vermieden werden. Das Beängstigende ist also nicht das Hacken, sondern unsere Nachlässigkeit bei der Sicherheit unserer eigenen Produkte.