Bug Bounty Programm

Bei Appbox ist Sicherheit eine grundlegende Priorität. Wir ermutigen Sicherheitsforscher aktiv dabei zu helfen, unsere Plattform zu stärken, indem sie potenzielle Schwachstellen identifizieren und melden. Dieses Programm beschreibt unseren Ansatz für verantwortungsvolle Sicherheitsforschung, wie wir mit Schwachstellenmeldungen umgehen und welche Belohnungen wir Forschern anbieten, die zur Verbesserung unserer Sicherheitslage beitragen.

Unser Engagement

Wenn ihr an unserem Bug Bounty Programm teilnehmt, versprechen wir:

• Eure Meldung zeitnah zu bestätigen und zu bewerten
• Bestätigte Schwachstellen mit angemessener Dringlichkeit zu behandeln
• Euch für einzigartige, bisher nicht gemeldete Schwachstellen anzuerkennen und zu belohnen, die zu Sicherheitsverbesserungen führen

Programm-Abdeckung

Dieses Bug Bounty Programm gilt für die folgenden Appbox-Plattformen:

• Appbox Hauptwebsite [https://www.appbox.co]
• Appbox Kontrollpanel [https://www.appbox.co/login]
• Appbox Hosting-Infrastruktur [username.appboxes.co] - Nur Infrastruktur, keine Kundenanwendungen

Hinweis: Während unsere Hosting-Infrastruktur (username.appboxes.co) im Geltungsbereich liegt, sind Schwachstellen in von Kunden bereitgestellten Drittanbieter-Anwendungen ausgeschlossen. Siehe Ausschlüsse unten.

Was als gültige Schwachstelle qualifiziert

Um für unser Bug Bounty Programm zu qualifizieren, muss eine Einreichung ALLE folgenden Kriterien erfüllen:

1. Tatsächliche Ausnutzung demonstrieren

• Ein funktionierender Proof of Concept einschließen, der zeigt, dass die Schwachstelle ausgenutzt werden kann
• Klare Sicherheitsauswirkungen zeigen, theoretische Schwachstellen ohne nachgewiesenen Schaden qualifizieren nicht
• Beweisen, dass ein Angreifer tatsächlich Benutzerdaten, Konten oder die Systemintegrität kompromittieren könnte

2. Im Geltungsbereich liegende Systeme betreffen

• Die Schwachstelle muss in Appbox' proprietärem Code oder Infrastruktur existieren
• Muss Systeme betreffen, die explizit unter "Programm-Abdeckung" oben aufgeführt sind
• Muss in unseren Produktions- oder Staging-Umgebungen reproduzierbar sein

3. Zuvor nicht gemeldet sein

• Die Schwachstelle muss neu entdeckt und uns noch nicht bekannt sein
• Doppelte Meldungen oder Varianten bekannter Probleme qualifizieren nicht

Ausgeschlossene Bereiche und Probleme

Die folgenden gelten als außerhalb des Geltungsbereichs unseres Bug Bounty Programms:

Drittanbietersysteme und Integrationen

• WHMCS Client Area [https://billing.appbox.co] - Melden an WHMCS Security
• Chatwoot Chat-Widget - Melden an Chatwoot Security
• Von Kunden bereitgestellte Anwendungen [app.username.appboxes.co] - Schwachstellen in Drittanbieter-Anwendungen (WordPress, Nextcloud, etc.), die auf unserer Infrastruktur gehostet werden, sollten den jeweiligen Anwendungsanbietern gemeldet werden
• Alle anderen Drittanbieterdienste, Plugins oder Integrationen, die wir verwenden
• IP-Adressen oder Domains, die nicht direkt von Appbox kontrolliert werden
• Veraltete oder außer Betrieb genommene Systeme, die nicht mehr aktiv genutzt werden

Außerhalb des Geltungsbereichs für Hosting-Infrastruktur:

• Schwachstellen im von Kunden bereitgestellten Anwendungscode (WordPress, Nextcloud, etc.)
• Standardkonfigurationen von Drittanbieter-Anwendungen
• Sicherheitsprobleme, die spezifisch für eine bestimmte Anwendungsversion sind

Sicherheitsheader und Härtung

• Fehlende Sicherheitsheader (X-Frame-Options, COOP, COEP, MTA-STS, etc.) es sei denn, ihr demonstriert eine tatsächliche Ausnutzung, die zu Datenkompromittierung führt
• Fehlende rel="noopener" oder rel="noreferrer" Attribute
• Server-Versionsoffenlegung oder HTTP-Header-Informationsleckage
• Cookie-Attribute bei nicht-sensiblen Cookies (Analytics, Präferenzen, etc.)

Informationsoffenlegung mit geringem Einfluss

• Ausführliche Fehlermeldungen, die keine sensiblen Daten offenlegen (Passwörter, Token, personenbezogene Daten)
• Pfadoffenlegung ohne nachgewiesene Pfadtraversierung oder Dateizugriff
• Identifizierung des Technologie-Stacks (PHP-Version, Framework-Erkennung, etc.)
• Generische Anwendungsantworten oder -verhalten

Designentscheidungen und theoretische Probleme

• Login-CSRF (bietet dem Angreifer keinen Zugang zu Opferkonten)
• Benutzeraufzählung über Timing-Angriffe oder differenzielle Antworten (es sei denn Teil einer größeren Angriffskette)
• Clickjacking ohne nachgewiesene Ausnutzung sensibler Funktionalität
• CORS-Konfigurationen auf nicht-sensiblen Endpunkten
• Fehlende Ratenbegrenzung es sei denn, ihr demonstriert tatsächlichen Missbrauch (DoS ist weiterhin ausgeschlossen)

Angriffsvoraussetzungen

• Sicherheitsprobleme, die unsere Standard-Anwendungskonfigurationen nicht betreffen
• Schwachstellen, die nicht-standardmäßige Konfigurationen erfordern
• Schwachstellen in unseren Containern, die benutzerdefinierte oder modifizierte Setups erfordern
• Probleme, die eine Kompromittierung auf Netzwerkebene erfordern (MITM, DNS-Poisoning, ARP-Spoofing)

Verbotene Testmethoden

• Timing-basierte Informationsoffenlegungs-Angriffe
• Prozessaufzählungstechniken
• Jede Form von Denial-of-Service oder hochvolumigen Angriffen
• Social Engineering und Phishing-Techniken
• Automatisierte Sicherheitsscans, die übermäßigen Traffic oder Lasten generieren
• Testen von nicht-funktionalen Features oder Seiten (z.B. Registrierungsseiten, die noch nicht in Produktion sind)

Ungültige Berichtstypen

• Berichte, die ausschließlich auf automatisierter Scanner-Ausgabe basieren ohne manuelle Validierung
• Generische Empfehlungen ohne Nachweis tatsächlicher Schwachstellen
• Best-Practice-Vorschläge ohne Sicherheitsauswirkung
• Compliance-Beobachtungen (PCI-DSS, DSGVO, etc.) ohne Nachweis der Ausnutzbarkeit

Belohnungsstruktur

Hauptwebsite und Kontrollpanel

Hosting-Infrastruktur

Mitwirkende, die gültige Schwachstellen melden, werden in unserer Security Researchers Hall of Fame als Zeichen unserer Wertschätzung anerkannt.

Erforderliche Berichtsqualität

Alle Schwachstellenberichte müssen enthalten:

• Klare Schwachstellenbeschreibung - Erklärt, was die Schwachstelle ist und warum sie wichtig ist
• Betroffenes System/URL - Gebt genau an, wo die Schwachstelle existiert
• Schritt-für-Schritt Reproduktion - Detaillierte Schritte, die es uns ermöglichen, das Problem zu reproduzieren
• Funktionierender Proof of Concept - Funktionale Demonstration der Ausnutzung (Code, Screenshots, Video)
• Tatsächliche Sicherheitsauswirkung - Demonstriert, was ein Angreifer erreichen könnte, nicht theoretische Möglichkeiten
• Eure eigenen Tests - Validiert Erkenntnisse manuell, leitet nicht einfach Scanner-Ausgaben weiter

Berichte, denen diese Elemente fehlen oder die aus generischen Sicherheitsempfehlungen bestehen, qualifizieren nicht für Belohnungen.

Eure Belohnung beanspruchen

• Ihr könnt zwischen zwei Belohnungsoptionen wählen:
  • Direkte PayPal-Zahlung (erfordert ein gültiges PayPal-Konto)
  • Appbox Service-Guthaben (anwendbar auf jeden Appbox-Service, nicht übertragbar)

Teilnahmerichtlinien

• Haltet euch an diese Richtlinie, unsere Nutzungsbedingungen und alle geltenden Gesetze
• Meldet Schwachstellen umgehend nach der Entdeckung
• Respektiert die Privatsphäre der Nutzer und die Systemintegrität während eurer Forschung
• Reicht alle Schwachstellenmeldungen ausschließlich über unser Kontaktformular ein
• Wahrt die Vertraulichkeit über entdeckte Schwachstellen bis zur Behebung
• Beschränkt eure Tests auf Systeme, die explizit in diesem Programm enthalten sind
• Falls ihr unerwarteten Zugang zu sensiblen Daten erhaltet: greift nur auf die Mindestmenge zu, die nötig ist, um das Problem zu demonstrieren, stoppt die Tests sofort und meldet die Schwachstelle umgehend
• Verwendet nur eure eigenen Testkonten für jede Interaktion mit unseren Systemen
• Versucht niemals, Appbox basierend auf euren Erkenntnissen zu erpressen
• Überprüft eure Erkenntnisse - Testet, dass euer Proof of Concept tatsächlich funktioniert, bevor ihr ihn einreicht
• Fokussiert euch auf die Auswirkung - Priorisiert Schwachstellen, die echten Schaden verursachen könnten, gegenüber theoretischen Problemen

Rechtsschutz

Sicherheitsforscher, die dieser Richtlinie folgen, können erwarten:

• Schutz vor rechtlichen Schritten für gutgläubige Sicherheitsforschung, die innerhalb dieser Richtlinien durchgeführt wird
• Befreiung von Anti-Umgehungsrechtsansprüchen, wenn nötig für legitime Sicherheitsforschung
• Verzicht auf bestimmte Richtlinienbeschränkungen, die sonst Sicherheitstests verhindern würden
• Anerkennung, dass konforme Sicherheitsforschung vorteilhaft und in gutem Glauben durchgeführt wird

Ihr bleibt dafür verantwortlich, alle geltenden Gesetze einzuhalten. Falls ihr rechtlichen Schritten von Dritten ausgesetzt seid, während ihr euch an diese Richtlinie haltet, werden wir bestätigen, dass eure Handlungen in Übereinstimmung mit unserem Programm durchgeführt wurden. Falls ihr unsicher seid, ob eure geplanten Forschungsaktivitäten dieser Richtlinie entsprechen, kontaktiert uns bitte über das Kontaktformular, bevor ihr fortfahrt.

Meldeprozess

Um eine Schwachstelle zu melden, erstellt ein detailliertes Ticket über unser Kontaktformular.

• Euer Bericht sollte umfassende Schritte zur Reproduktion der Schwachstelle enthalten. Ihr könnt diese Vorlage als Leitfaden verwenden: https://github.com/ZephrFish/BugBountyTemplates/blob/master/Example.md
• Alle Programmkommunikationen müssen über unsere offizielle Support-Ticket-Plattform laufen
• Die öffentliche Preisgabe jeder Schwachstelle ohne ausdrückliche schriftliche Genehmigung von Appbox verstößt gegen die Bedingungen dieses Programms und disqualifiziert euch vom Erhalt einer Belohnung

Was nach eurer Meldung passiert

• Gültige Schwachstellen: Wir werden eure Meldung bestätigen, an einer Behebung arbeiten und eure Belohnung bearbeiten
• Ungültige Berichte: Wir werden erklären, warum der Bericht nicht qualifiziert und können Hinweise für zukünftige Einreichungen geben
• Außerhalb des Geltungsbereichs liegende Berichte: Wir werden euch an den entsprechenden Anbieter weiterleiten oder erklären, warum das Problem nicht abgedeckt ist

Wir schätzen qualitativ hochwertige Forschung und konstruktive Beiträge zu unserer Sicherheit. Vielen Dank, dass ihr helft, Appbox sicher zu halten.