Web Security Scanner-Ergebnisse beheben

>

Ergebnisse von Web Security Scanner interpretieren, reproduzieren und beheben

Sicherheitslückenklassen

Web Security Scanner erkennt folgende Sicherheitslücken:

  • Cross-Site-Scripting (XSS)
  • Flash Injection
  • Gemischte Inhalte
  • Klartext-Passwörter
  • Verwendung unsicherer JavaScript-Bibliotheken

Wird eine dieser Sicherheitslücken erkannt, wird das Ergebnis hervorgehoben, sodass Sie die zugehörigen Details aufrufen können.

Auswirkungen auf Logs

Traces von Web Security Scanner-Scans werden in Ihren Logdateien angezeigt. Web Security Scanner generiert beispielsweise Anfragen für ungewöhnliche Strings wie ~sfi9876 und /sfi9876. Dadurch kann der Scan die Fehlerseiten Ihrer Anwendung untersuchen. Diese absichtlich ungültigen Seitenanfragen werden in Ihren Logs angezeigt.

Web Security Scanner-Ergebnisse beheben

Im Folgenden finden Sie Informationen zum Beheben verschiedener Arten von Web Security Scanner-Ergebnissen.

XSS

Der XSS-Injektionstest (Cross-Site-Script) für Web Security Scanner simuliert einen Injektionsangriff. Dazu wird ein harmloser Teststring in Felder eingefügt, die von Nutzern bearbeitet werden können, und es werden verschiedene Nutzervorgänge durchgeführt. Benutzerdefinierte Detektoren beobachten Browser und DOM, um festzustellen, ob eine Injektion erfolgreich war und welches Potenzial für Angriffe besteht.

Wenn das im Teststring enthaltene JavaScript ordnungsgemäß ausgeführt werden kann, wird der Chrome-Debugger gestartet. Wenn ein Teststring ausgeführt werden kann, ist es möglich, JavaScript auf der Seite zu injizieren und auszuführen. Wenn Angreifer diese Sicherheitslücke erkennen, können sie beliebiges JavaScript ausführen und sich dabei als der Nutzer (bzw. das Opfer) ausgeben, der auf einen schädlichen Link klickt.

Unter bestimmten Umständen kann die zu testende Anwendung den Teststring ändern, bevor er vom Browser geparst wird. Beispielsweise kann die Anwendung die Eingabe validieren oder die Größe eines Felds begrenzen. Wenn der Browser versucht, diesen geänderten Teststring auszuführen, kann ein Fehler auftreten. Daraufhin wird wahrscheinlich ein JavaScript-Ausführungsfehler ausgegeben. Dies ist ein Injektionsproblem, das jedoch möglicherweise nicht ausgenutzt werden kann.

Um dieses Problem zu beheben, prüfen sie, ob das Problem eine XSS-Sicherheitslücke ist. Prüfen Sie dazu manuell, ob die Teststringänderungen geändert werden können. Weitere Informationen hierzu finden Sie unter Cross-Site-Scripting.

Es gibt verschiedene Möglichkeiten, dieses Problem zu beheben. Wir empfehlen, auf alle Ausgaben Escaping anzuwenden und ein Vorlagensystem zu verwenden, das kontextabhängiges automatisches Escaping unterstützt.

XSS_ANGULAR_CALLBACK

Eine XSS-Sicherheitslücke (Cross-Site Scripting) in AngularJS-Modulen kann auftreten, wenn ein vom Nutzer bereitgestellter String von Angular interpoliert wird. Das Einfügen von vom Nutzer bereitgestellten Werten in eine AngularJS-Interpolation kann folgende Angriffe ermöglichen:

  • Ein Angreifer kann beliebigen Code in die von Browsern dargestellte Seite einfügen.
  • Ein Angreifer kann Aktionen im Namen des betroffenen Browsers im Original der Seite ausführen.

Klicken Sie nach dem Scan in der Google Cloud Console auf den Link zum Reproduzieren, um diese mögliche Sicherheitslücke zu reproduzieren. Dadurch wird entweder direkt eine Warnmeldung geöffnet oder es wird der String XSSDETECTED eingefügt, um nachzuweisen, dass bei einem Angriff Code ausgeführt werden kann. Im Falle einer Injektion können Sie die Entwicklertools Ihres Browsers öffnen und nach XSSDETECTED suchen, um die genaue Position der Injektion zu finden.

