Web Security Scanner-Ergebnisse beheben

Auf dieser Seite wird erläutert, wie Sie die Ergebnisse von Web Security Scanner interpretieren, reproduzieren und beheben können.

IAM-Rollen für Security Command Center können auf Organisations-, Ordner- oder Projektebene gewährt werden. Ob Sie Ergebnisse, Assets und Sicherheitsquellen ansehen, bearbeiten, erstellen oder aktualisieren können, hängt davon ab, auf welcher Ebene Sie Zugriff erhalten. Weitere Informationen über Security Command Center-Rollen finden Sie unter Zugriffssteuerung.

Sicherheitslückenklassen

Web Security Scanner erkennt folgende Sicherheitslücken:

  • Cross-Site-Scripting (XSS)
  • Serverseitige Anfragefälschung
  • Flash Injection
  • Gemischte Inhalte
  • Veraltete oder anfällige Bibliotheken
  • Klartext-Passwörter
  • Unsichere Ursprungsvalidierung
  • Ungültige Header
  • Falsch geschriebene Header
  • Zugängliche Repositories
  • SQL-Injection
  • XML-Injection
  • Prototyp-Verschmutzung

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.

Deaktivierung von Ergebnissen nach der Behebung

Nachdem Sie eine Sicherheitslücke behoben haben, Web Security Scanner legt den Status des entsprechendes Security Command Center-Ergebnis zu INACTIVE. Sofern Sie den Status nicht manuell ändern, wird der Status der Ergebnisse von Web Security Scanner in Security Command Center bleiben ACTIVE.

Wenn Sie die eigenständige Version von Web Security Scanner verwenden, wird eine Sicherheitslücke in nachfolgenden Sicherheitslückenberichten nicht mehr aufgeführt, nachdem Sie sie behoben haben und Web Security Scanner sie nicht mehr erkennen kann. Ein Eintrag zu der Sicherheitslücke bleibt in den bisherigen Berichten zu Sicherheitslücken erhalten.

Web Security Scanner führt wöchentlich verwaltete Scans aus.

Weitere Informationen zu Web Security Scanner-Scans finden Sie unter Scantypen.

Web Security Scanner-Ergebnisse beheben

In diesem Abschnitt wird erläutert, wie Sie verschiedene Arten von Ergebnissen des Web Security Scanners beheben können. Strategien zum Schutz vor häufigen Angriffen auf Anwendungsebene, die in OWASP Top 10 beschrieben sind, finden Sie unter OWASP Top 10 – Optionen zur Risikominimierung in Google Cloud.

XSS

Kategoriename in der API: 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

Kategoriename in der API: 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

Kategoriename in der API: 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.

Server side request forgery

Kategoriename in der API: SERVER_SIDE_REQUEST_FORGERY

Eine SERVER_SIDE_REQUEST_FORGERY-Sicherheitslücke ermöglicht Nutzern der Webanwendung Zugriff auf interne Daten. Dazu wird ein Server gezwungen, eine Anfrage (z. B. eine HTTP-Anfrage) an einen eingeschränkten Dienstendpunkt zu senden. Ein Angreifer kann diese Sicherheitslücke beispielsweise ausnutzen, um Daten aus dem Google Cloud-Metadatendienst abzurufen.

Verwenden Sie eine Zulassungsliste, um die Domains und IP-Adressen zu beschränken, an die die Webanwendung Anfragen senden kann, und so das Problem zu beheben.

Rosetta flash

Kategoriename in der API: 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

Kategoriename in der API: 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

Kategoriename in der API: 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 bekanntlich sichere Version, um dieses Problem zu beheben.

Struts insecure deserialization

Kategoriename in der API: STRUTS_INSECURE_DESERIALIZATION

Web Security Scanner erkennt möglicherweise, dass Ihre Webanwendung eine Apache Struts-Version verwendet, die anfällig für Remote-Injection-Angriffe ist. Die betroffenen Struts-Versionen können den ungültigen Content-Type-HTTP-Header eines Angreifers falsch parsen. Diese Sicherheitslücke ermöglicht es, schädliche Befehle unter den Berechtigungen des Webservers auszuführen.

