Detaillierte Einführung in die Front-End-Sicherheit und wie man sie verhindert

Mit der Entwicklung des Internets sind verschiedene WEB-Anwendungen immer komplexer geworden, um den unterschiedlichen Bedürfnissen der Benutzer gerecht zu werden, aber mit ihnen gehen auch verschiedene Netzwerksicherheitsprobleme einher. Als Front-End-Entwicklungsbranche können wir uns diesem Problem nicht entziehen. Deshalb werde ich heute kurz über die WEB-Frontend-Sicherheit sprechen und wie man sie verhindert.

Welche Formen von Front-End-Angriffen gibt es zunächst und wie können wir sie verhindern?

1. XSS-Angriff

XSS ist eine Computersicherheitslücke, die häufig in Webanwendungen auftritt und es böswilligen Webbenutzern ermöglicht, Code in Seiten einzufügen, die für andere Benutzer verfügbar sind. Zu diesen Codes gehören beispielsweise HTML-Code und clientseitige Skripte. Angreifer nutzen XSS-Schwachstellen, um die Zugriffskontrolle zu umgehen – beispielsweise die Same-Origin-Richtlinie (same origin policy). Diese Art von Sicherheitslücke ist weithin bekannt geworden, da sie von Hackern genutzt wird, um noch schädlichere Phishing-Angriffe (Phishing) zu schreiben.

Zu den Gefahren von XSS-Angriffen gehören:

1. Diebstahl verschiedener Benutzerkonten, wie Maschinenanmeldekonten, Benutzer-Online-Banking-Konten und verschiedene Administratorkonten

2. Kontrolle Unternehmensdaten, einschließlich der Möglichkeit, sensible Unternehmensdaten zu lesen, zu manipulieren, hinzuzufügen und zu löschen

3. Diebstahl wichtiger Unternehmensinformationen mit kommerziellem Wert

4. Illegale Übertragungen

5. Erzwingen des Versendens von E-Mails

6. Website-Hänger

7. Steuerung des Computers des Opfers, um Angriffe auf andere Websites zu starten

Spezifische Erscheinungsformen von XSS-Angriffen:

　1. JavaScript-Code-Injektion

Das Folgende ist die Codeseite:

Die Funktion dieses Codes besteht darin, die Zeichenfolge in die erste einzufügen Eingabefeld, Ausgabe in das zweite Eingabefeld, wir geben 1 ein, dann ist der Wert in der zweiten Eingabe 1. Unten sind Screenshots der Seite und des Quellcodes (hier gebe ich den folgenden Code zum Testen ein)