XSS_ERROR

Ein XSS_ERROR-Ergebnis ist ein möglicher XSS-Programmfehler aufgrund von JavaScript-Fehlern. Unter bestimmten Umständen kann die zu testende Anwendung den Teststring ändern, bevor dieser vom Browser geparst wird. Wenn der Browser versucht, diesen geänderten Teststring auszuführen, kann ein Fehler auftreten. Daraufhin wird wahrscheinlich ein JavaScript-Ausführungsfehler ausgegeben. Dies ist ein Injektionsproblem, das jedoch möglicherweise nicht ausgenutzt werden kann.

Um dieses Problem zu beheben, prüfen sie, ob das Problem eine XSS-Sicherheitslücke ist. Prüfen Sie dazu manuell, ob die Teststringänderungen geändert werden können. Weitere Informationen hierzu finden Sie unter Cross-Site-Scripting.

ROSETTA_FLASH

Web Security Scanner erkennt möglicherweise, dass der Wert eines Anfrageparameters zu Beginn einer Antwort wieder reflektiert wird, z. B. in Anfragen mit JSONP. Dies wird auch als Flash-Injektion bezeichnet. Unter bestimmten Umständen kann ein Angreifer den Browser dazu veranlassen, die Antwort als Flash-Datei auszuführen, die von der anfälligen Webanwendung bereitgestellt wird.

Zur Behebung dieses Problems sollten Sie am Anfang einer HTTP-Antwort keine vom Nutzer anpassbaren Daten einfügen.

MIXED_CONTENT

Web Security Scanner überwacht den HTTP-Traffic passiv und erkennt, wenn eine Anfrage für eine JavaScript- oder CSS-Datei über HTTP im Zusammenhang mit einer HTTPS-Seite ausgeführt wird. In diesem Szenario könnte ein Man-in-the-Middle-Angreifer die HTTP-Ressource manipulieren und vollen Zugriff auf die Website erhalten, die die Ressource lädt.

Um dieses Problem zu beheben, sollten Sie relative HTTP-Links verwenden und beispielsweise http:// durch // ersetzen.

OUTDATED_LIBRARY

Web Security Scanner erkennt möglicherweise, dass die Version einer enthaltenen Bibliothek ein Sicherheitsproblem enthält. Cloud Security Scanner ist ein signaturbasierter Scanner, der versucht, die Version der verwendeten Bibliothek zu identifizieren und diese mit einer bekannten Liste von anfälligen Bibliotheken abzugleichen. Wenn die Versionserkennung fehlschlägt oder die Bibliothek manuell repariert wurde, können falsch positive Meldungen auftreten.

Aktualisieren Sie die enthaltene Bibliothek auf eine bekannte sichere Version, um dieses Problem zu beheben.

CLEAR_TEXT_PASSWORD

Web Security Scanner erkennt möglicherweise, dass eine Anwendung ein Passwortfeld als Klartext überträgt. Ein Angreifer könnte den Netzwerktraffic abhören und das Passwortfeld ausspähen.

So schützen Sie vertrauliche Informationen, die zwischen Client und Server übertragen werden:

  • Verwenden Sie TLS/SSL-Zertifikate.
  • Verwenden Sie auf Seiten mit Passwortfeldern immer HTTPS.
  • Stellen Sie sicher, dass Formularaktionsattribute immer auf eine HTTPS-URL verweisen.

INVALID_CONTENT_TYPE

Web Security Scanner erkennt möglicherweise, dass eine Ressource geladen wurde, die nicht mit dem Content-Type-HTTP-Header der Antwort übereinstimmt. In diesem Szenario gibt die Anwendung vertrauliche Inhalte mit einem ungültigen Inhaltstyp oder ohne X-Content-Type-Options: nosniff-Header zurück.

Sie können die Sicherheitslücke beheben, indem Sie darauf achten, dass die folgenden Voraussetzungen erfüllt sind:

  • JSON-Antworten werden mit dem Content-Type-Header application/json bereitgestellt.
  • Andere vertrauliche Antworten werden mit den geeigneten MIME-Typen bereitgestellt.
  • Inhalte werden mit dem HTTP-Header X-Content-Type-Options: nosniff bereitgestellt.

INVALID_HEADER

