Mit Web Security Scanner können Sie Sicherheitslücken in Ihren App Engine-, GKE- (Google Kubernetes Engine) und Compute Engine-Webanwendungen erkennen. Dieser Scanner führt ein Crawling Ihrer Anwendung durch, folgt dabei allen Links im Bereich der Start-URLs und versucht, so viele Nutzereingaben und Event-Handler wie möglich anzuwenden. Web Security Scanner unterstützt nur öffentliche URLs und IP-Adressen, hinter einer Firewall.
Web Security Scanner unterstützt die App Engine-Standardumgebung und flexiblen App Engine-Umgebungen, Compute Engine-Instanzen und GKE-Ressourcen
Web Security Scanner ist als Ergänzung Ihrer bestehenden Sicherheitsarchitektur und Ihrer Entwicklungsprozesse konzipiert. Damit Sie möglichst wenig durch falsch positive Meldungen abgelenkt werden, ist Web Security Scanner so eingestellt, dass nur Warnungen mit hohen Konfidenzwerten angezeigt werden. Das Tool ist kein Ersatz für eine manuelle Sicherheitsprüfung und bietet keine Garantie dafür, dass Ihre Anwendung frei von Sicherheitslücken ist.
Scantypen
Web Security Scanner ermöglicht verwaltetes und benutzerdefiniertes Scannen auf Sicherheitslücken im Web für öffentliche App Engine-, GKE- und Compute Engine-Dienste.
Verwaltete Scans
Von Web Security Scanner verwaltete Scans werden von Security Command Center konfiguriert und verwaltet. Verwaltete Scans werden jede Woche automatisch ausgeführt, um öffentliche Webendpunkte zu erkennen und zu scannen. Bei diesen Scans wird keine Authentifizierung verwendet. Sie senden nur GET-Anfragen, sodass sie keine Formulare auf Live-Websites senden.
Verwaltete Scans werden getrennt von benutzerdefinierten Scans ausgeführt.
Wenn Security Command Center aktiviert ist, Organisationsebene, können Sie mit verwalteten Scans grundlegende Webanwendungen zentral verwalten Schwachstellenerkennung für Projekte in Ihrem Unternehmen, einzelne Projektteams einzubeziehen. Wenn Ergebnisse gefunden werden, können Sie mit diesen Teams zusammenarbeiten, um umfassendere benutzerdefinierte Scans einzurichten.
Wenn Sie Web Security Scanner als Dienst aktivieren, werden die Ergebnisse des verwalteten Scans sind automatisch auf der Seite Vulnerabilities (Sicherheitslücken) in Security Command Center verfügbar und zugehöriger Berichte. Informationen zum Aktivieren von Web Security Scanner Verwaltete Scans, siehe Konfigurieren Sie Security Command Center-Dienste.
Verwaltete Scans unterstützen nur Anwendungen, die den Standardport 80 verwenden für HTTP-Verbindungen und 443 für HTTPS-Verbindungen. Wenn Ihre Anwendung nicht-Standardport, führen Sie stattdessen einen benutzerdefinierten Scan durch.
Benutzerdefinierte Scans
Benutzerdefinierte Scans von Web Security Scanner liefern detaillierte Informationen zu Ergebnissen in Bezug auf die Anwendungssicherheit, wie veraltete Bibliotheken, Cross-Site-Scripting oder Verwendung von gemischten Inhalten.
Benutzerdefinierte Scans werden auf Projektebene definiert.
Benutzerdefinierte Scanergebnisse sind in Security Command Center verfügbar, nachdem Sie den Leitfaden zum Einrichten benutzerdefinierter Web Security Scanner-Scans befolgt haben.
Scan-Ergebnisse
In diesem Abschnitt werden die Ergebnistypen und Web-Compliance-Standards von Web Security Scanner beschrieben.
Detektoren und Compliance
Web Security Scanner unterstützt Kategorien in OWASP Top Ten, ein Dokument, das und bietet Tipps zur Schadensbehebung für die 10 wichtigsten Webanwendungen Sicherheitsrisiken, wie vom Open Web Application Security Project festgelegt (OWASP).
Die Compliance-Zuordnung ist als Referenz enthalten und wird von der OWASP Foundation nicht zur Verfügung gestellt oder überprüft. Es dient nur zur Überwachung der Einhaltung von Richtlinien dient der Kontrolle von Verstößen. Die Zuordnungen werden nicht als Grundlage für oder als Ersatz für einen Audit, die Zertifizierung oder einen Bericht über die aufsichtsrechtliche oder branchenübliche Benchmarks oder Standards einhalten.
Weitere Informationen zur Compliance finden Sie unter Compliance mit Sicherheits-Benchmarks bewerten und melden
Ergebnistypen
Benutzerdefinierte und verwaltete Web Security Scanner-Scans identifizieren die folgenden Ergebnistypen. In der Standardstufe unterstützt Web Security Scanner benutzerdefinierte Scans von bereitgestellten Anwendungen mit öffentlichen URLs und IP-Adressen, die sich nicht hinter einer Firewall befinden.
Kategorie | Ergebnisbeschreibung | OWASP 2017 Top 10 | OWASP 2021 Top 10 |
---|---|---|---|
Accessible Git repository
Kategoriename in der API: |
Ein Git-Repository ist öffentlich zugänglich. Um dieses Ergebnis zu korrigieren, entfernen Sie den unbeabsichtigten öffentlichen Zugriff auf das GIT-Repository.
Preisstufe: Standard |
A5 | A01 |
Accessible SVN repository
Kategoriename in der API: |
Ein SVN-Repository ist öffentlich zugänglich. Um dieses Ergebnis zu korrigieren, entfernen Sie den unbeabsichtigten öffentlichen Zugriff auf das SVN-Repository.
Preisstufe: Standard |
A5 | A01 |
Cacheable password input
Kategoriename in der API: |
In der Webanwendung eingegebene Passwörter können in einem normalen Browser-Cache statt in einem sicheren Passwortspeicher gespeichert werden.
Preisstufe: Premium |
A3 | A04 |
Clear text password
Kategoriename in der API: |
Passwörter werden in Klartext übertragen und können abgefangen werden. Um dieses Ergebnis zu korrigieren, verschlüsseln Sie das über das Netzwerk übertragene Passwort.
Preisstufe: Standard |
A3 | A02 |
Insecure allow origin ends with validation
Kategoriename in der API: |
Ein Cross-Site-HTTP- oder -HTTPS-Endpunkt validiert nur ein Suffix des Anfrageheaders Origin , bevor er im Antwortheader Access-Control-Allow-Origin widergespiegelt wird. Prüfen Sie zur Korrektur dieses Ergebnisses, 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") .
Preisstufe: Premium |
A5 | A01 |
Insecure allow origin starts with validation
Kategoriename in der API: |
Ein Cross-Site-HTTP- oder -HTTPS-Endpunkt validiert nur ein Präfix des Anfrageheaders Origin , bevor er im Antwortheader Access-Control-Allow-Origin widergespiegelt wird. Um dieses Ergebnis zu korrigieren, 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") .
Preisstufe: Premium |
A5 | A01 |
Invalid content type
Kategoriename in der API: |
Die geladene Ressource stimmt nicht mit dem Content-Type HTTP-Header der Antwort überein. Um dieses Ergebnis zu korrigieren, legen Sie für den HTTP-Header X-Content-Type-Options den richtigen Wert fest.
Preisstufe: Standard |
A6 | A05 |
Invalid header
Kategoriename in der API: |
Ein Sicherheitsheader hat einen Syntaxfehler und wird von Browsern ignoriert. Legen Sie die HTTP-Sicherheitsheader richtig fest, um das Problem zu beheben.
Preisstufe: Standard |
A6 | A05 |
Mismatching security header values
Kategoriename in der API: |
Ein Sicherheitsheader hat doppelte, nicht übereinstimmende Werte, was zu nicht definiertem Verhalten führt. Legen Sie die HTTP-Sicherheitsheader richtig fest, um das Problem zu beheben.
Preisstufe: Standard |
A6 | A05 |
Misspelled security header name
Kategoriename in der API: |
Ein Sicherheitsheader wurde falsch geschrieben und wird ignoriert. Legen Sie die HTTP-Sicherheitsheader richtig fest, um das Problem zu beheben.
Preisstufe: Standard |
A6 | A05 |
Mixed content
Kategoriename in der API: |
Ressourcen werden über HTTP auf einer HTTPS-Seite bereitgestellt. Achten Sie zur Behebung dieses Problems darauf, dass alle Ressourcen über HTTPS bereitgestellt werden.
Preisstufe: Standard |
A6 | A05 |
Outdated library
Kategoriename in der API: |
Es wurde eine Bibliothek mit bekannten Sicherheitslücken gefunden. Aktualisieren Sie die Bibliotheken auf eine neuere Version, um dieses Problem zu beheben.
Preisstufe: Standard |
A9 | A06 |
Server side request forgery
Kategoriename in der API: |
Es wurde eine serverseitige Fälschungsanfrage (SSRF) erkannt. 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.
Preisstufe: Standard |
Nicht zutreffend | A10 |
Session ID leak
Kategoriename in der API: |
Bei einer domainübergreifenden Anfrage enthält die Webanwendung die Sitzungs-ID des Nutzers im Anfrageheader Referer . Diese Sicherheitslücke gewährt der empfangenden Domain Zugriff auf die Sitzungs-ID, mit der die Identität des Nutzers angenommen oder dieser sicher identifiziert werden kann.
Preisstufe: Premium |
A2 | A07 |
SQL injection
Kategoriename in der API: |
Ein potenzielles SQL-Einschleusungsproblem wurde erkannt. Verwenden Sie parametrisierte Abfragen, um zu verhindern, dass Nutzereingaben die Struktur der SQL-Abfrage beeinflussen, um dieses Ergebnis anzusprechen.
Preisstufe: Premium |
A1 | A03 |
Struts insecure deserialization
Kategoriename in der API: |
Die Verwendung einer anfälligen Version von Apache Struts wurde erkannt. Aktualisieren Sie Apache Struts auf die neueste Version, um dieses Ergebnis zu korrigieren.
Preisstufe: Premium |
A8 | A08 |
XSS
Kategoriename in der API: |
Ein Feld in dieser Webanwendung ist anfällig für einen Cross-Site-Scripting-Angriff (XSS). Um dieses Ergebnis zu korrigieren, validieren und maskieren Sie vom Nutzer bereitgestellte nicht vertrauenswürdige Daten.
Preisstufe: Standard |
A7 | A03 |
XSS angular callback
Kategoriename in der API: |
Ein vom Nutzer bereitgestellter String ist nicht maskiert und AngularJS kann ihn interpolieren. Validieren und maskieren Sie nicht vertrauenswürdige vom Nutzer bereitgestellte Daten, die vom Angular-Framework verarbeitet werden, um das Problem zu beheben.
Preisstufe: Standard |
A7 | A03 |
XSS error
Kategoriename in der API: |
Ein Feld in dieser Webanwendung ist anfällig für einen Cross-Site-Scripting-Angriff. Um dieses Ergebnis zu korrigieren, validieren und maskieren Sie vom Nutzer bereitgestellte nicht vertrauenswürdige Daten.
Preisstufe: Standard |
A7 | A03 |
XXE reflected file leakage
Kategoriename in der API: |
Eine XXE-Sicherheitslücke (XML External Entity) wurde erkannt. Diese Sicherheitslücke kann dazu führen, dass die Webanwendung eine Datei auf dem Host offenlegt. Konfigurieren Sie Ihre XML-Parser so, dass externe Entitäten nicht zugelassen werden, um dieses Problem zu beheben.
Preisstufe: Premium |
A4 | A05 |
Prototype pollution
Kategoriename in der API: |
Die Anwendung ist anfällig für Verschmutzung durch Prototypen. Diese Sicherheitslücke tritt auf,
des Object.prototype -Objekts können von Angreifern steuerbare Werte zugewiesen werden. Werte, die diesen Prototypen zugewiesen wurden
allgemein davon ausgegangen, dass sie zu Cross-Site-Scripting oder ähnlichen clientseitigen Schwachstellen sowie logischen Fehlern führen.
Preisstufe: Standard <ph type="x-smartling-placeholder"></ph> Ergebnis korrigieren |
A1 | A03 |
Nutzungswarnungen
Die IAM-Rollen für Security Command Center können in der Organisation, Ordner- oder Projektebene. Ihre Fähigkeit, Ergebnisse, Assets, und Sicherheitsquellen hängen von der Zugriffsebene ab. Weitere Informationen über Security Command Center-Rollen finden Sie unter Zugriffssteuerung.
Bei der Verwendung von Web Security Scanner sollten Sie Folgendes beachten:
- Web Security Scanner wird kontinuierlich verbessert. Daher kann es vorkommen, dass zukünftige Scans Probleme melden, die von aktuellen Scans nicht erkannt wurden.
- Einige Funktionen oder Bereiche Ihrer Anwendung werden möglicherweise nicht getestet.
- Web Security Scanner versucht, alle gefundenen Steuerelemente und Eingaben zu aktivieren.
- Wenn Sie über Ihr Testkonto Vorgänge zu Statusänderungen freigeben können, wird sie vom Web Security Scanner wahrscheinlich aktiviert. Dies kann zu unerwünschten Ergebnissen führen.
- Für Web Security Scanner gilt ein Limit von 15 Scans pro Projekt. Weil Scans gleichzeitig ausgeführt werden, wird Nutzern empfohlen, mehrere Start-URLs pro Scan oder zum Hinzufügen von Scans zu verschiedenen Projekten die das Limit noch nicht erreicht haben.
Wer kann Sicherheitsscans durchführen?
Informationen zu den IAM-Rollen (Identity and Access Management), die für Web Security Scanner verfügbar, siehe Zugriffssteuerung:
Wie lange dauert ein Sicherheitsscan?
Der Sicherheitsscan wird nicht sofort ausgeführt, sondern für eine spätere Ausführung in die Warteschlange gestellt. Abhängig von der aktuellen Last kann es mehrere Stunden dauern, bis der Scan ausgeführt wird. Sobald der Scan startet, ist die Scandauer abhängig von der Größe Ihrer Anwendung. Für große Anwendungen mit vielen URLs kann ein Scan möglicherweise mehrere Stunden in Anspruch nehmen.
Zieleinschränkungen
Web Security Scanner verfügt über Filter, die Scanziele auf die bestimmte App Engine-Instanz begrenzen, für die der Scan erstellt wurde. Die Eingabe von URLs für ein anderes App Engine-Projekt oder eine externe Domain führt zu einer Fehlermeldung.
Scans für Compute Engine und GKE sind auf Domains beschränkt, die statischen externen IP-Adressen zugeordnet sind, die für dasselbe Projekt reserviert sind, und statischen externen IP-Adressen, die zu demselben Projekt gehören. Eine Anleitung zum Reservieren von IP-Adressen für Projekte finden Sie unter den folgenden Links:
Compute Engine: Statische externe IP-Adresse reservieren
Momentan ist es in App Engine nicht möglich, statische IP-Adressen einer Anwendung zuzuordnen. Sie können jedoch Cloud Load Balancing und ein serverloses Netzwerk verwenden, Endpunktgruppen eine statische IP-Adresse für den Load-Balancer reservieren, über die der Traffic an Ihre Anwendung weitergeleitet wird. Informationen zu Preisen Siehe Preise für externe IP-Adressen.
Innerhalb Ihres Projekts versucht Web Security Scanner automatisch, Logout-URLs und andere allgemeine Standorte zu vermeiden, die sich negativ auf den Scan auswirken könnten. Sie können jedoch zur Sicherheit über die Scaneinstellungen URLs manuell ausschließen.
Validierung
Scankonfigurationen werden beim Erstellen und vor jedem Scan validiert. Web Security Scanner prüft Security Command Center-Einstellungen und Anmeldedaten für die Authentifizierung, um sicherzustellen, dass Scans richtig konfiguriert sind und in Ihre Anwendung integrieren können. Konfigurationsparameter, einschließlich der maximalen Scangeschwindigkeit, werden ebenfalls geprüft, damit sie innerhalb der unterstützten Bereiche liegen.
Sie müssen Fehler beheben, bevor ein Scan erstellt oder aktualisiert werden kann. Anwendungen, die nach der Erstkonfiguration geändert werden, können während der Scans Fehler verursachen. Wenn eine Domain beispielsweise nicht mehr auf eine IP-Adresse verweist, die dem Projekt gehört, wird die Ressource nicht gescannt und auf der Konfigurationsseite für den Scan wird ein Fehler gemeldet.
Best Practices
Da Web Security Scanner Felder füllt, Schaltflächen betätigt, auf Links klickt und andere Nutzeraktionen ausführt, sollten Sie besonders vorsichtig sein, wenn Sie Produktionsressourcen scannen. Er könnte möglicherweise Funktionen aktivieren, die den Status Ihrer Daten oder Ihres Systems ändern, was zu unerwünschten Ergebnissen führt.
Beispiel:
- In einem Blog, in dem öffentlich kommentiert werden kann, postet Web Security Scanner möglicherweise Teststrings als Kommentare für alle Blogartikel.
- Auf einer E-Mail-Anmeldeseite generiert Web Security Scanner möglicherweise eine hohe Anzahl von Test-E-Mails.
Im Folgenden finden Sie einige Methoden, die Sie separat oder in Kombination verwenden können, um unerwünschte Ergebnisse zu vermeiden:
- Scans in einer Testumgebung ausführen. Richten Sie durch Erstellen eines separaten App Engine-Projekts eine Testumgebung ein, auf der Sie Ihre Anwendung und Daten laden. Wenn Sie die Google Cloud CLI verwenden, können Sie das Zielprojekt beim Hochladen Ihrer Anwendung als Befehlszeilenoption angeben.
- Testkonto verwenden. Erstellen Sie zum Scannen Ihrer Anwendung ein Nutzerkonto, das nicht auf vertrauliche Daten oder schädliche Vorgänge zugreifen kann. Viele Anwendungen bieten bei der ersten Anmeldung eines Nutzers einen bestimmten Workflow ‒ wie Akzeptieren der Bedingungen, Erstellen eines Profils. Da der Workflow unterschiedlich ist, kann ein Testkonto für einen erstmaligen Nutzer andere Scanergebnisse ausgeben als ein Nutzerkonto für einen etablierten Nutzer. Wir empfehlen, den Scan mit einem Konto durchzuführen, bei dem der Workflow der Ersteinrichtung abgeschlossen ist.
- Einzelne Elemente der Benutzeroberfläche blockieren, die Sie nicht aktivieren möchten. Verwenden Sie dazu die CSS-Klasse
inq-no-click
. Event-Handler, die diesem Element angehängt sind, werden beim Crawling und Prüfen nicht aktiviert. Dies ist unabhängig davon, ob sie mit Inline-JavaScript, mitaddEventListener
oder durch Festlegen des entsprechenden Event-Handlers angehängt wurden. - Sicherungsdaten verwenden. Es wird empfohlen, Daten vor einem Scan zu sichern.
- Ausgeschlossene URLs. Sie können URL-Muster angeben, die nicht gecrawlt oder getestet werden. Informationen zur Syntax finden Sie unter URLs ausschließen:
Prüfen Sie Ihre Anwendung vor dem Scannen sorgfältig auf Funktionen, die möglicherweise auf Daten, Nutzer oder Systeme jenseits des Scanumfangs auswirken.
Nächste Schritte
- Erste Schritte mit dem Web Security Scanner: