Schutz Ihrer Benutzer vor DOM-basierten XSS-Angriffen

Schutz Ihrer Benutzer vor DOM-basierten XSS-Angriffen

Cross-Site Scripting (XSS) ist eine der häufigsten Methoden, um Websites anzugreifen. XSS-Sicherheitsanfälligkeiten ermöglichen es einem böswilligen Benutzer, beliebige JavaScript-Teile auszuführen, wenn andere Benutzer Ihre Website besuchen.

XSS ist die häufigste öffentlich gemeldete Sicherheitslücke und Teil des Toolkits jedes Hackers.

Risiken

Prävalenz Selten

Ausnutzbarkeit einfach

Auswirkungen schädlich

DOM-basierte XSS-Angriffe haben alle Risiken, die mit den anderen Arten von XSS-Angriffen verbunden sind, mit dem zusätzlichen Bonus, dass sie von der Serverseite aus nicht erkannt werden können.Jede Seite, die URI-Fragmente verwendet, ist möglicherweise durch XSS-Angriffe gefährdet.

Schutz

Der Schutz vor DOM-basierten XSS-Angriffen besteht darin, zu überprüfen, ob yourJavaScript URI-Fragmente nicht auf unsichere Weise interpretiert. Es gibt eine Reihe von Möglichkeiten, dies sicherzustellen.

Verwenden Sie ein JavaScript-Framework

Frameworks wie AngularJS und React verwenden Vorlagen, die die Erstellung von Ad-hoc-HTML zu einer expliziten (und seltenen) Aktion machen. Dadurch wird Ihr Entwicklungsteam zu Best Practices geführt und unsichere Vorgänge können leichter erkannt werden.

AngularJS

In Angular wird jeder dynamische Inhalt, der in geschweiften Klammern geschrieben wird, automatisch maskiert, so dass Folgendes sicher ist:

 <div>{{dynamicContent}}</div>

Seien Sie vorsichtig bei Code, der dynamischen Inhalt an das Attribut innerHTML bindet, da dieser nicht automatisch maskiert wird:

 <div ="dynamicContent"></div> <div innerHTML="{{dynamicContent}}"></div>
React

In React wird jeder dynamische Inhalt, der in geschweiften Klammern geschrieben wird, automatisch maskiert, sodass Folgendes sicher ist:

render() { return <div>{dynamicContent}</div>}

Mit React können Sie rohen HTML-Code schreiben, indem Sie Inhalte an die dangerouslySetInnerHTML -Eigenschaft binden, die benannt ist, um Sie an das Sicherheitsrisiko zu erinnern! Achten Sie auf Code, der wie folgt aussieht:

render() { return <div dangerouslySetInnerHTML={ __html: dynamicContent } />}
Überprüfen Sie Ihren Code sorgfältig

Manchmal ist ein vollständiges JavaScript-Framework zu schwer site.In in diesem Fall müssen Sie regelmäßig Code-Reviews durchführen, um locationsthat reference window.location.hash . Erwägen Sie, vereinbarte Codierungsstandards dafür zu entwickeln, wie URI-Fragmente geschrieben und interpretiert werden sollen, und zentralisieren Sie diese Logik in einer Kernbibliothek.

Wenn Sie jQuery verwenden, überprüfen Sie sorgfältig jeden Code, der die Funktionhtml(...) verwendet. Wenn Sie clientseitig rohen HTML-Code auf der Rückseite nicht vertrauenswürdiger Eingaben erstellen, liegt möglicherweise ein Problem vor, unabhängig davon, ob die Eingabe von einem URI-Fragment stammt oder nicht. Verwenden Sie nach Möglichkeit die Funktion text(...).

Wenn Sie nur die nativen DOM-APIs verwenden, vermeiden Sie die Verwendung der folgenden Eigenschaften und Funktionen:

  • innerHTML
  • outerHTML
  • document.write

Legen Sie stattdessen Textinhalte nach Möglichkeit innerhalb von Tags fest:

  • textContent
JSON sorgfältig analysieren

Werten Sie JSON nicht aus, um es in native JavaScript-Objekte zu konvertieren, z. B. mithilfe der Funktion eval(...). Verwenden Sie stattdessen JSON.parse(...) .

Erkennen Sie unsicheren Code mithilfe von Entwicklungstools

Die Burp Suite der Sicherheitsfirma PortSwigger kann verwendet werden, um DOM-basierte Schwachstellen zu erkennen.

Verwenden Sie überhaupt keine URI-Fragmente!

Der sicherste Code ist der Code, der nicht vorhanden ist. Wenn Sie keine URI-Fragmente verwenden müssen, tun Sie dies nicht! Schreiben Sie einen Komponententest, um Ihr JavaScript nach Erwähnungen von window.location.hash zu durchsuchen, und lassen Sie es fehlschlagen, wenn das Muster gefunden wird. Wenn URI-Fragmente verwendet werden müssen, können Sie besprechen, wie Sie deren sichere Verwendung sicherstellen können.

Implementieren einer Content-Security-Richtlinie

Moderne Browser unterstützen Content-Security-Richtlinien, die es dem Autor einer Webseite ermöglichen, zu steuern, wo JavaScript (und andere Ressourcen) geladen und ausgeführt werden können. XSS-Angriffe beruhen darauf, dass der Angreifer böswillige Skripte auf der Webseite eines Benutzers ausführen kann – 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.

Durch Festlegen einer Inhaltssicherheitsrichtlinie im Antwortheader können Sie den Browser auffordern, niemals Inline-JavaScript auszuführen und zu sperren, welche Domänen JavaScript für eine Seite hosten können:

Inhalt-Sicherheit-Politik: script-src ’selbst‘ https://apis.google.com

Indem Sie die URIs, von denen Skripte geladen werden können, auf die Whitelist setzen, geben Sie implizit an, dass Inline-JavaScript nicht zulässig ist.

Die Inhaltssicherheitsrichtlinie kann auch in einem <meta> -Tag im <head> -Element der Seite festgelegt werden:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">

Dieser Ansatz schützt Ihre Benutzer sehr effektiv! Es kann jedoch erforderneine beträchtliche Menge an Disziplin, um Ihre Website für einen solchen Header bereit zu machen.Inline-Scripts-Tags gelten in der modernen Webentwicklung als schlechte Praxis – das Mischen von Inhalt und Code macht die Wartung von Webanwendungen schwierig -, sind jedoch auf älteren Websites üblich.

Um schrittweise von Inline-Skripten zu migrieren, sollten Sie die Verwendung VONCSP. Reports.By wenn Sie eine report-uri -Direktive in Ihren Richtlinienkopf einfügen, werden Sie vom Browser über Richtlinienverletzungen informiert, anstatt die Ausführung von Inline-JavaScript zu verhindern:

Inhaltssicherheitsrichtlinie Nur für Berichte: script-src ’self‘; bericht-uri http://example.com/csr-reports

Dies gibt Ihnen die Gewissheit, dass es keine verweilenden Inline-Skripte gibt,bevor Sie sie direkt verbieten.

Weiterführende Literatur

  • Wie Cross-Site Scripting funktioniert
  • Eine Einführung in die Content Security Policy
  • CSP (Content Security Policy) im Mozilla Developer Network
  • DOM Based Cross-site Scripting Vulnerability
  • Content Security Policy Explained
Cross-Site Scripting

Reflektiertes XSS

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.