Was ist Cross-Site Scripting Prevention?
Cross-Site Scripting Prevention ist der Prozess der Erkennung und Behebung von XSS-Schwachstellen in Ihren Websites oder Webanwendungen, bevor sie die Produktion erreichen. Die Erkennung von XSS-Schwachstellen kann automatisch mithilfe eines automatisierten Schwachstellenscanners oder manuell durch Penetrationstests erfolgen. In diesem Artikel erfahren Sie, wie Sie Cross-Site Scripting verhindern und wie Sie diese sofort implementieren können. Am Ende des Artikels finden Sie auch einen Link zu einem kostenlosen, entwicklerorientierten Schwachstellenscanner, mit dem Sie frühzeitig und häufig Cross-Site-Scripting-Schwachstellen als Teil Ihrer Entwicklungspipelines erkennen und beheben können
In diesem Artikel erfahren Sie, wie Sie Cross-Site-Scripting-Schwachstellen erkennen und beheben können:
- Was ist Cross-Site Scripting Prevention?
- Wie funktioniert Cross-Site Scripting?
- Was sind die Arten von XSS-Angriffen?
- Wie wichtig ist Cross-Site Scripting Prevention?
- Cross Site Scripting protection
- Dynamischen Inhalten entkommen
- Whitelist-Werte
- Implementieren einer Content-Security-Richtlinie
- HTML bereinigen
- Nur-HTTP-Cookies
- XSS-Prävention mit Codebeispielen
- Cross-Site-Scripting-Prävention in Python (Django)
- Cross-Site-Scripting-Prävention in Ruby (Rails)
- Cross-Site-Scripting-Prävention in Java (Java Server Pages)
- Cross-Site-Scripting-Prävention in C # (ASP.NET)
- Cross-Site-Scripting-Prävention im Knoten
- Schnurrbart.js
- Staub.js
- Nunjucks
- Cross-Site-Scripting-Prävention in PHP
- Cross-Site-Scripting-Prävention in AngularJS
- Cross-Site-Scripting-Prävention in Reagieren
- Wie können automatisierte Tools Cross-Site Scripting verhindern?
Wie funktioniert Cross-Site Scripting?
Cross-Site Scripting (XSS) -Angriffe sind eine Form von Injection-Angriffen, bei denen schädliche Skripte in vertrauenswürdige Webanwendungen injiziert werden.
Ein Angreifer kann die Webanwendung verwenden, um bösartigen Code, typischerweise in Form eines browserseitigen Skripts, an einen anderen Endbenutzer zu senden, was zu einem XSS-Angriff führt.
XSS-Sicherheitsanfälligkeiten treten sehr häufig auf, wenn eine Webanwendung Eingaben eines gültigen Benutzers verwendet, die in der generierten Ausgabe enthalten sind, jedoch ohne die entsprechende Validierung oder Codierung.
Wenn das schädliche Skript an den Benutzer gesendet wird, kann sein Browser nicht kategorisch wissen, dass dem Skript nicht vertraut werden sollte, und führt das Skript anschließend aus. Dieses Skript kann dann auf eine Vielzahl von Daten zugreifen, einschließlich Cookies, Sitzungstoken oder anderer vertraulicher Informationen, die vom Browser für diese Website gespeichert werden können.
Was sind die Arten von XSS-Angriffen?
Es gibt drei Haupttypen von XSS-Angriffen:
- Reflektiertes XSS: Bösartiges Skript stammt von der aktuellen HTTP-Anforderung
- Gespeichertes XSS: bösartiges Skript stammt aus der Datenbank der Website
- DOM-basiertes XSS: Hier besteht die Sicherheitsanfälligkeit eher im clientseitigen als im serverseitigen Code.
Wie wichtig ist Cross-Site Scripting Prevention?
Der Schaden durch die Ausnutzung einer XSS-Sicherheitsanfälligkeit hängt von der Sensibilität der Daten ab, die Ihre Site verarbeitet. Hier sind einige Beispiele, in denen Hacker XSS-anfällige Apps ausgenutzt haben:
- Verbreitung von Würmern in sozialen Medien: Facebook, Twitter und YouTube wurden auf diese Weise erfolgreich angegriffen.
- Sitzungsentführung: Bösartiges JavaScript kann die Sitzungs-ID möglicherweise an eine Remote-Site unter der Kontrolle des Hackers senden, sodass der Hacker sich als dieser Benutzer ausgeben kann, indem er eine laufende Sitzung entführt.
- Identitätsdiebstahl: Wenn der Benutzer vertrauliche Informationen wie Kreditkartennummern in eine kompromittierte Website eingibt, können diese Details mit bösartigem JavaScript gestohlen werden.
- Denial-of-Service-Angriffe und Website-Vandalismus.
- Diebstahl sensibler Daten wie Passwörter.
- Finanzbetrug auf Bankenseiten.
Cross-Site Scripting protection
Escape dynamischer Inhalt
Normalerweise wird beim Rendern einer Webseite dynamischer Inhalt in HTML eingebunden. Wenn der dynamische Inhalt nicht ordnungsgemäß behandelt wird, kann ein Angreifer dies verwenden, um einen gespeicherten XSS-Angriff zu konstruieren. Der Angreifer würde ein bearbeitbares Feld missbrauchen, indem er bösartigen JavaScript-Code einfügt, der im Browser ausgewertet wird, wenn ein anderer Benutzer diese Seite besucht.
Möglicherweise möchten Sie nicht, dass Ihre Benutzer HTML-Rohdaten erstellen, es sei denn, Ihre Website ist ein Content-Management-System. Maskieren Sie alle dynamischen Inhalte, die aus einem Datenspeicher stammen, damit der Browser weiß, dass sie als Inhalt von HTML-Tags behandelt werden sollen, im Gegensatz zu rohem HTML.
Das Escaping dynamischer Inhalte besteht im Allgemeinen darin, signifikante Zeichen durch die HTML-Entitätscodierung zu ersetzen:
“ "
# #
& &
‚ '
( (
) )
/ /
; ;
< <
> >
Wie Sie in den folgenden Codebeispielen sehen werden, entkommen die meisten modernen Frameworks standardmäßig dynamischen Inhalten.
Wenn Sie bearbeitbaren Inhalt auf diese Weise umgehen, wird der Inhalt vom Browser niemals als ausführbarer Code behandelt. Dadurch werden die meisten XSS-Angriffe verhindert.
Whitelist-Werte
Wenn ein dynamisches Datenelement nur eine Handvoll gültiger Werte annehmen kann, beschränken Sie die Werte im Datenspeicher. Stellen Sie außerdem sicher, dass Ihre Renderlogik nur bekannte, richtige Werte zulässt.
Ein Beispiel, in dem Sie diesen Ansatz verwenden möchten, besteht darin, einen Benutzer zu bitten, sein Land aus einer Dropdown-Liste auszuwählen, anstatt es manuell eingeben zu müssen.
Implementieren einer Content-Security-Richtlinie
Moderne Browser unterstützen Content-Security-Richtlinien. Inhaltssicherheitsrichtlinien ermöglichen es dem Autor einer Webseite zu steuern, wo JavaScript und andere Ressourcen geladen und ausgeführt werden können.
Damit ein XSS-Angriff möglich ist, muss der Angreifer in der Lage sein, schädliche Skripte auf der Webseite eines Benutzers auszuführen – entweder indem er inline <script> -Tags irgendwo innerhalb des <html> -Tags einer Seite einfügt oder indem er den Browser dazu verleitet, das JavaScript von einer böswilligen Drittanbieter-Domain zu laden.
Wenn Sie eine Content Security-Richtlinie im Antwortheader festlegen, können Sie den Browser anweisen, niemals Inline-JavaScript auszuführen und die Domänen auszuwählen, die JavaScript für eine Seite hosten können:
Content-Security-Policy: script-src 'self' https://apis.google.com
Indem Sie die URLs, von denen Skripte geladen werden können, auf die Whitelist setzen, geben Sie implizit an, dass Inline-JavaScript nicht zulässig ist.
Sie können die Content Security Policy auch in einem <meta>-Tag im <head>-Element einer Seite platzieren:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
Dieser Ansatz ist sehr effektiv beim Schutz Ihrer Benutzer, erfordert jedoch Disziplin, um Ihre Website für einen solchen Header vorzubereiten. Während Inline-Skripte in der modernen Webentwicklung als schlechte Praxis angesehen werden, sind sie auf älteren, älteren Websites üblich.
Erwägen Sie die Verwendung von CSP-Verletzungsberichten, um schrittweise von Inline-Skripten zu migrieren. Durch Hinzufügen einer report-uri-Direktive in Ihrem Richtlinienkopf benachrichtigt Sie der Browser über Richtlinienverletzungen, anstatt die Ausführung von Inline-JavaScript zu verhindern:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
Dies gibt Ihnen die Gewissheit, dass es keine verweilenden Inline-Skripte gibt, bevor Sie sie direkt verbieten.
HTML bereinigen
Für einige Websites besteht die legitime Notwendigkeit, Roh-HTML zu speichern und zu rendern. Wenn auf Ihrer Website Rich Content gespeichert und gerendert wird, müssen Sie eine HTML-Bereinigungsbibliothek verwenden, um sicherzustellen, dass böswillige Benutzer keine Skripte in ihre HTML-Einreichungen einfügen können.
HTTP-only-Cookies
Bösartiges JavaScript kann verwendet werden, um ein Cookie zu stehlen, das die Sitzungs-ID des Benutzers enthält. Es gibt selten einen guten Grund, Cookies in clientseitigem JavaScript zu lesen oder zu manipulieren, also sollten Sie Cookies als HTTP-only markieren, was bedeutet, dass Cookies vom Browser empfangen, gespeichert und gesendet werden, aber nicht von JavaScript geändert oder gelesen werden können.
XSS-Prävention mit Codebeispielen
Cross-Site-Scripting-Prävention in Python (Django)
Vorlagen in Django entkommen standardmäßig HTML, sodass alles, was wie folgt aussieht, im Allgemeinen sicher ist:
**{{ contents }}**
Sie können Escape mit dem Filter | safe überschreiben. Es gibt oft gute Gründe, dies zu tun, aber Sie müssen Code-Reviews für alles durchführen, was diesen Befehl verwendet:
**{{ contents | safe }}**
Beachten Sie, dass HTML-Escaping auch mit dem {% autoescape %} -Tag aktiviert oder deaktiviert werden kann.
Cross-Site-Scripting-Prävention in Ruby (Rails)
Rails-Vorlagen entkommen standardmäßig HTML, sodass alles, was wie folgt aussieht, im Allgemeinen sicher ist:
<%= contents %>
Sie können Escape überschreiben, indem Sie die Raw-Funktion oder den Operator <%== verwenden. Es gibt oft gute Gründe, dies zu tun, aber Sie müssen Code-Reviews für alles durchführen, was diese Funktionen verwendet:
<% raw contents %>
<%== contents %>
Cross-Site Scripting Prevention in Java (Java Server Pages)
Verwenden Sie das c:out-Tag, um HTML sicher zu umgehen:
<c:out value="${contents}">
Die folgenden Schreibweisen in eine Vorlage entkommen HTML nicht, daher sollten Sie sie mit Vorsicht verwenden:
<%= contents %>
${contents}
<%
out.println(contents);
%>
Cross-Site-Scripting-Prävention in C # (ASP.NET)
Verwenden Sie eine der folgenden Funktionen, um HTML sicher zu entkommen (das Formular <%: wurde in ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
Die folgende Art des Schreibens in eine Vorlage entgeht HTML nicht automatisch, daher sollten Sie sie mit Vorsicht verwenden:
<%= contents %>
Verwenden Sie HttpUtility.HtmlEncode(...), wenn Sie HTML manuell maskieren müssen.
Cross-Site-Scripting-Prävention im Knoten
Schnurrbart.js
In Schnurrbart.js, alle Tags in doppelten Schnurrbärten entkommen automatisch HTML:
{{ contents }}
Denken Sie daran, dass Tags in Triple Mustaches HTML nicht entkommen, also verwenden Sie sie mit Vorsicht:
{{{ contents }}}
Staub.js
Schlüssel-Tags automatisch entkommen HTML:
{ contents }
Das Escaping kann jedoch mit dem Operator |s deaktiviert werden. Verwenden Sie dies daher mit Vorsicht
{ contents | s }
Nunjucks
Wenn Auto-Escaping in der Umgebung aktiviert ist, werden Nunjucks Tags für eine sichere Ausgabe automatisch escapen:
{{ contents }}
Inhalte, die mit dem sicheren Filter markiert sind, werden nicht maskiert – verwenden Sie diese Funktion mit Vorsicht:
{{ contents | safe }}
In diesem Fall müssen Tags manuell maskiert werden:
{{ contents | escape }}
Cross-Site Scripting Prevention in PHP
Der echo-Befehl in PHP entweicht HTML standardmäßig nicht, was bedeutet, dass jeder Code wie der folgende, der Daten direkt aus der HTTP-Anforderung abruft, anfällig für XSS-Angriffe ist:
<?php
Echo $_POST;
?>
Cross-Site-Scripting-Prävention in AngularJS
Jeder in geschweiften Klammern geschriebene Inhalt wird automatisch maskiert, sodass Folgendes sicher ist:
<div>{{dynamicContent}}</div>
Beachten Sie, dass Code, der dynamischen Inhalt an das innerHTML Attribut bindet, nicht automatisch maskiert wird:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
Cross-Site-Scripting-Prävention in React
Jeder dynamische Inhalt, der in geschweiften Klammern geschrieben wird, wird in React automatisch maskiert, sodass der folgende Code sicher ist:
render() {
return <div>{dynamicContent}</div>
}
Sie können auch rohen HTML-Code schreiben, indem Sie Inhalte an die dangerouslySetInnerHTML-Eigenschaft binden. Der Name ist kein Zufall, also achten Sie auf einen Code, der wie folgt aussieht:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
Wie können automatisierte Tools Cross-Site Scripting verhindern?
Wie oben erwähnt, kann das Verhindern von Cross-Site-Scripting-Angriffen einfach sein, da viele Frameworks dynamischen Inhalten standardmäßig entkommen. Diese Bequemlichkeit kann jedoch zu Versehentlichkeit und einigen schwerwiegenden Sicherheitsschwächen für Ihre Anwendung und Ihr Unternehmen führen.
Stellen Sie immer sicher, dass Sie Ihre Anwendungen auf Schwachstellen scannen, bevor Sie sie für die Produktion freigeben, idealerweise als Teil Ihrer DevOps- und CI / CD-Pipelines, um Sicherheitslücken bei jedem Build / Commit frühzeitig zu erkennen und zu beheben.
Mit Nexploit, dem Scanner für dynamische Anwendungssicherheitstests von NeuraLegion, können Sie noch heute mit der Automatisierung Ihrer Sicherheitstests beginnen. Entwickelt für Entwickler und ohne Fehlalarme, können Sie es in Ihre Pipelines integrieren, um Sicherheitstests nach links zu verschieben und durch Design sicher zu sein.
Melden Sie sich hier für Ihr KOSTENLOSES Konto an: https://nexploit.app/signup