SEKurity GmbH Logo

Richtlinie zur Meldung von Sicherheitslücken

Wenn Sie ein Sicherheitsproblem in diesem Blog gefunden haben, möchten wir davon erfahren. Diese Seite beschreibt, worum wir Sie bitten und wozu wir uns im Gegenzug verpflichten.

Zuletzt aktualisiert:

01Wofür diese Richtlinie gilt

Diese Richtlinie gilt für blog.sekurity.de und für nichts sonst: für die Anwendung, die den Blog ausliefert, für die Inhalte, die wir dort veröffentlichen, und für die Konfiguration, die wir kontrollieren.

Der Geltungsbereich ist bewusst eng gefasst. Dies ist eine statische Website auf angemieteter Infrastruktur — ein erheblicher Teil dessen, was Ihr Datenverkehr berührt, steht daher nicht in unserer Verfügungsgewalt. Die nächsten beiden Abschnitte benennen diese Grenze genau, denn ein Geltungsbereich, den man erraten muss, ist keiner.

  • Injection, Cross-Site-Scripting oder Content-Spoofing in Seiten, die von blog.sekurity.de ausgeliefert werden
  • Fehlerhafte Zugriffskontrolle oder Informationsabfluss in der Website oder ihrem Build-Ergebnis — etwa Geheimnisse im ausgelieferten Bundle
  • Fehlkonfigurierte HTTP-Header, Weiterleitungen oder Routing-Regeln, die wir selbst definieren
  • Mängel in unserer security.txt, unserem veröffentlichten PGP-Schlüssel oder in dieser Richtlinie selbst

02Was nicht in den Geltungsbereich fällt

Meldungen in diesen Kategorien schließen wir ohne inhaltliche Prüfung. Das ist keine Aussage darüber, ob das zugrundeliegende Problem real ist — einige davon sind es, sie gehören nur jemand anderem.

  • Denial of Service, Lasttests oder alles, was die Verfügbarkeit beeinträchtigt. Das träfe unseren Hosting-Anbieter und nicht uns, und wir können es nicht genehmigen.
  • Ergebnisse automatisierter Scanner ohne nachgewiesene, ausnutzbare Auswirkung auf diese Website.
  • Fehlende Hardening-Header, schwache TLS-Cipher und vergleichbare Best-Practice-Befunde ohne funktionierenden Angriffsweg. Schicken Sie sie uns gern — wir lesen sie —, aber es sind keine Schwachstellenmeldungen.
  • Self-XSS, Clickjacking auf Seiten ohne zustandsändernde Aktion, Mail-Records auf Domains, die keine Mail versenden, und Versionsangaben ohne funktionierenden Proof of Concept.
  • Social Engineering gegenüber Personen, physische Angriffe und alles, was auf einen Menschen statt auf das System zielt.
  • Befunde in den Drittanbieterdiensten, die diese Website lädt — siehe unten.
  • Andere Angebote der SEKurity, einschließlich www.sekurity.de. Die Kontaktadresse ist dieselbe, aber Geltungsbereich und Safe Harbour dieser Seite erstrecken sich nicht darauf.

03Infrastruktur, die wir nicht betreiben

Wir schreiben die Inhalte und den Code; alles darunter mieten wir an. Wir können keine Erlaubnis erteilen, Systeme zu testen, die wir nicht betreiben — und diese Richtlinie gibt auch nicht vor, es zu können.

Liegt Ihr Befund in einem der folgenden Dienste statt in unserer Anwendung, melden Sie ihn bitte dessen Betreiber. Diese unterhalten eigene Meldeprogramme und können das Problem tatsächlich beheben. Wir können weder das eine noch das andere.

Vercel

Hosting, Edge-Netzwerk, TLS-Terminierung, Build-Pipeline sowie die Analytics-, Speed-Insights- und Toolbar-Skripte, die diese Website lädt.

Google Fonts

Webschriften, ausgeliefert über fonts.googleapis.com und fonts.gstatic.com.

04Wie Sie testen, ohne Schaden anzurichten

Tests an diesem Blog laufen zwangsläufig über unseren Hosting-Anbieter. Das lässt sich nicht vermeiden, und gegen gewöhnliche manuelle Tests unserer Anwendung mit geringem Volumen haben wir nichts einzuwenden.

Für die Einhaltung der Nutzungsbedingungen dieser Anbieter bleiben Sie neben dieser Richtlinie selbst verantwortlich. Nichts hier setzt sie außer Kraft, und wir können Sie nicht davon entbinden.

Halten Sie die Anfragerate auf einem Niveau, das ein Mensch plausibel erzeugen könnte, hören Sie auf, sobald Sie einen Nachweis haben, und testen Sie mit Ihren eigenen Daten statt mit denen anderer.

05Wie Sie melden

