Sicherheit ist zentral dafür, Snipp für alle sicher zu halten, und wir sind auf Forscher angewiesen, die uns helfen, Schwachstellen schnell zu finden und zu beheben. Falls du ein Sicherheitsproblem entdeckt hast, wollen wir davon erfahren. Wir schätzen jede verantwortungsvolle Offenlegung, viel Erfolg bei der Jagd!
Wir werden niemals rechtliche Schritte gegen jemanden einleiten, der Schwachstellen in gutem Glauben meldet und die Richtlinien auf dieser Seite befolgt.
Wir bemühen uns, jeden Bericht innerhalb von 48 Stunden zu bestätigen, und halten dich während des gesamten Lösungsprozesses auf dem Laufenden.
Je nach Schweregrad und Auswirkung deines Fundes kannst du Anspruch auf ein exklusives Profil-Abzeichen und kostenlose Monate unseres PLUS-Abonnements haben.
Forscher, die wesentliche Beiträge zur Sicherheit von Snipp leisten, können Profil-Abzeichen verdienen, die öffentlich auf ihrem Konto angezeigt werden.
Wird für deinen ersten gültigen Schwachstellenbericht verliehen. Würdigt Forscher, die dazu beitragen, Snipp sicherer zu machen.
Wird nach 3-5 herausragenden Berichten oder einem einzelnen kritischen Fund verliehen. Reserviert für aktive Forscher, die die folgenreichsten Probleme aufdecken.
Alle Tests müssen mit deinen eigenen Konten durchgeführt werden. Interagiere niemals mit den Daten oder Konten anderer Nutzer und beeinträchtige sie nicht.
Nur von Snipp betriebene Dienste fallen in den Geltungsbereich. Berichte zu Drittanbieter-Plattformen, auch zu solchen, die über unsere API integriert sind, werden nicht akzeptiert.
Vermeide jede Aktivität, die unsere Dienste beeinträchtigen oder die Datenintegrität gefährden könnte. Dazu gehören Brute-Force-Angriffe, DoS, Spamming und zeitbasierte Angriffe.
Automatisierte Scan-Tools sind nicht erlaubt. Alle Tests sollten manuell durchgeführt werden.
Wir können bestimmte Schwachstellenklassen vorübergehend aus dem Geltungsbereich ausschließen, während wir sie intern bearbeiten. Alle Änderungen werden auf dieser Seite widergespiegelt.
Bitte behandle alle Erkenntnisse vertraulich, bis wir das Problem vollständig untersucht und behoben haben.
Verantwortungsvolle Offenlegung ist der beste Weg, uns zu helfen, Probleme schnell zu beheben und gleichzeitig das Risiko zu minimieren. Wenn du uns direkt meldest, können wir sofort an einer Lösung arbeiten, ohne die Schwachstelle böswilligen Akteuren preiszugeben.
Erkenntnisse, die öffentlich geteilt werden, bevor wir die Möglichkeit hatten, sie zu beheben, ob in sozialen Medien, Foren oder anderswo, kommen nicht für eine Abzeichen-Anerkennung infrage. Wir möchten den Menschen Anerkennung zollen, die uns die Gelegenheit geben, Dinge zuerst zu beheben.
Wenn mehrere Personen dasselbe Problem melden, bewerten wir die Einreichungen anhand von:
Klarheit der technischen Erläuterung
Wie gut der Bericht die Auswirkungen in der Praxis vermittelt
Zeitstempel der Einreichung
Ein Bericht muss eine reale Auswirkung nachweisen. Ein CVSS-Wert allein, ohne einen funktionierenden Proof of Concept, der zeigt, was ein Angreifer tatsächlich erlangt, wird als informativ behandelt und ist nicht für eine Belohnung qualifiziert.
Wir schätzen jeden Forscher aufrichtig, der sich die Zeit nimmt, Snipp sicherer zu machen.
Einige Daten sind absichtlich öffentlich. Informationen, die bereits auf öffentlichen Seiten erscheinen, sind nicht vertraulich, und sie zu lesen, sei es über die Website, einen API-Endpunkt oder im abgemeldeten Zustand, stellt keine Schwachstelle dar. Bevor Sie eine Datenoffenlegung melden, prüfen Sie, ob dieselben Daten bereits öffentlich angezeigt werden. Folgendes ist absichtlich öffentlich:
Profilinformationen, die auf der öffentlichen Seite eines Nutzers angezeigt werden: Benutzername, Anzeigename, Avatar, Banner, Bio, verknüpfte soziale Netzwerke, Beitrittsdatum sowie die Anzahl der Follower und der gefolgten Konten.
Profilabzeichen und der dahinterstehende Status, einschließlich Mitarbeiter, Partner, Bug Hunter, Übersetzer, verifiziert und Unterstützer. Diese werden öffentlich als Abzeichen angezeigt.
Beitragsinformationen zu einem öffentlichen oder nicht gelisteten Beitrag: Titel, Beschreibung, Medien, Aufrufzahl und Uploaddatum.
Betrachterbezogene Kennzeichnungen, die nur Ihre eigene Sitzung widerspiegeln, etwa ob ein Profil Ihr eigenes ist, ob Sie einem Nutzer folgen oder ob zwischen Ihnen und ihm eine Blockierung besteht. Diese beschreiben Ihr Verhältnis zu den Daten, nicht die privaten Informationen anderer.
Überlege vor dem Einreichen, ob das Problem ein realistisches Angriffsszenario und eine bedeutsame Auswirkung auf die Sicherheit hat. Folgendes ist in der Regel ausgeschlossen:
Offenlegung von Daten, die bereits absichtlich öffentlich sind (siehe den vorherigen Abschnitt), einschließlich Profilfelder, Abzeichen, Beitragsmetadaten und betrachterbezogene Kennzeichnungen
Berichte, die ausschließlich auf clientseitiger Validierung beruhen. Sicherheitsprüfungen werden auf dem Server durchgesetzt, daher stellt eine fehlende clientseitige Prüfung keine Schwachstelle dar, wenn der Server dieselbe Eingabe ablehnt
Verarbeitung von Dateityp, MIME oder Dateierweiterung bei Uploads. Hochgeladene Dateien werden anhand ihres tatsächlichen Inhalts auf dem Server validiert, und der gespeicherte Typ wird niemals vom Client übernommen
Offenlegung einer Ursprungs-IP-Adresse, eines Infrastrukturanbieters oder einer nicht über den Proxy laufenden Subdomain. Einige Dienste, etwa Upload-Endpunkte, werden absichtlich außerhalb des CDN bereitgestellt und sind am Ursprung gehärtet
Veraltete oder historische DNS-Einträge, die nicht mehr auf aktive Infrastruktur verweisen
Fehlende oder falsch konfigurierte Sicherheits-Header wie CSP, HSTS oder X-Frame-Options ohne einen nachgewiesenen funktionierenden Exploit
Ausführliche Fehlermeldungen, Stack-Traces oder die Offenlegung von Softwareversionen ohne einen nachgewiesenen funktionierenden Exploit
Aufzählung gültiger Ressourcen anhand ihrer Kennung oder 4xx- und 5xx-Antworten auf ungültige Kennungen. Die Rückgabe eines Nicht-gefunden-Status auf eine ungültige Anfrage ist erwartetes Verhalten
Konto-Enumeration
Angriffe, die MITM oder physischen Zugriff auf das Gerät eines Nutzers erfordern
Clickjacking
Content-Spoofing und Text-Injection
CSRF-Schwachstellen
SPF-, DKIM- und DMARC-Einträge von E-Mails
Fehlende HttpOnly-/Secure-Cookie-Flags
Offene CORS-Header
Ratenbegrenzung
Berichte von Scannern und automatisierten Tools
Selbst-Ausnutzung (z. B. Token-Wiederverwendung und Konsolen-Scripting)
Social-Engineering- oder Phishing-Angriffe, die auf Nutzer oder Mitarbeiter abzielen
Externe Dienste, Partner und Integrationen liegen außerhalb des Geltungsbereichs dieses Programms. Nur Schwachstellen in Snipp-eigenen Funktionen und APIs kommen infrage. Berichte müssen eine klare Auswirkung auf die Sicherheit von Snipp selbst aufzeigen.
Jedes Szenario, in dem ein Angreifer die API-Schlüssel, Sitzungstokens oder Anmeldedaten eines anderen Nutzers erlangen könnte, ohne auf Social Engineering zurückzugreifen, fällt in den Geltungsbereich.
Reproduzierbare Website-Abstürze, die durch manipulierte Eingaben oder normale Nutzerinteraktion verursacht werden, fallen in den Geltungsbereich, sofern sie nicht von Ressourcenerschöpfung, Spam oder anderen Denial-of-Service-Techniken abhängen.
Berichte, die auf der Ausnutzung einer Race Condition beruhen, benötigen zusätzliche Belege, um akzeptiert zu werden. Bitte füge mindestens eines der folgenden Elemente hinzu:
Ein reproduzierbares Skript (Python oder JavaScript bevorzugt, andere Sprachen sind aber auch in Ordnung)
Eine ausführliche Beschreibung, die die HTTP-Methoden, Endpunkte und die genaue Reihenfolge der Anfragen abdeckt, die zum Auslösen der Bedingung erforderlich sind
Ein beigefügtes Skript erleichtert uns die Überprüfung des Problems erheblich und beschleunigt den Prüfprozess.
Schreib uns eine E-Mail mit einer klaren Beschreibung des Problems, Schritten zur Reproduktion und allen unterstützenden Belegen. Wir melden uns so schnell wie möglich.