Submission API verwenden

In diesem Dokument wird beschrieben, wie Sie URLs, die Ihrer Meinung nach nicht sicher sind, zur Analyse an Safe Browsing senden und die Ergebnisse dieser Einreichungen asynchron prüfen. Alle URLs, die gegen die Safe Browsing-Richtlinien verstoßen, werden dem Safe Browsing-Dienst hinzugefügt.

Hinweis

Wenden Sie sich an den Vertrieb oder Ihren Customer Engineer, um Zugriff auf diese Funktion zu erhalten.

Best Practices

Safe Browsing-Richtlinien lesen

Mit der Web Risk Submission API wird geprüft, ob die eingereichten URLs Inhalte rendern, die gegen die Safe Browsing-Richtlinien verstoßen. API-Entwickler müssen dafür sorgen, dass die eingereichten URLs eindeutige Beweise für Verstöße gegen diese Richtlinien enthalten. Die folgenden Beispiele zeigen Beweise für Verstöße gegen Richtlinien:

  • Social-Engineering-Inhalte, die eine legitime Onlinemarke (Markenname, Logo, Erscheinungsbild), Systembenachrichtigungen oder betrügerische URLs imitieren oder Nutzer auffordern, vertrauliche Anmeldedaten wie einen Nutzernamen oder ein Passwort einzugeben.
  • Eine Website, auf der eine bekannte ausführbare Malware-Datei gehostet wird.

Reichen Sie die folgenden Arten von URLs nicht ein, da sie wahrscheinlich nicht der Safe Browsing-Sperrliste hinzugefügt werden:

  • Gefälschte Umfragen, Shopping-Websites oder andere Betrugsversuche, die kein Phishing darstellen (z. B. Kryptowährungsbetrug).
  • Spam mit Glücksspiel-, Gewalt- oder nicht jugendfreien Inhalten, der kein Phishing oder Malware enthält.

Erkennung verbessern

Wir empfehlen, die Felder ThreatInfo und ThreatDiscovery zu verwenden, um zusätzliche Informationen zu Einsendungen anzugeben. Das kann die Erkennung verbessern. Weitere Informationen finden Sie unter Best Practices für die Verwendung der Submission API.

Taxonomie und Markenausrichtung

Mit den folgenden optionalen Komponenten im ThreatInfo-Objekt können Sie genauere und detailliertere Missbrauchsberichte erstellen: abuseSubtype und targetedBrand. Mithilfe dieser Felder kann Web Risk die Zielentitäten genauer analysieren und die Erkennungsmodelle verbessern.

abuseSubtype

Das Feld abuseSubtype enthält eine detaillierte Klassifizierung der Bedrohung. Achten Sie darauf, dass dieses Feld nur festgelegt wird, wenn der primäre abuseType SOCIAL_ENGINEERING ist. Andernfalls wird ein Fehler zurückgegeben.

Folgende abuseSubtype-Werte werden unterstützt:

  • BANK_PHISHING: Phishing, bei dem sich der Absender als Bank oder vertrauenswürdige Finanzorganisation ausgibt.
  • CRYPTO_EXCHANGE_PHISHING: Phishing, bei dem sich der Angreifer als Kryptowährungs-Handelsplattform ausgibt.
  • SOCIAL_MEDIA_PLATFORM_PHISHING: Phishing, bei dem sich die Betrüger als Social-Media-Plattform ausgeben.
  • RETAIL_PHISHING: Phishing, bei dem sich die Betrüger als etablierte Einzelhandelsplattform ausgeben.
  • EMAIL_PROVIDER_PHISHING: Phishing, bei dem sich der Absender als E-Mail-Dienst ausgibt.
  • ENTERTAINMENT_PHISHING: Phishing, bei dem sich der Absender als Unterhaltungsdienst ausgibt.
  • GOVERNMENT_AGENCY_PHISHING: Phishing, bei dem sich der Absender als staatliche Behörde ausgibt, um personenbezogene Daten (personenidentifizierbare Informationen) wie eine Sozialversicherungsnummer oder eine Steueridentifikationsnummer zu erhalten.
  • PACKAGE_TRACKING_SCAM: Nachahmen eines Versanddienstes, um personenidentifizierbare Informationen oder Zahlungsdetails zu erhalten.
  • FAKE_SUPPORT_SCAM: Irreführende Websites, auf denen fälschlicherweise Geräteprobleme behauptet werden, um Nutzer dazu zu bringen, personenbezogene Daten weiterzugeben oder Betrüger zu kontaktieren.
  • GOVERNMENT_FINE_SCAM: Irreführende Inhalte, in denen behauptet wird, dass eine ausstehende Ordnungswidrigkeitsgebühr bezahlt werden muss.
  • FAKE_PRIZE_SCAM: Betrügerische Seiten, auf denen unrealistische Belohnungen oder Preise angeboten werden.
  • OTHER_PHISHING / OTHER_SCAM: Social-Engineering-Angriffe, die nicht in die anderen hier genannten Kategorien fallen.

