Einführung in häufige Sicherheitsprobleme bei der Front-End-Entwicklung

Einführung in häufig gestellte Fragen:

(Lernvideo-Sharing: Programmiervideo)

1. Cross-Site-Scripting-Angriff (XSS-Angriff)

XSS (Cross-Site-Scripting), Cross-Site-Scripting-Angriff. XSS ist eine der häufigsten Web-Angriffstechnologien. Unter dem sogenannten Cross-Site-Scripting-Angriff versteht man Folgendes: Wenn Benutzer diese Webseiten durchsuchen, wird der Schadcode ausgeführt Verschiedene Angriffe wie Diebstahl von Cookie-Informationen und Sitzungsentführung:

(1) Eingabefilterung. Vertrauen Sie niemals Benutzereingaben und führen Sie bestimmte Filterungen für vom Benutzer eingegebene Daten durch. Zum Beispiel, ob die eingegebenen Daten dem erwarteten Format entsprechen, z. B. Datumsformat, E-Mail-Format, Telefonnummer

Codeformat usw. Dies kann einen vorläufigen Schutz vor XSS-Schwachstellen bieten. Die oben genannten Maßnahmen schränken lediglich die Webseite ein. Angreifer können die Front-End-Eingabebeschränkungen dennoch umgehen, indem sie Paketerfassungstools wie Fiddler verwenden und die Anforderung zum Einschleusen von Angriffsskripten ändern.

Daher muss der Backend-Server nach Erhalt der vom Benutzer eingegebenen Daten besondere gefährliche Zeichen filtern oder maskieren und diese dann in der Datenbank speichern. (2) Ausgabekodierung. Die vom Server an den Browser ausgegebenen Daten können mithilfe der Sicherheitsfunktionen des Systems verschlüsselt oder maskiert werden, um XSS-Angriffe zu verhindern. In PHP gibt es zwei Funktionen, htmlentities() und htmlspecialchars(), die Sicherheitsanforderungen erfüllen können. Die entsprechende JavaScript-Codierungsmethode kann JavascriptEncode verwenden. (3) Sicherheitskodierung. Die Entwicklung sollte versuchen, das Umschreiben von Web-Client-Dokumenten, die Umleitung oder andere sensible Vorgänge zu vermeiden und die Verwendung von Client-Daten zu vermeiden. Diese Vorgänge sollten so weit wie möglich auf der Serverseite implementiert werden. (4) HttpOnly-Cookie. Die effektivste Verteidigungsmethode, um zu verhindern, dass XSS-Angriffe Benutzercookies stehlen. Wenn eine Webanwendung ein Cookie setzt, setzen Sie ihr Attribut auf HttpOnly.

kann verhindern, dass das Cookie der Webseite durch das böswillige JavaScript des Clients gestohlen wird, und die Cookie-Informationen des Benutzers schützen. (5) WAF (Web Application Firewall), Webanwendungs-Firewall. Ihre Hauptfunktion besteht darin, häufige Web-Schwachstellenangriffe wie Web-Trojaner,

XSS und CSRF zu verhindern. Es wurde von einem Drittunternehmen entwickelt und erfreut sich in Unternehmensumgebungen großer Beliebtheit.

2. Cross-Site Request Forgery (CSRF-Angriff)

CSRF (Cross Site Request Forgery), also Cross-Site Request Forgery, ist ein häufiger Webangriff, mit dem viele Entwickler jedoch nicht vertraut sind. CSRF ist auch die am häufigsten übersehene Art von Website-Angriff in der Web-Sicherheit. Prinzip des CSRF-Angriffs: Der Opferbenutzer des CSRF-Angriffsprozesses meldet sich auf Website A an, gibt persönliche Informationen ein und speichert das vom Server generierte Cookie lokal. Klicken Sie dann auf einen bösartigen Link, den der Angreifer auf Website A erstellt hat, um zur Website

B zu springen, und dann überträgt Website B die Cookie-Informationen des Benutzers, um Website B zu besuchen. Lassen Sie Website A die Illusion erzeugen, dass der Benutzer sie selbst besucht hat, und dann Führen Sie eine Reihe von Schritten durch. Der häufigste Vorgang ist die Übertragung.

Lösung:

(1) Bestätigungscode. Während der Interaktion zwischen der Anwendung und dem Benutzer, insbesondere in Kernschritten wie Kontotransaktionen, muss der Benutzer einen Bestätigungscode eingeben, um die endgültige Anfrage abzuschließen. Unter normalen Umständen sind Verifizierungscodes gut genug, um

CSRF-Angriffe einzudämmen. Das Hinzufügen von Bestätigungscodes verringert jedoch das Benutzererlebnis und die Website kann nicht allen Vorgängen Bestätigungscodes hinzufügen. Daher können Verifizierungscodes nur als Hilfsmittel zum Festlegen von Verifizierungscodes an wichtigen Geschäftspunkten verwendet werden. (2) Empfehlungsprüfung.

HTTP-Referer ist Teil des Headers. Wenn der Browser eine Anfrage an den Webserver sendet, übermittelt er normalerweise die Referrer-Informationen, um dem Server mitzuteilen, von welcher Seite er verlinkt ist

. CSRF-Angriffe können abgewehrt werden, indem die Quelle der Anfrage überprüft wird. Für den Referrer einer normalen Anfrage gelten bestimmte Regeln. Beispielsweise muss der Referrer einer Formularübermittlung eine auf dieser Seite initiierte Anfrage sein. Indem wir also prüfen, ob der Wert des http-Header-Referers