Schreiben Sie an security@sekurity.de. Ist der Befund sensibel, verschlüsseln Sie ihn bitte mit unserem PGP-Schlüssel — demselben Schlüssel, der unsere security.txt signiert.

Eine Meldung, die wir nachvollziehen können, wird schneller behoben als eine ausführliche, die wir nicht reproduzieren können. Stellen Sie die Reproduktion daher an den Anfang.

  • Die betroffene URL oder Komponente und genug Detail, um den Befund zu reproduzieren
  • Was ein Angreifer damit gewinnt — die Auswirkung, nicht nur den Mechanismus
  • Einen Proof of Concept, idealerweise den kleinsten, der das Problem zeigt
  • Ob und ungefähr wann Sie zu veröffentlichen beabsichtigen

06Wozu wir uns verpflichten

Wir sind ein kleines Team. Die folgenden Fristen sind daher bewusst zurückhaltend gewählt, damit wir sie auch einhalten können. In der Praxis beantworten wir die meisten Meldungen noch in derselben Woche.

  • Wir bestätigen den Eingang Ihrer Meldung innerhalb von 5 Arbeitstagen
  • Wir geben Ihnen innerhalb von 15 Arbeitstagen eine erste Einschätzung — ob der Befund in den Geltungsbereich fällt und wie wir den Schweregrad sehen
  • Wir halten Sie mindestens alle 30 Tage auf dem Laufenden, solange das Problem offen ist
  • Wir sagen Ihnen Bescheid, sobald es behoben ist

07Safe Harbour

Wenn Sie sich an diese Richtlinie halten, wird die SEKurity GmbH wegen Ihrer Untersuchung keine zivilrechtlichen Ansprüche gegen Sie geltend machen und keine Strafverfolgung anregen oder unterstützen. Wir betrachten solche Tests als genehmigt.

Dieses Wort ist hier entscheidend: Die §§ 202a–202c StGB stellen den unbefugten Zugang unter Strafe, und die Befugnis ist genau der Unterschied zwischen Forschung und Straftat. Sollte ein Dritter wegen einer Untersuchung vorgehen, die Sie im Rahmen dieser Richtlinie auf unserer Website durchgeführt haben, werden wir öffentlich und schriftlich bestätigen, dass sie genehmigt war.

Die Grenzen, klar benannt — denn ein Safe Harbour mit verdeckten Rändern ist schlechter als gar keiner:

  • Er bindet allein die SEKurity GmbH. Wir können keine Zusicherung im Namen unseres Hosting-Anbieters abgeben oder für andere, deren Systeme Ihr Datenverkehr durchquert.
  • Er gilt für Tests innerhalb des oben beschriebenen Geltungsbereichs. Wechseln Sie auf andere Hosts, greifen Sie auf fremde Daten zu oder beeinträchtigen Sie die Verfügbarkeit, so gilt er nicht.
  • Er deckt keine Erpressung. Eine Meldung, die an eine Zahlung geknüpft ist, ist keine Forschung, und wir behandeln sie entsprechend.
  • Er setzt gutgläubiges Handeln voraus: Hören Sie beim Nachweis auf, erheben Sie nur die Daten, die zum Beleg nötig sind, speichern oder verbreiten Sie sie nicht, und sagen Sie uns, worauf Sie zugegriffen haben.

08Koordinierte Veröffentlichung

Wir möchten einen Befund aus dem Geltungsbereich beheben, bevor er veröffentlicht wird, und bitten Sie, mit der Veröffentlichung bis zur Auslieferung des Fixes oder 90 Tage ab Ihrer Meldung zu warten — je nachdem, was früher eintritt.

Neunzig Tage sind eine Obergrenze, kein Ziel. Beheben wir es in einer Woche, veröffentlichen Sie in einer Woche. Brauchen wir länger, fragen wir Sie, begründen es und akzeptieren, dass die Entscheidung letztlich bei Ihnen liegt.

Wir werden Sie nicht bitten, als Bedingung für eine Meldung eine Verschwiegenheitsvereinbarung zu unterzeichnen, und wir werden keine Veröffentlichungsfrist nutzen, um einen Befund auszusitzen.

09Anerkennung

Wir betreiben kein Bug-Bounty-Programm und zahlen keine Prämien für Meldungen. Das hier klar zu sagen ist fairer, als Sie es erst nach getaner Arbeit herausfinden zu lassen.

Was wir anbieten können, ist Anerkennung: Wir nennen Sie auf Wunsch namentlich, mit einem Link Ihrer Wahl, im Fix und überall dort, wo wir den Befund beschreiben — oder wahren Ihre Anonymität, wenn Ihnen das lieber ist.

Meldeweg

PGP-Schlüssel
https://blog.sekurity.de/pgp-key.asc

8AE8 B278 FF65 1C43 2196 0CEB F29B 8AB7 CC6C FCEC