<SCRIPT>alert(&#39;xss&#39;)</SCRIPT>

Sie können offensichtlich sehen, dass es kein Popup-Dialogfeld gibt. Werfen Sie einen Blick auf die Quelle Code

Wir sehen, dass die von uns eingegebene Zeichenfolge an das Wertattribut im Eingabe-Tag in Zeile 15 ausgegeben und als Wert in Wert angezeigt wird, also gibt es keine Popup-Fenster. Was sollen wir jetzt tun? Schlaue Leute haben herausgefunden, dass man vor

<SCRIPT>alert(&#39;xss&#39;)</SCRIPT>

ein „>“ einfügen kann. Das Ergebnis sollte also

Das Fenster öffnet sich erfolgreich.

Wir sehen, dass ein zweites Eingabefeld folgt durch eine „>-Zeichenfolge. Warum passiert das? Werfen wir einen Blick auf den Quellcode

Lösung: Derzeit besteht die einfachste Präventionsmethode darin, alle Front- Ausgabedaten beenden. Sicher, obwohl angezeigt wird, dass es ein Skript-Tag gibt, werden die linken und rechten spitzen Klammern (>2. Verwendung von append

Im vorherigen Abschnitt haben wir die linken und rechten spitzen Klammern des Skript-Tags verhindert, aber kluge Hacker haben trotzdem einen guten Weg gefunden, es zu knacken das, einfach geben Das Zuweisen eines Teils von js zu innerHTML kann nicht ausgeführt werden. Beispiel:

<br/>

Dies kann jedoch mit dem Append von jQuery erfolgen. Der Grund dafür ist, dass JQuery das Skript-Tag darin findet, wenn das Append-Element in ein Fragment umgewandelt wird, und es dann mit eval erneut ausführt. Die von jquerys Append verwendete Methode ist ebenfalls innerHTML. InnerHTML konvertiert Unicode-Codes in Zeicheneinheiten.

Anhand der Kombination dieser beiden Arten von Wissen können wir schließen, dass die Website Append verwendet, um Dom-Operationen auszuführen. Wenn es sich um ein Feld handelt, über das wir uns entscheiden können, können wir die linken und rechten spitzen Klammern mithilfe von Unicode verschleiern Code, etwa so: „u003cscriptu003ealert('xss');“. Beim nächsten Escape wird das als u003 getarnte

3. Wiederverwendung des img-Tags

Das img-Tag ruft onerror für das Element auf, wenn das Laden des Bildes fehlschlägt. So können wir angreifen.

Aber was ist, wenn wir die Adresse dieses Bildes anders schreiben?

Der Quellcode hat sich zu diesem Zeitpunkt geändert Denn --src ist leer, aber wenn ein Fehler auftritt, wird der injizierte Code ausgeführt. Wenn wir die Seite aktualisieren, werden wir feststellen, dass die Codeinjektion erfolgreich war und weiterhin maskiert werden muss.

2. CSRF-Angriff

Was ist ein CSRF-Angriff?

　CSRF (Cross-site request forgeryCross -Site Request Forgery, auch bekannt als „One Click Attack“ oder Session Riding, oft als CSRF oder XSRF abgekürzt, ist eine böswillige Nutzung der Website , die von Hackern verwendet wird, werden die Vorgänge, die Sie beim Besuch der Website des Hackers ausführen, auf anderen Websites ausgeführt (z. B. auf der Website der von Ihnen genutzten Online-Bank)

Mit get

Um Ärger zu vermeiden, werden wir normalerweise einige Daten, die übermittelt werden sollten, in einer Get-Anfrage zusammenfassen. Wie jeder weiß, verstößt dies nicht nur gegen die HTTP-Standards, sondern kann auch von Hackern verwendet werden

Zum Beispiel gibt es auf der Website, die Sie entwickelt haben, eine Funktion zum Kauf von Waren. Sie haben sie wie folgt entwickelt:

Dann kann die Website des Hackers wie folgt entwickelt werden:

In diesem Fall muss der Benutzer die Website des Hackers nur einmal besuchen, was tatsächlich der Fall ist äquivalent dazu, dass der Vorgang einmal auf Ihrer Website durchgeführt wurde.

Daher muss unsere tägliche Entwicklung weiterhin dem Einreichungsgeschäft folgen und die Postanforderung strikt befolgen, geschweige denn verwenden jsonp, um die Übermittlungsschnittstelle zu machen.

2. Wenn Sie Post-Anfragen zur Abwicklung wichtiger Geschäfte verwenden, gibt es immer noch eine Möglichkeit, sie zu knacken wie folgt:

Der Hacker-Code lautet wie folgt:

Nachher Klicken, der Benutzer hat eingereicht, aber selbst niemand weiß, wie man sich gegen diese Situation verteidigen kann.

Der einfachste Weg besteht darin, einen Bestätigungscode hinzuzufügen, damit die Website des Hackers die Bestätigung nicht erhalten kann Dies wird jedoch die Übermittlungserfahrung des Benutzers beeinträchtigen, insbesondere bei einigen häufigen Vorgängen. Wenn der Benutzer immer aufgefordert wird, den Bestätigungscode einzugeben, ist dies sehr ärgerlich Die Möglichkeit besteht darin, das Token auf der von ihm besuchten Seite herunterzuladen. Alle Eingaben des Benutzers müssen das auf dieser Seite generierte Token mitbringen. Das Wesentliche dieser Methode ist die Verwendung des Bestätigungscodes. Das gleiche Token wird für jede Sitzung auf der gesamten Seite verwendet. Bei vielen Post-Vorgängen können Entwickler automatisch das Token der aktuellen Seite verwenden. Wenn die Token-Überprüfung fehlschlägt, wird bewiesen, dass die Übermittlung nicht von dieser Website erfolgt Der Prozess wird beendet, wenn das Token tatsächlich für diese Website generiert wird.

Der Code lautet wie folgt:

trägt das Token nicht wird von jeder Sitzung dieser Site generiert, sodass die Übermittlung fehlschlägt.

Das Website-Formular dieser Website trägt automatisch das von dieser Website generierte Token

Wenn Sie die Webseite dieser Website zum erneuten Senden verwenden, verwenden Sie

Natürlich sind die oben genannten Beispiele nur Beispiele. Die spezifische Token-Generierung muss je nach Sitzung und Benutzer-ID geändert werden. Wenn Sie der Meinung sind, dass Ihre Website auch ein Token hinzufügen muss, wenden Sie sich bitte an Baidu.

3. Netzwerk-Hijacking-Angriff

Oft greift unsere Website nicht direkt auf unseren Server zu, sondern durchläuft viele Proxy-Ebenen. Wenn bei einem bestimmten Link die Daten von Entführern auf der Zwischen-Proxy-Ebene abgefangen werden, können sie vertrauliche Daten erhalten Passwörter für Benutzer Ihrer Website. Beispielsweise verbinden sich unsere Benutzer oft mit einem seltsamen WLAN in verschiedenen Restaurants. Wenn es sich bei diesem WLAN um ein von einem Hacker eingerichtetes Hotspot-WLAN handelt, kann der Hacker auf alle vom Benutzer gesendeten und empfangenen Daten zugreifen. Hier wird Webmastern empfohlen, https zur Verschlüsselung ihrer Websites zu verwenden. Auf diese Weise können Hacker die Daten der Website nicht entschlüsseln, selbst wenn sie abgerufen werden können.

Wenn Ihre Website nicht mit https verschlüsselt wurde, verwenden Sie im Formularübermittlungsteil am besten eine asymmetrische Verschlüsselung, also eine clientseitige Verschlüsselung, die nur vom Server entschlüsselt werden kann. Auf diese Weise kann der Entführer in der Mitte nicht an die tatsächlichen Informationen des verschlüsselten Inhalts gelangen.

4. Konsolen-Injektionscode

Ich weiß nicht, ob Ihnen die Warnmeldung auf der offiziellen Tmall-Website-Konsole aufgefallen ist, wie in Abbildung 4.1 dargestellt Hacker verleiten Benutzer dazu, Dinge in die Konsole einzufügen (und schikanieren unerfahrene Benutzer, die den Code nicht verstehen). Sie können beispielsweise einen Artikel in Moments veröffentlichen, in dem es heißt: „Solange Sie Tmall besuchen, drücken Sie F12 und fügen Sie den folgenden Inhalt ein.“ , Sie können „xx Yuan Geschenk“ usw. erhalten, dann werden einige Benutzer es wirklich bedienen und sie werden nicht wissen, dass ihre Privatsphäre offengelegt wurde.

Dieser Ansatz von Tmall warnt Benutzer auch davor, dies zu tun. Es scheint, dass die Front-End-Sicherheit von Tmall ebenfalls sehr gut ist. Diese Art von Angriff ist jedoch in der Minderheit, also schauen Sie einfach mal rein. Wenn Sie tatsächlich feststellen, dass einige Benutzer auf diese Weise angegriffen werden, denken Sie daran, an die Lösung von Tmall zu denken.

5. Angeln

Phishing ist ebenfalls eine sehr alte Angriffsmethode, aber es handelt sich nicht wirklich um einen Front-End-Angriff. Aber schließlich handelt es sich um einen Angriff auf Seitenebene, also lasst uns gemeinsam darüber reden. Ich glaube, dass viele Leute diese Erfahrung machen werden. Jemand in der QQ-Gruppe hat über einen Teilzeitjob gepostet, über einen Ausflug ins Ausland und den Verkauf seines Hauses und Autos. Die Details finden Sie in meinem QQ-Bereich und so weiter. Nachdem ich es geöffnet hatte, fand ich ein QQ-Login-Feld. Tatsächlich wusste ich, dass es sich nicht um QQ handelte, aber es war dem QQ-Login sehr ähnlich Benutzername und Passwort wurden daher nicht bei QQ angemeldet. Der Name und das Passwort wurden an jemanden gesendet.

Tatsächlich wird diese Methode auch im Frontend verwendet. Versuchen wir als nächstes, das Frontend zu verwenden, um ein realistisches Angeln durchzuführen.

1. Zuerst teilen wir einen Artikel im xx-Bereich und locken dann andere zum Klicken an.

2 Als nächstes haben wir stillschweigend die umgeleitete Quellwebseitenadresse auf der Website „cheat.php“ geändert.

Nachdem der Benutzer unsere betrügerische Website besucht hat, hat sich daher stillschweigend die vorherige Registerkarte geändert und wir haben sie stillschweigend durch eine Phishing-Website ersetzt, um den Benutzer dazu zu verleiten, seinen Benutzernamen, sein Passwort usw. einzugeben.

3 Unsere Phishing-Website ist als XX-Leerzeichen getarnt und ermöglicht Benutzern die Eingabe ihres Benutzernamens und Passworts

Diese Phishing-Methode ist interessanter. Der Punkt ist Wir vergleichen Es ist schwierig, diese Art von Angriff zu verhindern. Wir können nicht alle Seitenlinks mit js öffnen. Ändern Sie daher entweder den externen Link-Sprunglink in den aktuellen Seitensprung oder geben Sie dem Benutzer eine Eingabeaufforderung, wenn die Seite entladen wird, oder ändern Sie alle Sprünge auf der Seite in window.open und befolgen Sie beim Öffnen die meisten Bemühungen zur Phishing-Prävention und -Kontrolle haben das gleiche Ziel: Wir müssen das Sicherheitsbewusstsein der Internetnutzer verbessern.

6. Worauf sollten wir bei der täglichen Entwicklung achten

Bei der Entwicklung müssen wir uns vor benutzergenerierten Inhalten hüten und schichtweise vorgehen? Ebenenerkennung der vom Benutzer eingegebenen Informationen. Achten Sie auf die Filterung des Ausgabeinhalts des Benutzers (Escape usw.) und denken Sie daran, die Übertragung wichtiger Inhalte zu verschlüsseln (sei es mit https oder durch die Verschlüsselung selbst).

Anfragen abrufen und veröffentlichen Sie müssen sich strikt an die Spezifikationen halten, sie nicht verwechseln und nicht mit JSONP einige gefährliche Übermittlungen durchführen.

Bitte verwenden Sie die in der URL enthaltenen Informationen mit Vorsicht. Denken Sie immer daran, wo Ihre Website gefährlich sein könnte.

Das Obige dreht sich alles um die Front-End-Sicherheit. Für weitere Front-End-Probleme besuchen Sie bitte die chinesische PHP-Website: https://www.php.cn/

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in die Front-End-Sicherheit und wie man sie verhindert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!