diese Seite ist, können wir feststellen, ob es sich um einen CSRF-Angriff handelt. In einigen Fällen, z. B. beim Springen von https zu http, sendet der Browser den Referrer jedoch aus Sicherheitsgründen nicht und der Server kann dies nicht überprüfen. Wenn andere Websites in derselben Domäne wie diese Website XSS-Schwachstellen aufweisen, können Angreifer schädliche Skripte in andere Websites einschleusen. Opfer, die solche URLs in derselben Domäne eingeben, werden ebenfalls angegriffen. Aus den oben genannten Gründen kann man sich nicht vollständig auf den Referer Check als wichtigstes Mittel zur Verteidigung gegen CSRF verlassen

. Das Auftreten von CSRF-Angriffen kann jedoch durch den Referer Check überwacht werden. (3) Anti-CSRF-Token. Die derzeit relativ vollständige Lösung besteht darin, Anti-CSRF-Token hinzuzufügen, dh beim Senden einer Anforderung ein zufällig generiertes Token als Parameter in der HTTP-Anforderung hinzuzufügen und auf dem Server einen Interceptor einzurichten, um das Token zu überprüfen. Der Server liest den Token-Wert im aktuellen Domänen-Cookie des Browsers und überprüft, ob das Token

in der Anfrage und der Token-Wert im Cookie vorhanden und gleich sind, bevor er es als legitime Anfrage betrachtet. Andernfalls gilt die Anfrage als rechtswidrig und die Dienstleistung wird abgelehnt. Diese Methode ist viel sicherer als die Referrer-Prüfung. Das Token kann nach der Anmeldung des Benutzers generiert und in der Sitzung oder im Cookie platziert werden. Dann nimmt der Server das Token bei jeder Anfrage aus der Sitzung oder dem Cookie und vergleicht es mit dem Anfrage. Token-Vergleich. Aufgrund der Existenz des Tokens kann der Angreifer nicht mehr konstruieren

Erstellen Sie eine vollständige URL, um einen CSRF-Angriff zu implementieren. Wenn jedoch das Problem der Koexistenz mehrerer Seiten gelöst wird und eine bestimmte Seite das Token verbraucht, speichern die Formulare auf anderen Seiten weiterhin das verbrauchte Token, und beim Absenden der Formulare auf anderen Seiten tritt ein Tokenfehler auf.

3. SQL-Injection-Angriff

SQL-Injection (SQL-Injection): Wenn die Anwendung SQL (Structured Query Language, Structured Query Language) an die Backend-Datenbank überträgt, fügt der Angreifer SQL-Befehle in das Webformular ein, um das zu senden oder einzugeben Domänenname Oder die Abfragezeichenfolge der Seitenanforderung und verleiten Sie letztendlich den Server zur Ausführung schädlicher SQL-Befehle

Lösung:

(1) Verhindern Sie den Verlust vertraulicher Systeminformationen. Setzen Sie die php.ini-Option display_errors=off, um zu verhindern, dass sensible Informationsfehler auf der Webseite ausgegeben werden, nachdem ein Fehler im PHP-Skript aufgetreten ist, was Angreifern die Möglichkeit gibt, einen Vorteil daraus zu ziehen. (2) Datenflucht. Setzen Sie die php.ini-Option magic_quotes_gpc=on, wodurch automatisch alle „(einfache Anführungszeichen), „(doppelte Anführungszeichen), (Backslashes), Leerzeichen usw. in den übermittelten Variablen vorangestellt werden. Oder verwenden Sie die Funktion mysql_real_escape( ) oder Die Funktion addslashes() zum Escapen von Eingabeparametern bezieht sich im Allgemeinen auf die Überprüfung, ob die Benutzereingabe dem erwarteten Typ, der Länge, dem Wertebereich oder anderen Formatstandards entspricht Wenn die Eingabe offensichtlich bösartige Inhalte enthält, wird sie bei Verwendung der Whitelist-Verifizierung in der Regel mit der Sicherheitslücke beim Hochladen von Dateien kombiniert. Die Upload-Schwachstelle kann zum direkten Zugriff auf WEBSHELL genutzt werden. Die Upload-Schwachstelle ist auch eine häufige Schwachstelle bei aktuellen Einbrüchen und ermöglicht es Angreifern, gefährliche Inhalte einzuschleusen Code und Ausführung auf dem Server. Das Prinzip der Datei-Upload-Sicherheitslücke: Da der Implementierungscode der Datei-Upload-Funktion das vom Benutzer hochgeladene Dateisuffix und den Dateityp nicht streng einschränkt, ermöglicht er dem Angreifer, beliebige Inhalte in ein Verzeichnis hochzuladen, auf das zugegriffen werden kann Das Web. PHP-Dateien und die Möglichkeit, diese Dateien an den PHP-Interpreter zu übergeben, können Sie jedes PHP-Skript auf dem Remote-Server ausführen

Lösung:

(1) Überprüfen Sie, ob der Server den hochgeladenen Dateityp und das Suffix ermittelt (2 ) Definition. Es dürfen nur Dateien der Typen in der Whitelist hochgeladen werden. (3) Das Datei-Upload-Verzeichnis verhindert, dass Angreifer sekundäre Angriffe durchführen CGI gibt die Eingabeparameter unverändert auf der Seite aus, der Angreifer täuscht den Benutzer, indem er die Eingabeparameter ändert

Detaillierte Einführung:

Website-Sicherheit

.

Das obige ist der detaillierte Inhalt vonEinführung in häufige Sicherheitsprobleme bei der Front-End-Entwicklung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!