Berichterstattung über Sicherheitslücken in Bezug auf Produktsicherheit — Umfang und Einsatzregeln

Regeln des Engagements
  • Keine Denial-of-Service-Tests
  • Keine physische oder soziale Manipulation
  • Kein Testen von Diensten von Drittanbietern
  • Kein Hochladen von Sicherheitslücken oder kundenbezogenen Inhalten auf Dienstprogramme von Drittanbietern (z. B. GitHub, Drobox, YouTube)
  • Alle Nutzdaten für Angriffe müssen in professioneller Sprache verwendet werden.
  • Wenn Sie Zugriff auf ein System, Konten, Benutzer oder Benutzerdaten erhalten können, halten Sie an der Erkennungsstelle an und melden Sie sich. Tauchen Sie nicht tiefer ein, um festzustellen, wie viel mehr verfügbar ist.
  • Wenn eine Sicherheitslücke dokumentiert wird, achten Sie bitte darauf, dass eine Sicherheitslücke öffentlich ist und der Kunde nicht identifiziert werden kann.
Sicherheitslücken mit geringer Auswirkung — außerhalb des Geltungsbereichs

Die folgenden Sicherheitslücken werden als schwach eingestuft und fallen nicht in den Geltungsbereich:

  • Google Maps API-Schlüssel
  • Konto-/E-Mail-Aufzählung mithilfe von Brute-Force-Angriffen.
  • Die Aufzählung von Benutzerkonten/E-Mails, für die keine Brute-Force-Methode erforderlich ist, wird als Teil des Geltungsbereichs betrachtet.
  • Alle Probleme mit geringer Auswirkung im Zusammenhang mit der Sitzungsverwaltung (z. B. gleichzeitige Sitzungen, Ablauf der Sitzung, Zurücksetzen/Ändern des Kennworts, Abmelden usw.)
  • Umgehung von Einschränkungen beim Hochladen einer Datei ohne Nachweis, dass die Datei empfangen wurde.
  • Clickjacking/UI-Korrektur
  • Automatische Vervollständigung oder Speicherung von Kennworten/Anmeldeinformationen durch die clientseitige Anwendung/den Browser
  • Beschreibende oder ausführliche Fehlerseiten ohne Nachweis der Ausnutzbarkeit oder des Abrufs vertraulicher Informationen.
  • Aufzählung der Verzeichnisstruktur (es sei denn, die Tatsache enthüllt außergewöhnlich nützliche Informationen)
  • Unvollständige oder fehlende SPF-/DMARC/DKIM-Einträge
  • Probleme im Zusammenhang mit der Stärke und Länge von Kennworten/Anmeldeinformationen, Sperrungen oder fehlendem Brute-Force-Schutz oder Ratenbegrenzung.
  • Kompromittierungen von Accounts (insbesondere Admin-Konten) als Folge dieser Probleme werden wahrscheinlich im Rahmen des Geltungsbereichs berücksichtigt.
  • Fehlender SSL-Code oder gemischter Inhalt
  • Durchsickern Sitzungscookies, Benutzeranmeldeinformationen oder andere vertrauliche Daten werden von Fall zu Fall überprüft.
  • Wenn das Durchsickern sensibler Daten eine Positionierung durch MitM erfordert, um sie auszunutzen, wird davon ausgegangen, dass dies nicht in den Geltungsbereich fällt.
  • Anmeldung/Abmeldung/Unauthentifiziert/CSRF mit geringer Auswirkung
  • CSRF-Sicherheitslücken können akzeptabel sein, wenn sie eine stärkere Auswirkung haben. Beispiele für CSRF mit geringer Auswirkung sind: Hinzufügen/Löschen aus dem Einkaufswagen, Hinzufügen/Entfernen von Wunschzettel/Favoriten, Optionen für nicht schwerwiegende Einstellungen usw.
  • Offenlegungen von Informationen mit geringen Auswirkungen (einschließlich Versionsoffenlegung)
  • Fehlende Cookie-Flags
  • Fehlende oder aktivierte HTTP-Headers/Methoden, die nicht direkt zu einer Sicherheitslücke führen.
  • Reflektierte Angriffe zum Herunterladen von Dateien (RFD)
  • Selbstausbeutung (d. h. Links zum Zurücksetzen von Passwörtern oder Wiederverwendung von Cookies)
  • Bewährte SSL/TLS-Methoden, die keinen voll funktionsfähigen Machbarkeitsnachweis enthalten.
  • URL/Open-Umleitung
  • Verwendung einer bekanntermaßen anfälligen Bibliothek, die zu einer Schwachstelle mit geringen Auswirkungen führt (d. h. eine veraltete jQuery-Version führt zu XSS mit geringen Auswirkungen)
  • Gültige Fehler oder Best-Practice-Probleme, die nicht direkt mit der Sicherheitslage des Clients zusammenhängen.
  • Sicherheitslücken, die Benutzer veralteter Browser, Plugins oder Plattformen betreffen.
  • Sicherheitslücken, die das Einfügen von beliebigem Text ermöglichen, ohne dass Hyperlinks, HTML- oder JavaScript-Code eingefügt werden können.
  • Sicherheitslücken, bei denen der Benutzer/das Opfer extrem unwahrscheinliche Aktionen ausführen muss (z. B. Self-XSS)
  • Self-XSS für ein persistentes/gespeichertes XSS wird in Betracht gezogen. Weitere Informationen finden Sie im Artikel Self-XSS.
  • Jede Art von XSS, bei der ein Opfer eine ungewöhnliche Tastenkombination drücken muss, fällt NICHT in den Geltungsbereich (d. h. Alt+Shift+X für die Payload-Ausführung)

Weitere spezifische Arten von Sicherheitslücken, die aufgrund ihrer geringen Auswirkungen nicht in den Geltungsbereich fallen:

  • Offenlegung von Dateien und Verzeichnissen in der IIS-Tilde
  • Aufzählung des SSH-Benutzernamens
  • Aufzählung des WordPress-Benutzernamens
  • Schwache SSL-Chiffren/ PUDEL/Heartbleed
  • CSV-Injektion
  • PHP-Informationen
  • Server-Status, wenn keine vertraulichen Informationen preisgegeben werden.
  • Offenlegung von Informationen über Snoop