Web Security Scanner erkennt möglicherweise, dass ein Sicherheitsheader einen Syntaxfehler hat, was zu einem fehlerhaften oder ungültigen Wert führt. Daher wird der Header von Browsern ignoriert.

Gültige Header werden in den folgenden Abschnitten beschrieben.

Header der Verweisrichtlinie

Eine gültige Verweisrichtlinie enthält einen der folgenden Werte:

  • Leerer String
  • no-referrer
  • no-referrer-when-downgrade
  • same-origin
  • origin
  • strict-origin
  • origin-when-cross-origin
  • strict-origin-when-cross-origin
  • unsafe-url

X-Frame-Options-Header

Ein gültiger X-Frame-Options-Header darf nur die folgenden Werte haben:

  • DENY: Framing unterdrücken
  • SAMEORIGIN: Framing zulassen, wenn die URL der obersten Ebene den gleichen Ursprung hat
  • ALLOW-FROM URL

ALLOW-FROM URL wird von Chrome nicht unterstützt. Mehrere X-Frame-Options sind nicht zulässig.

X-Content-Type-Options-Header

Ein gültiger X-Content-Type-Options-Header darf nur einen Wert haben: nosniff.

X-XSS-Protection-Header

Ein gültiger X-XSS-Protection-Header muss entweder mit 0 ("deaktivieren") oder 1 ("aktivieren") beginnen. Nur wenn Sie den Schutz aktivieren, können Sie bis zu zwei Optionen hinzufügen:

  • mode=block zeigt eine leere Seite an, statt XSS zu filtern
  • report=URL sendet Berichte an URL

Optionen müssen durch Semikolons getrennt werden, z. B. 1; mode=block; report=URI. Achten Sie darauf, dass kein abschließendes Semikolon vorhanden ist.

MISSPELLED_SECURITY_HEADER_NAME

Web Security Scanner kann falsch geschriebene Sicherheitsheadernamen erkennen. In seiner falsch geschriebenen Form ist der Sicherheitsheader unwirksam und muss repariert werden.

Überprüfen Sie, ob auf dem Tab "Netzwerk" der Entwicklertools Ihres Browsers die falsche Schreibweise zu finden ist. So können Sie diese Sicherheitslücke reproduzieren.

MISMATCHING_SECURITY_HEADER_VALUES

Web Security Scanner kann erkennen, ob eine Antwort doppelte, sicherheitsbezogene Antwortheader mit widersprüchlichen Werten hat. Einige sicherheitsrelevante HTTP-Header haben ein undefiniertes Verhalten, wenn sie in der Antwort zweimal mit nicht übereinstimmenden Werten deklariert wurden.

Diese Sicherheitslücke lässt sich beheben, indem Sie nur einen der beiden nicht übereinstimmenden Header beibehalten.

Zugängliches Repository

Web Security Scanner findet in der Anwendung möglicherweise ein zugängliches GIT- oder SVN-Repository. Dies kann zu Schwachstellen im Quellcode und in der Konfiguration führen.

Um die Sicherheitslücke zu reproduzieren, klicken Sie im Suchbericht auf die Reproduktions-URL.

Problem prüfen

Wenn Web Security Scanner ein Problem meldet, müssen Sie prüfen, wo das Problem auftritt. Sie können dies mit einem Browser mit ausgeschaltetem XSS-Schutz tun. Wir empfehlen die Verwendung einer separaten Testinstanz von Chrome. Sie können jedoch auch einem beliebigen modernen Browser verwenden, in dem der XSS-Schutz deaktiviert werden kann.

So deaktivieren Sie den XSS-Schutz in Chrome:

  • Unter Linux rufen Sie den Linux-Chrome-Befehl so auf:

    chrome --user-data-dir=~/.chrometest --allow-running-insecure-content \
      --disable-xss-auditor --disable-sync --bwsi
    
  • Wenn Sie macOS verwenden, rufen Sie den Chrome-Befehl so auf:

    open -n /Applications/Google\ Chrome.app/ --args --disable-xss-auditor \
      --user-data-dir=/tmp/xssrepro
    

Die Erzwingung der Sicherheitsrichtlinie für Inhalte (Content Security Policy, CSP) kann verhindern, dass der JavaScript-Code ausgeführt wird. Dadurch wird es schwieriger, XSS zu reproduzieren. Prüfen Sie in diesem Fall die Browser-Log-Konsole, um Details zur aufgetretenen CSP-Verletzung anzeigen zu lassen.