GeckoFlag ist eine Software, die auf Ihrem eigenen Server läuft. Damit Sie Ihre Projektdaten mit gutem Gefühl anvertrauen können, führt der Entwickler selbst bei jedem Release Sicherheitsprüfungen durch und veröffentlicht deren Inhalt und Ergebnisse auf dieser Seite.
Diese Seite dokumentiert Selbstprüfungen durch den Entwickler. Es handelt sich nicht um eine Zertifizierung oder ein Audit durch eine unabhängige Stelle. Da wir zugleich offenlegen, was geprüft wird, können Sie diese Angaben als Grundlage für Ihre Entscheidung über den Einsatz nutzen.
- Maßnahmen im Design
- Prüfungen bei jedem Release
- Prüfergebnisse der aktuellen Version
- Nicht geprüfte Bereiche
- Sicherheitslücken melden
- Prüfung der Distributionsdateien
- Empfohlene Einstellungen
Sicherheitsmaßnahmen im Design
GeckoFlag enthält standardmäßig die folgenden Maßnahmen. Alle sind ohne weitere Konfiguration aktiv.
Schutz von Passwörtern
Passwörter werden nicht im Klartext gespeichert, sondern mit bcrypt gehasht. Auch Token zum Zurücksetzen des Passworts werden gehasht gespeichert, und die Anzahl der Anfragen zum Zurücksetzen ist begrenzt.
Begrenzung von Anmeldeversuchen
Fehlgeschlagene Anmeldungen werden sowohl pro Konto als auch pro Client-IP-Adresse gezählt; nach Überschreiten einer bestimmten Anzahl wird die Anmeldung vorübergehend gesperrt. Das erschwert Brute-Force-Angriffe ebenso wie Angriffe auf viele Konten gleichzeitig.
Schutz vor CSRF
Bei jedem Absenden eines Formulars wird ein Token geprüft. So werden Aktionen verhindert, die von externen Websites im Namen eines Benutzers ausgelöst werden.
Schutz vor XSS
Rich Text in Vorgängen, Kommentaren, im Wiki, in Notizen usw. wird mit HTML Purifier so bereinigt, dass beim Speichern und Anzeigen nur zugelassene Tags erhalten bleiben. Links sind nur mit http und https erlaubt. Auch von der KI erzeugte Texte durchlaufen vor dem Speichern dieselbe Verarbeitung.
Schutz vor SQL-Injection
Datenbankzugriffe erfolgen über das ORM von CakePHP 5 und Prepared Statements.
Prüfung des Host-Headers
Links in E-Mails zum Zurücksetzen des Passworts, in Einladungen und in Benachrichtigungen werden nicht anhand des Host-Headers der Anfrage, sondern anhand der registrierten Domain erzeugt. Über einen manipulierten Host-Header lassen sich die Links in E-Mails daher nicht auf externe Adressen umleiten.
Speicherung von Dateien
Bilder in Vorgängen und Projektdateien werden außerhalb des öffentlichen Ordners gespeichert und erst ausgeliefert, nachdem geprüft wurde, ob die anfragende Person Mitglied des Projekts ist. Dateien mit ausführbaren Endungen wie PHP werden nicht angenommen.
Verschlüsselung von API-Schlüsseln
Der Claude-API-Schlüssel für die KI-Funktionen wird verschlüsselt in der Datenbank gespeichert.
API-Tokens der Claude-Integration
Die Claude-Integration ist standardmäßig deaktiviert und kann nur genutzt werden, wenn ein Administrator sie aktiviert und für einzelne Benutzer freigibt. Von jedem API-Token wird nur ein Hash gespeichert, und es kann ein Ablaufdatum festgelegt werden. Eine Passwortänderung macht die Tokens ungültig. Die API prüft dieselben Berechtigungen wie die Bildschirme, und schreibgeschützte Tokens können nichts ändern.
Beschränkung nach IP-Adresse
Administratoren können festlegen, von welchen IP-Adressen aus der Zugriff erlaubt ist.
Sperrung des Installers
Nach Abschluss der Einrichtung ist der Installer nicht mehr erreichbar.
Schutz nicht öffentlicher Ordner
Unter Apache wird der direkte Zugriff auf Ordner mit Konfiguration, Protokollen, Quellcode usw. standardmäßig verweigert (für Nginx siehe Empfohlene Einstellungen).
Automatisches Backup vor Updates
Vor einem Software-Update wird automatisch ein Backup erstellt.
Signaturprüfung von Update-Dateien
Offizielle Update-Dateien tragen eine elektronische Signatur des Entwicklers (Ed25519). Vor dem Update werden die Signatur und der Inhalt aller Dateien abgeglichen; manipulierte oder nicht offizielle Update-Dateien werden nicht eingespielt.
Prüfung von Bild-Uploads
Bei Bildern wie Avataren, Vorschaubildern und Logos wird das Format anhand des Dateiinhalts bestimmt, und die Bilder werden unter einem zufälligen Dateinamen gespeichert. Aus den Bildordnern werden keine anderen Dateien als Bilder ausgeliefert (unter Apache). SVG wird nicht angenommen.
Sicherheits-Header
Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy und Permissions-Policy werden gesendet, um Clickjacking und das Abfließen von Informationen an externe Websites zu verhindern. Beim Betrieb über HTTPS wird zusätzlich Strict-Transport-Security gesendet, damit der Browser stets über HTTPS verbindet.
Sitzungsverwaltung
Bei jeder Anmeldung wird die Sitzung neu erstellt. Änderungen von Berechtigungen, das Löschen eines Kontos und Passwortänderungen wirken sich sofort auch auf bereits angemeldete Sitzungen aus. Zum Ändern der E-Mail-Adresse und des Passworts muss das aktuelle Passwort eingegeben werden.
Sicherheitsprüfungen bei jedem Release
Vor der Veröffentlichung einer neuen Version führen wir die folgenden Prüfungen durch. Die Prüfungen finden in einer Testumgebung mit derselben Konfiguration wie im Produktivbetrieb statt, niemals an öffentlich laufenden Diensten oder an den Servern unserer Kunden. Was bei der aktuellen Version durchgeführt wurde, finden Sie unter „Prüfergebnisse der aktuellen Version“.
| Bereich | Prüfinhalt | Werkzeuge / Standards | Häufigkeit |
|---|---|---|---|
| Abhängigkeiten | Prüfung der verwendeten Bibliotheken auf bekannte Sicherheitslücken und Erstellung einer Liste der verwendeten Bibliotheken (SBOM) | composer audit, OSV-Scanner, CycloneDX | Bei jedem Release |
| Statische Analyse | Erkennung von Pfaden im Quellcode, auf denen Eingabewerte gefährliche Verarbeitungen erreichen (XSS, SQL-Injection usw.) | Psalm (Taint-Analyse), PHPStan (Level 5), Semgrep | Bei jedem Release |
| Geheime Daten | Ob Passwörter oder API-Schlüssel im Quellcode oder in den Distributionsdateien enthalten sind | gitleaks | Bei jedem Release |
| Dynamischer Scan | Senden echter Angriffsanfragen im angemeldeten Zustand als Administrator und als normaler Benutzer und Prüfung der Reaktion | Nuclei | Bei jedem Release |
| Berechtigungsprüfung | Ob sich Vorgänge, Dateien und Notizen von Projekten, an denen man nicht beteiligt ist, durch Ändern der ID in der URL anzeigen oder bearbeiten lassen | Automatisierte Tests (PHPUnit), manuelle Prüfung | Bei jedem Release |
| Datei-Upload | Ob ausführbare Dateien, als Bilder getarnte Dateien, ZIP-Dateien mit Pfadmanipulation usw. abgewiesen werden | Code-Review, manuelle Prüfung | Bei jedem Release |
| XSS | Eingabe von Angriffszeichenfolgen in Vorgangsbeschreibungen, Kommentare, Wiki und KI-generierte Texte und Prüfung, dass keine Skripte ausgeführt werden | Code-Review, manuelle Prüfung | Bei jedem Release |
| Prüfung je Serverkonfiguration | Ob unter Apache und Nginx sowie bei verschiedenen Anordnungen des öffentlichen Ordners direkt auf Konfigurationsdateien oder Protokolle zugegriffen werden kann | Manuelle Prüfung | Bei jedem Release |
| Erweiterung für die Claude-Integration | Bekannte Schwachstellen in den Bibliotheken der Erweiterung, Umgang mit dem API-Token und Einschränkung der Anfrageziele | npm audit, gitleaks, Code-Review | Bei jeder Version der Erweiterung |
| Selbstprüfung anhand einer Checkliste | Punktweise Prüfung von Authentifizierung, Sitzungen, Eingabevalidierung, Fehlerbehandlung usw. | In Anlehnung an OWASP ASVS 5.0 Level 1, IPA (Japan): „How to Secure Your Website“ | Bei jeder Hauptversion |
| Offizielle Website | HTTPS-Konfiguration und Sicherheits-Header von geckoflag.com | SSL Labs, Mozilla Observatory | Einmal im Monat |
Werden Probleme mit dem Schweregrad „Hoch“ oder „Mittel“ gefunden, erfolgt kein Release, bevor sie behoben und erneut geprüft wurden. Probleme mit dem Schweregrad „Niedrig“ werden geprüft und entweder behoben, oder es wird dokumentiert, warum sie keine Auswirkungen haben.
Richtlinie für die Aktualisierung von Abhängigkeiten
Die von GeckoFlag verwendeten Bibliotheken (z. B. CakePHP) werden bei jedem Release auf bekannte Sicherheitslücken geprüft. Wird eine Sicherheitslücke gefunden, die GeckoFlag betrifft, veröffentlichen wir eine korrigierte Version in der Regel innerhalb der folgenden Fristen.
- Schweregrad „Kritisch“ und „Hoch“: innerhalb von 14 Tagen nach Bekanntgabe
- Schweregrad „Mittel“: innerhalb von 30 Tagen nach Bekanntgabe
- Schweregrad „Niedrig“: mit dem nächsten Release (spätestens innerhalb von 90 Tagen)
Auch Sicherheitslücken, die sich bei der Art und Weise, wie GeckoFlag die Bibliothek nutzt, nicht auswirken, werden mit dem nächsten Release durch ein Update auf eine korrigierte Version behoben. Bibliotheken für die Entwicklung sind in den Distributionsdateien nicht enthalten.
Prüfergebnisse der aktuellen Version: v1.11.0
Geprüft wurden die Änderungen seit v1.10.0 (die Claude-Integration, Text- und Hintergrundfarben sowie Trennlinien im formatierten Text u. a.); dabei wurden auch Probleme behoben, die bereits in früheren Versionen enthalten waren. Wenn Sie v1.10.0 oder älter verwenden, empfehlen wir das Update auf v1.11.0.
| Prüfung | Werkzeuge (Version) | Funde (Hoch / Mittel / Niedrig) | Maßnahme |
|---|---|---|---|
| Abhängigkeiten | GitHub Advisory Database, FriendsOfPHP security-advisories (Datenstand 2026-10-28; 89 Pakete) | 0 / 0 / 0 | Keine bekannten Schwachstellen in den Bibliotheken der Distributionsdateien. Bekannte Schwachstellen in reinen Entwicklungsbibliotheken wurden in v1.11.0 durch ein Update behoben (Entwicklungsbibliotheken sind nicht in den Distributionsdateien enthalten) |
| Statische Analyse / Code-Review | Psalm 5.26.1 (Taint-Analyse), PHPStan 2.1.17 (Level 5), Semgrep 1.182.1, manuelles Code-Review (Änderungen seit v1.10.0: API und Tokens der Claude-Integration, formatierter Text, angemeldet bleiben, Software-Updates; außerdem die Ausgabe von Links auf allen Bildschirmen) | 1 / 1 / 3 | Die Funde mit „Hoch“ und „Mittel“ sowie 2 Funde mit „Niedrig“ wurden in v1.11.0 behoben. Der verbleibende Fund mit „Niedrig“ tritt nur durch Aktionen des Benutzers selbst auf; seine Auswirkung ist nachweislich begrenzt. Der Fund mit „Hoch“ war bereits in früheren Versionen enthalten |
| Geheime Daten | gitleaks 8.24.2 | 0 / 0 / 0 | Sowohl der Quellcode als auch die Distributionsdateien wurden geprüft. Beide 2 Treffer waren Fehlalarme (z. B. Beispielzeichenfolgen in externen Bibliotheken) |
| Prüfung der Korrekturen | Funktionsprüfung in der Testumgebung (PHP 8.3, MariaDB 10.11, Apache 2.4, Nginx 1.24, Chromium) | — | Für jeden Fund bestätigt, dass sich das ursprüngliche Problem nicht mehr reproduzieren lässt |
| Dynamischer Scan | Nuclei v3.11.1 (Vorlagen v10.5.1), ohne Anmeldung sowie als Administrator und Mitglied | 0 / 0 / 0 | Keine Probleme |
| Berechtigungsprüfung | PHPUnit 12.5 (454 automatisierte Tests; zusätzlich zu den bisherigen Prüfungen wurde bestätigt, dass die API der Claude-Integration Anfragen ohne Token, mit schreibgeschütztem Token, von nicht berechtigten Benutzern und bei deaktivierter Funktion ablehnt und nie Projekte erreicht, denen der Benutzer nicht angehört) | 0 / 0 / 0 | Keine Probleme |
| Prüfung je Serverkonfiguration | Manuell (Apache 2.4 und Nginx 1.24, je 2 Anordnungen des öffentlichen Ordners; 39 URLs, darunter Konfigurationsdateien, Protokolle, Sitzungen und gespeicherte Dateien) | 0 / 0 / 1 | In v1.11.0 behoben: Direkter Zugriff auf den Dateiordner älterer Versionen (files) wird jetzt auch unter Apache vollständig abgelehnt. Sonst keine Probleme |
| Checkliste | OWASP ASVS 5.0 Level 1 (70 Punkte) | 50 von 56 anwendbaren Punkten erfüllt | Diesmal nicht überprüft (das Ergebnis von v1.10.0 gilt weiter) |
| Erweiterung für die Claude-Integration | npm audit, gitleaks 8.24.2, mcpb validate, manuelles Code-Review (geckoflag-1.0.0.mcpb) | 0 / 0 / 0 | Keine bekannten Schwachstellen, die die Bibliotheken in der Distributionsdatei betreffen. Geprüft wurden der Umgang mit dem API-Token und die Einschränkung der Anfrageziele (nur HTTPS, keine Weiterleitungen) |
Die Prüfergebnisse aller Versionen, auch der früheren, finden Sie unter „Frühere Prüfergebnisse“.
Nicht geprüfte Bereiche
Die oben beschriebenen Prüfungen haben folgende Grenzen. Bitte berücksichtigen Sie diese Punkte auch, wenn Sie den Einsatz in Erwägung ziehen.
- Es wurde keine Prüfung durch Dritte durchgeführt. Code-Reviews oder Penetrationstests durch externe Fachleute wurden bisher nicht durchgeführt.
- Die Serverumgebung unserer Kunden ist nicht Gegenstand der Prüfung. Die Sicherheit hängt stark von der Konfiguration und dem Aktualisierungsstand von Betriebssystem, Webserver, PHP und Datenbank ab.
- Es wurden nicht alle Hosting-Umgebungen geprüft. Geprüft wurden nur die unter „Prüfergebnisse der aktuellen Version“ aufgeführten Konfigurationen.
- Externe Dienste sind nicht Gegenstand der Prüfung. Für die Sicherheit der von den KI-Funktionen genutzten API von Anthropic, der von der Claude-Integration genutzten Claude-Desktop-App, der Mailserver für den E-Mail-Versand usw. sind die jeweiligen Anbieter verantwortlich.
- Zu Problemen, die automatisierte Werkzeuge nicht erkennen. Arten von Problemen, die von Werkzeugen nicht erkannt werden (z. B. Fehler in der Geschäftslogik), werden durch manuelle Prüfungen ergänzt; eine vollständige Abdeckung ist jedoch nicht möglich.
Meldung gefundener Sicherheitslücken
Wenn Sie ein Problem finden, bei dem es sich um eine Sicherheitslücke in GeckoFlag handeln könnte, melden Sie es bitte nicht öffentlich, sondern direkt über die unten genannte Kontaktmöglichkeit. Jede Meldung wird vom Entwickler persönlich gelesen.
Kontakt für Meldungen: Bitte nutzen Sie das Kontaktformular und wählen Sie als Art der Anfrage „Meldung einer Sicherheitslücke“.
Was Ihre Meldung enthalten sollte
- Betroffene Version sowie die betroffene Seite bzw. Funktion
- Schritte zur Reproduktion (soweit möglich)
- Mögliche Auswirkungen
- Ihre Serverumgebung (PHP, Webserver usw.)
Unsere Bitte
- Führen Sie Tests nur in einer Umgebung durch, die Sie selbst verwalten, und unternehmen Sie keine Angriffe auf GeckoFlag-Installationen, die von anderen betrieben werden, oder auf geckoflag.com.
Auf Wunsch nennen wir Sie in den Sicherheitsinformationen zur korrigierten Version namentlich als Dank für Ihre Meldung.
SHA-256 der Distributionsdateien
Ob eine heruntergeladene Datei mit der offiziellen Datei identisch ist, können Sie durch Abgleich mit den folgenden Werten prüfen.
| Datei | SHA-256 |
|---|---|
| GeckoFlag - 1.11.0.zip | 33354ac588c4cb4de2953c3c26a484953c2bb886f38196ba4bcf4fe629648399 |
| geckoflag-1.0.0.mcpb | 44f2c6dfc9f437856d0680920a327820d757a14116064faa6e46ad8a961d0747 |
So prüfen Sie den Wert: Führen Sie unter Windows in PowerShell Get-FileHash Dateiname -Algorithm SHA256 aus, unter macOS und Linux shasum -a 256 Dateiname.
Empfohlene Einstellungen für einen sicheren Betrieb
Die Sicherheit von GeckoFlag hängt auch von der Konfiguration des Servers ab, auf dem es installiert ist. Wir empfehlen die folgenden Einstellungen.
- Die Installation unmittelbar nach dem Hochladen abschließen: Bis die Installation abgeschlossen ist, kann jeder, der die URL kennt, die Einrichtungsseite öffnen. Schließen Sie die Installation ab, sobald die Dateien auf dem Server liegen.
- Über HTTPS betreiben: Anmeldedaten und Projektinhalte werden verschlüsselt übertragen. Bei vielen Hosting-Anbietern sind kostenlose SSL-Zertifikate verfügbar. Beachten Sie: Wurde die Adresse einmal über HTTPS geöffnet, verbindet sich der Browser danach ein Jahr lang über HTTPS mit dieser Adresse (ab v1.10.0). Bitte berücksichtigen Sie dies, falls Sie HTTPS künftig nicht mehr verwenden möchten.
- Den öffentlichen Ordner (Document Root) auf webroot setzen: Konfigurationsdateien und Protokolle liegen dann an einer Stelle, die aus dem Web nicht erreichbar ist.
- Bei Nginx die Konfiguration ergänzen: Unter Nginx ist .htaccess wirkungslos. Verweigern Sie gesondert den Zugriff auf nicht öffentliche Ordner und stellen Sie ein, dass im Upload-Ordner für Bilder (webroot/img) kein PHP ausgeführt wird. Ein Konfigurationsbeispiel finden Sie im Handbuch (Installation).
- Auf die neueste Version aktualisieren: Sicherheitskorrekturen werden mit der jeweils neuesten Version bereitgestellt. Beziehen Sie Update-Dateien von der offiziellen Website und prüfen Sie den SHA-256-Wert. Ab v1.10.0 wird vor dem Update zusätzlich automatisch die Signatur geprüft.
- PHP und Datenbank auf unterstützten Versionen halten: Für PHP-Versionen, deren Support beendet ist, werden keine Korrekturen mehr bereitgestellt.
- Administratorkonten schützen: Verwenden Sie lange, schwer zu erratende Passwörter und vergeben Sie Administratorrechte nur an Personen, die sie benötigen.
- Bei interner Nutzung die IP-Beschränkung verwenden: Unter „Einstellungen“ können Sie festlegen, von welchen IP-Adressen aus der Zugriff möglich ist.
- Regelmäßig Backups erstellen: Bewahren Sie die Datenbank und die hochgeladenen Dateien an einem vom Server getrennten Ort auf.