Ich habe meine Nebenprojekte auf Sicherheit geprüft – das habe ich herausgefunden
Ich habe vor Kurzem alle meine Nebenprojekte auf Sicherheit geprüft. Ich habe meine FastAPI-Backends, Telegram-Bots und Web-Apps überprüft. Ich dachte, ich wäre vorsichtig.
Ich habe mich geirrt.
Ich habe echte Bugs gefunden, die ich tatsächlich in die Produktion übernommen habe. Das sind keine theoretischen Probleme. Es sind Fehler, die mir passiert sind, während ich versucht habe, schnell voranzukommen.
Hier sind die wichtigsten Probleme, die ich gefunden habe, und wie man sie behebt:
- Bedingte Authentifizierung Ich habe Code geschrieben, der API-Keys nur dann prüfte, wenn ein Secret existierte. Wenn ich vergessen hatte, das Secret in meiner Umgebung zu setzen, wurde die Prüfung komplett übersprungen. Dadurch war meine API für jeden offen.
- Fix: Machen Sie die Authentifizierung niemals bedingt. Wenn das Secret fehlt, sollte die App einen Fehler ausgeben und stoppen.
- Leckage von Keys in der Git-Historie Ich habe alte API-Keys in meiner Git-Historie gefunden. Ich hatte sie später in .env-Dateien verschoben, aber Git bewahrt jede alte Version Ihres Codes für immer auf.
- Fix: Behandeln Sie jeden Key, der jemals in Git committet wurde, als kompromittiert. Widerrufen Sie ihn sofort. Verwenden Sie Tools wie
git-filter-repo, um Ihre Historie zu bereinigen.
- Übrig gebliebene Debug-Endpoints Ich habe Endpoints in der Produktion gelassen, die meine Datenbankkonfiguration und Systemeinstellungen anzeigten. Diese sind während der Entwicklung hilfreich, aber im Live-Betrieb gefährlich.
- Fix: Fügen Sie das Entfernen von Debug-Endpoints zu Ihrer Deployment-Checkliste hinzu.
- Ausführliche Fehlermeldungen Ich habe rohe Systemfehler an den Benutzer zurückgegeben. Diese Fehler offenbaren Dateipfade, Datenbanktypen und Bibliotheksversionen. Ein Angreifer kann diese Daten nutzen, um Ihr System gezielt anzugreifen.
- Fix: Protokollieren Sie den vollständigen Fehler intern für sich selbst. Geben Sie dem Client eine generische Meldung wie „Internal Server Error“ zurück.
- XSS über
innerHTMLIch habeinnerHTMLverwendet, um Benutzerdaten in meinem Frontend darzustellen. Dies ermöglicht es Angreifern, Skripte in Ihre Website einzuschleusen.
- Fix: Bereinigen Sie Daten immer (Sanitization) oder verwenden Sie
textContentanstelle voninnerHTML.
- Fehlendes Rate Limiting Ich hatte Endpoints, die ohne Limits teure KI-Modelle aufriefen. Ein einziger Benutzer konnte innerhalb von Minuten eine massive Rechnung verursachen.
- Fix: Authentifizierung stoppt unbefugte Benutzer. Rate Limiting verhindert, dass autorisierte Benutzer Ihr System missbrauchen. Sie benötigen beides.
- Zu lockere CORS-Einstellungen
Ich habe
allow_origins=["*"]in meiner Middleware verwendet. Dies erlaubt es jeder Website, Anfragen an Ihre API zu stellen.
- Fix: Erlauben Sie in der Produktion nur Ihre spezifischen Domains.
- Dateileakage Ich habe Code geschrieben, der temporäre Dateien erstellt, diese aber nicht löschte, wenn der Prozess abstürzte. Diese Dateien bleiben für immer auf Ihrem Server.
- Lösung: Verwenden Sie einen try-finally-Block, um sicherzustellen, dass Dateien auch dann gelöscht werden, wenn ein Fehler auftritt.
Sicherheitslücken sind selten beabsichtigt. Sie sind das Ergebnis der Einstellung: „Das behebe ich später.“ Das „Später“ kommt nie.
Integrieren Sie Sicherheit von Tag eins an in Ihren Workflow. Überprüfen Sie Ihren Code, bevor Sie ihn committen und bevor Sie ihn deployen.
Quelle: https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb