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 mit Web Security Scanner-Scans werden in Ihren Protokolldateien angezeigt. Web Security Scanner generiert beispielsweise Anfragen für ungewöhnliche Strings wie ~sfi9876 und /sfi9876. So kann der Scan die Fehlerseiten Ihrer Anwendung untersuchen. Diese absichtlich ungültigen Seitenanfragen werden in Ihren Protokollen angezeigt.

Web Security Scanner-Ergebnisse beheben

Im Folgenden finden Sie Informationen dazu, wie Sie verschiedene Arten von Ergebnissen des Web Security Scanners beheben können.

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. Der Fehler weist auf ein Injektionsproblem hin, kann es aber möglicherweise nicht aufrufen.

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. Ausführliche Informationen zum Überprüfen dieser Sicherheitslücke 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 XM-Schwachstelle (Cross-Site Scripting) in AngularJS-Modulen kann auftreten, wenn Angular einen vom Nutzer bereitgestellten String interpoliert. 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 potenzielle Sicherheitslücke zu reproduzieren. Dieser Link öffnet ein Dialogfeld mit Benachrichtigungen oder fügt den String XSSDETECTED ein, um zu beweisen, dass der Angriff Code ausführen kann. Wenn der String eingefügt wird, können Sie die Entwicklertools Ihres Browsers öffnen und nach XSSDETECTED suchen, um die genaue Position der Injection 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 der Browser ihn parst. Wenn der Browser versucht, diesen geänderten Teststring auszuführen, kann ein Fehler auftreten. Daraufhin wird wahrscheinlich ein JavaScript-Ausführungsfehler ausgegeben. Der Fehler weist auf ein Injektionsproblem hin, kann es aber möglicherweise nicht aufrufen.

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. Ausführliche Informationen zum Überprüfen dieser Sicherheitslücke finden Sie unter Cross-Site-Scripting.

ROSETTA_FLASH

Web Security Scanner kann erkennen, dass der Wert eines Anfrageparameters zu Beginn einer Antwort wieder reflektiert wird, z. B. in Anfragen mit JSONP. Diese Sicherheitslücke wird auch als "Flash-Injection" bezeichnet. Unter bestimmten Umständen kann ein Angreifer den Browser dazu führen, 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 so vollständigen Zugriff auf die Website erhalten, die die Ressource lädt, oder Zugriff auf die von Nutzern ausgeführten Aktionen überwachen.

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. Web 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 kann feststellen, 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

In Web Security Scanner wird möglicherweise ein Syntaxfehler angezeigt, was zu einem fehlerhaften oder ungültigen Wert für Header führt. Daher ignoriert der Browser diese Header.

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 URL der obersten Ebene identisch ist
  • ALLOW-FROM URL

Chrome unterstützt ALLOW-FROM URL nicht. 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. Anschließend können Sie bis zu zwei Optionen hinzufügen, wenn Sie die Schutzmaßnahme aktivieren:

  • 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 am Ende kein Semikolon steht.

MISSPELLED_SECURITY_HEADER_NAME

Web Security Scanner findet möglicherweise einen falsch geschriebenen Sicherheitsheadernamen. 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. Diese Bedingung 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. In diesem Abschnitt wird erläutert, wie Sie Erbenisberichte verwenden, um Sicherheitslücken zu reproduzieren und zu prüfen.

  1. Rufen Sie in der Cloud Console die Seite Web Security Scanner auf.
    Zur Seite „Web Security Scanner“
  2. Wählen Sie ein Projekt aus. Es wird eine Seite mit einer Liste Ihrer verwalteten und benutzerdefinierten Scans angezeigt.
  3. Wählen Sie unter Scankonfigurationen den Scan aus, der das Ergebnis enthält, das Sie überprüfen möchten. Es wird eine Seite mit Details zum Scan geöffnet.
  4. Gehen Sie zum Tab Ergebnisse, maximieren Sie eine Kategorie und wählen Sie ein Ergebnis aus, um seine Details aufzurufen.
  5. Die Bestätigungsmethode unterscheidet sich je nach Ergebniskategorie. Verwenden Sie einen Testbrowser und folgen Sie der unten stehenden Anleitung.
    • Cross-Site-Scripting: Nach der Reproduktions-URL wird im Browser ein leeres Pop-up-Fenster erstellt. Dies weist darauf hin, dass der Scan erfolgreich in einen Skript ungefährlichen Code eingefügt hat.
    • Veraltete Bibliothek: Nach der Vulnerable URL wird eine Seite mit dem Text "Exploited" zurückgegeben. Dies weist darauf hin, dass der Scan erfolgreich in einen Skript ungefährlichen Code eingefügt hat.
    • Gemischte Inhalte Wenn Sie der URL der HTTPS-Seite folgen, wird eine Warnung zu einer Sicherheitslücke bei gemischten Inhalten zurückgegeben. Der Ergebnisbericht identifiziert die anfällige Ressource unter URL der über HTTP bereitgestellten Ressource.
    • Flash Injection: Flash Security Scanner gibt Ergebnisse in dieser Kategorie zurück, die meisten modernen Browser sind jedoch vor Flash-Injection geschützt. Es ist unwahrscheinlich, dass diese Ergebnisse missbraucht werden können.

Die Erzwingung von Content Security Policy (CSP) kann verhindern, dass der JavaScript-Code ausgeführt wird. Diese Bedingung erschwert die Reproduktion des XSS. Wenn dieses Problem auftritt, finden Sie Informationen zu dem aufgetretenen CSP-Verstoß in der Browser-Logkonsole.