targetedBrand

Das targetedBrand-Objekt identifiziert die Einheit, die Ziel von Phishing- und Social-Engineering-Kampagnen ist.

  • brandName: Der erkennbare Name der Marke oder des Unternehmens, dessen Identität missbraucht wird (z. B. Altostrat).
  • domain: Die legitime Domain der Marke, die nachgeahmt wird (z. B. altostrat.com).

Wichtige Hinweise für Vorschau-Teilnehmer

  • Konsistenz bei der Taxonomie: Phishing wird weiterhin unter dem Bedrohungstyp SOCIAL_ENGINEERING kategorisiert (und nicht unter dem separaten übergeordneten Typ PHISHING), um die Konsistenz in der Web Risk- und Safe Browsing API-Suite zu gewährleisten.
  • Ausgeschlossene Kategorien: Unterkategorien für MALWARE und UNWANTED_SOFTWARE sind in dieser Version ausgeschlossen.
  • Nicht aufgeführte Bedrohungen behandeln: Wenn Ihre Einreichung keinem bestimmten Untertyp zugeordnet werden kann, verwenden Sie OTHER_PHISHING oder OTHER_SCAM. Wir empfehlen, das Feld comments in ThreatJustification zu verwenden, um den Angriff zu beschreiben.
  • Optional, aber empfohlen: Wenn Sie diese Felder angeben, kann Web Risk die zugehörigen Threat Intelligence-Modelle priorisieren und optimieren.
  • Vorschauphase: Die Aufzählungswerte und das Verhalten für diese Funktion können sich ändern.

URLs einreichen

Senden Sie zum Senden einer URL eine HTTP-POST-Anfrage an die Methode projects.uris.submit.

  • Die Submission API unterstützt eine URL pro Anfrage. Um mehrere URLs zu prüfen, müssen Sie für jede URL eine separate Anfrage senden.

  • Die URL muss gültig sein, muss jedoch nicht kanonisiert werden. Weitere Informationen finden Sie unter RFC 2396.

  • Die HTTP-POST-Antwort gibt einen long-running operation zurück. Weitere Informationen zum Abrufen des Einreichungsergebnisses und zum Prüfen des Status einer Einreichung finden Sie unter Vorgänge mit langer Laufzeit.

Beispiel

HTTP-Methode und URL:

POST https://webrisk.googleapis.com/v1/projects/project-id/uris:submit

JSON-Text der Anfrage:

{
  "submission": {
    "uri": "https://www.example.com/login.html"
  }
}

Wenn Sie die Anfrage senden möchten, wählen Sie eine der folgenden Optionen aus:

curl

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus: 

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://webrisk.googleapis.com/v1/projects/project-id/uris:submit"

PowerShell

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus: 

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://webrisk.googleapis.com/v1/projects/project-id/uris:submit" | Select-Object -Expand Content

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

{
  "name": "projects/project-number/operations/operation-id",
}

Einreichungsstatus prüfen

Verwenden Sie project-number und operation-id aus der Antwort, um den Status der Einreichung zu prüfen. Der Status befindet sich im Feld metadata.state des zurückgegebenen Vorgangs.

Mögliche Status sind RUNNING, SUCCEEDED und CLOSED. Weitere Informationen zu diesen Status finden Sie im Leitfaden zu Vorgängen mit langer Ausführungszeit unter Vorgangsstatus.