Die folgenden Apache Struts-Versionen sind anfällig:

  • 2.3.x-Versionen vor 2.3.32
  • 2.5.x-Versionen vor 2.5.10.1

Aktualisieren Sie Apache Struts auf die neueste Version, um dieses Problem zu beheben.

Weitere Informationen zur Apache Struts-Sicherheitslücke finden Sie unter CVE-2017-5638.

Cacheable password input

Kategoriename in der API: CACHEABLE_PASSWORD_INPUT

Web Security Scanner kann erkennen, dass die Webanwendung für eine Passworteingabe ein <input>-Element verwendet, für das das type-Attribut nicht auf password festgelegt ist. Dies kann dazu führen, dass Browser das vom Nutzer eingegebene Passwort im regulären Browser-Cache statt in einem sicheren Passwortspeicher speichern.

Zum Beheben dieses Problems fügen Sie dem Element <input> das Attribut type hinzu und legen es auf password fest, z. B. <input type="password">. Durch dieses Attribut werden die Zeichen unkenntlich gemacht, die der Nutzer im Passwortfeld eingibt.

Clear text password

Kategoriename in der API: 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.

Insecure allow origin ends with validation

Kategoriename in der API: INSECURE_ALLOW_ORIGIN_ENDS_WITH_VALIDATION

Web Security Scanner erkennt möglicherweise, dass ein Cross-Site-HTTP- oder HTTPS-Endpunkt nur ein Suffix des Origin-Anfrageheaders validiert, bevor er es im Access-Control-Allow-Origin-Antwortheader reflektiert. Ist die Validierung falsch konfiguriert, gewährt der Endpunkt möglicherweise Zugriff auf eine schädliche Domain, die dasselbe Suffix wie eine Domain auf der Zulassungsliste hat. Beispiel: Wenn der Validator des Endpunkts Domains wie *google.com entspricht, kann er fälschlicherweise Zugriff auf maliciousdomaingoogle.com gewähren.

Prüfen Sie zur Behebung dieses Problems, ob die erwartete Stammdomain Teil des Headerwerts Origin ist, bevor Sie sie im Antwortheader Access-Control-Allow-Origin angeben. Stellen Sie bei Subdomain-Platzhaltern der Stammdomain einen Punkt voran, z. B. .endsWith(".google.com").

Insecure allow origin starts with validation

Kategoriename in der API: INSECURE_ALLOW_ORIGIN_STARTS_WITH_VALIDATION

Web Security Scanner erkennt möglicherweise, dass ein Cross-Site-HTTP- oder HTTPS-Endpunkt nur ein Präfix des Origin-Anfrageheaders validiert, bevor er es im Access-Control-Allow-Origin-Antwortheader reflektiert. Ist die Validierung falsch konfiguriert, gewährt der Endpunkt möglicherweise Zugriff auf eine schädliche Domain, die dasselbe Präfix wie eine Domain auf der Zulassungsliste hat. Beispiel: Wenn die Validierung des Endpunkts nur prüft, ob die anfragende Domain google.com enthält, kann sie fälschlicherweise Zugriff auf google.com.maliciousdomain.com gewähren.

Um dieses Ergebnis zu beheben, prüfen Sie, ob die erwartete Domain vollständig mit dem Headerwert Origin übereinstimmt, bevor Sie sie im Antwortheader Access-Control-Allow-Origin angeben, z. B. .equals(".google.com").

Session ID leak

Kategoriename in der API: SESSION_ID_LEAK

Web Security Scanner findet im Referer-Anfrageheader der domainübergreifenden Anfragen Ihrer Webanwendung möglicherweise eine Sitzungs-ID. Domains, die Referer erhalten, können mit der Sitzungs-ID die Identität eines Nutzers mithilfe seines Tokens übernehmen oder den Nutzer sicher identifizieren.

Speichern Sie Sitzungs-IDs in Cookies statt in der URL, um dieses Problem zu beheben. Sichern Sie Ihre Cookies außerdem mit folgenden Attributen:

  • HTTPOnly: ein Attribut, das Cookies für clientseitige Skripts unzugänglich macht
  • Secure: Ein Attribut, das Cookies nur über HTTPS übertragbar macht

Invalid content type

Kategoriename in der API: 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.

Achten Sie zur Behebung dieses Problems auf Folgendes:

  • 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

Kategoriename in der API: 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

Kategoriename in der API: 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

Kategoriename in der API: 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.

Dieses Problem 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.

XXE reflected file leakage

Kategoriename in der API: XXE_REFLECTED_FILE_LEAKAGE

Web Security Scanner findet möglicherweise eine Sicherheitslücke einer externen XML-Entität (XXE) in einer Webanwendung, die XML aus Nutzereingaben parst. Ein Angreifer kann eine XML-Datei bereitstellen, die eine externe Entität enthält. Diese externe Entität kann auf Inhalte verweisen, auf die die Anwendung Zugriff hat, z. B. Dateien auf dem Hostcomputer der Anwendung. Wenn der XML-Parser der Anwendung die schädliche XML-Datei verarbeitet, kann er den Inhalt von Dateien auf dem Host offenlegen.

Konfigurieren Sie Ihre XML-Parser so, dass externe Entitäten nicht zugelassen werden, um dieses Problem zu beheben.

Weitere Informationen zu dieser Sicherheitslücke finden Sie unter Verarbeitung externer XML-Entitäten (XXE).

SQL injection

Kategoriename in der API: SQL_INJECTION

Web Security Scanner könnte eine SQL-Injection-Sicherheitslücke finden. Angreifer können Eingaben erstellen, die die Abfragestruktur der zugrunde liegenden SQL-Abfrage bearbeiten, die auf dem Server ausgeführt wird. Mit diesen Eingaben können sie Daten aus der Datenbank exfiltrieren und in einigen Fällen ändern. Verwenden Sie parametrisierte Abfragen, um zu verhindern, dass Nutzereingaben die Struktur der SQL-Abfrage beeinflussen, um dieses Problem zu beheben.

Weitere Informationen zu dieser Sicherheitslücke finden Sie unter SQL-Injection.

Prototype pollution

Kategoriename in der API: PROTOTYPE_POLLUTION

Web Security Scanner kann eine Prototype-Pollution-Sicherheitslücke in einer Webanwendung finden, deren Objektattributen von Angreifern steuerbare Werte zugewiesen sind. Angreifer können Eingaben erstellen, die die Anwendung anfällig für Cross-Site-Scripting oder andere clientseitige Sicherheitslücken machen.

Löschen Sie das verworfene Attribut proto und machen Sie das Object.prototype-Objekt unveränderlich, um das Problem zu beheben. Wenn diese Abhilfemaßnahme nicht mit Ihrem Code kompatibel ist, ändern Sie den gefährdeten Codeabschnitt so, dass nur erwartete Werte aus von Angreifern steuerbaren Eingaben kopiert werden.

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 Google Cloud Console die Seite Web Security Scanner auf.

    Zu "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 prüfen möchten. Eine Seite mit Details zum Scan wird geöffnet.

  4. Gehen Sie zum Tab Ergebnisse, maximieren Sie eine Kategorie und wählen Sie ein Ergebnis aus, um die zugehörigen Details aufzurufen.

  5. Die Bestätigungsmethode variiert je nach Ergebniskategorie. Verwenden Sie einen Testbrowser und folgen Sie der Anleitung unten.

    • 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 angreifbare Ressource unter URL der über HTTP bereitgestellten Ressource.
    • Flash-Injection: Web Security Scanner gibt möglicherweise Ergebnisse in dieser Kategorie zurück, aber die meisten modernen Browser sind vor der Flash-Injection geschützt. Es ist unwahrscheinlich, dass diese Erkenntnisse ausgenutzt werden können.
    • Prototype-Verschmutzung: Folgen Sie der URL im Feld Reproduction URL (Reproduktions-URL). und suchen Sie nach Änderungen am Objekt Object.prototype. durch die Nutzlast mit den folgenden JavaScript-Snippets.
      • ({}).__secret_injected_property
      • ({}).__defineGetter__.__secret_injected_property
      • ({}).hasOwnProperty.__secret_injected_property

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.