Heim  >  Artikel  >  Web-Frontend  >  JavaScript-Injection-Angriff

JavaScript-Injection-Angriff

高洛峰
高洛峰Original
2016-11-28 15:49:411838Durchsuche

Was ist ein JavaScript-Injection-Angriff?
Eine Website ist immer dann anfällig für JavaScript-Injection-Angriffe, wenn sie Benutzereingaben akzeptiert und diesen Inhalt erneut anzeigt. Lassen Sie uns eine bestimmte Anwendung untersuchen, die anfällig für JavaScript-Injection-Angriffe ist. Nehmen wir an, Sie haben eine Website für Kundenfeedback erstellt. Kunden können die Website besuchen und Feedback zum Produkt abgeben. Wenn ein Kunde Feedback sendet, werden die Feedbackinformationen erneut auf der Feedbackseite angezeigt.

Kundenfeedback-Website ist eine einfache Website. Leider ist diese Website anfällig für JavaScript-Injection-Angriffe.

Angenommen, der folgende Text wird in ein Kundenfeedbackformular eingegeben:


Dieser Text stellt ein JavaScript-Skript dar, das ein Warnmeldungsfeld anzeigt. Nachdem jemand dieses Skript an ein Kunden-Feedback-Formular gesendet hat, wird jedem, der die Kunden-Feedback-Site besucht, die Nachricht

angezeigt. Sie könnten auch denken, dass andere durch JavaScript-Injection-Angriffe keinen Schaden anrichten werden.

Ihre erste Reaktion auf einen JavaScript-Injection-Angriff könnte darin bestehen, ihn zu ignorieren. Man könnte denken, dass ein JavaScript-Injection-Angriff nur ein harmloser Angriff ist. Leider ist es bekannt, dass Hacker JavaScript in Websites einschleusen, um Schaden anzurichten. Cross-Site-Scripting-Angriffe (XSS) können mithilfe von JavaScript-Injection-Angriffen durchgeführt werden. Bei einem Cross-Site-Scripting-Angriff können vertrauliche Benutzerinformationen gestohlen und an eine andere Website gesendet werden.

Hacker können beispielsweise JavaScript-Injection-Angriffe nutzen, um Cookie-Werte aus den Browsern anderer Benutzer zu stehlen. Wenn vertrauliche Informationen (wie Passwörter, Kreditkartenkontonummern oder Sozialversicherungsnummern) in Browser-Cookies gespeichert werden, können Hacker JavaScript-Injection-Angriffe verwenden, um diese Informationen zu stehlen. Oder wenn ein Benutzer vertrauliche Informationen in ein Formularfeld auf einer Seite eingibt und die Seite durch einen JavaScript-Angriff kompromittiert wird, kann ein Hacker das eingeschleuste JavaScript verwenden, um die Formulardaten abzurufen und an eine andere Website zu senden.

Bitte achten Sie besonders darauf. Nehmen Sie JavaScript-Injection-Angriffe ernst und schützen Sie die vertraulichen Informationen Ihrer Benutzer. In den nächsten beiden Teilen besprechen wir zwei Techniken zum Schutz von ASP.NET MVC-Anwendungen vor JavaScript-Injection-Angriffen.

Methode 2: HTML-Codierung vor dem Schreiben in die Datenbank

Zusätzlich zur Verwendung von HTML zum Codieren von Daten bei der Anzeige in einer Ansicht können Sie HTML auch zum Codieren von Daten verwenden, bevor Sie sie an die Datenbank senden.

Die zweite Methode trifft genau auf den Controller in Listing 4 zu.

Zum Beispiel:

public ActionResult Create(string message)

{

// Feedback hinzufügen
var newFeedback = new Feedback();
newFeedback.Message = Server.HtmlEncode(message);
newFeedback.EntryDate = DateTime.Now;
db.Feedbacks.InsertOnSubmit(newFeedback);
db.SubmitChanges();

// Redirect

return RedirectToAction(“Index”);

}

Bitte beachten Sie, dass der Wert von Message in der Create()-Operation HTML-codiert wird, bevor er an die Datenbank übermittelt wird. Wenn die Nachricht erneut in einer Ansicht angezeigt wird, ist die Nachricht HTML-codiert, sodass in die Nachricht eingefügtes JavaScript nicht ausgeführt wird.

Zusammenfassung
Im Allgemeinen bevorzugen Benutzer die erste in diesem Tutorial besprochene Methode und nicht die zweite Methode. Das Problem beim zweiten Ansatz besteht darin, dass Sie letztendlich HTML-codierte Daten in der Datenbank haben. Mit anderen Worten: Die Daten in der Datenbank enthalten seltsame Zeichen. Was ist der Schaden? Wenn

Sie Datenbankdaten in einer anderen Form als einer Webseite anzeigen müssen, werden Sie auf Probleme stoßen. Beispielsweise können Daten in einer Windows Forms-Anwendung nicht einfach angezeigt werden.




Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn