Übernommenen Code prüfen — wo fängt man beim OWASP Top 10 Code Review am besten an?

Bei der manuellen Suche bringt eine einfache Volltextsuche nach bestimmten Mustern extrem viel: 1) Datenbankaufrufe, bei denen Variablen direkt in den Query-String gemergt werden, 2) unverschlüsselte API-Keys im Code, 3) Catch-Blöcke, die sensible System-Stacktraces an den Client zurückgeben. Das Ganze dauert vielleicht ein paar Stunden.

Als wir ein Portal ähnlicher Größe übernommen haben, haben wir per manuellem Review innerhalb von zwei Tagen 5 verschiedene Rechteausweitungen gefunden. Die Scanner hatten davon keine einzige bemerkt, weil eben nur ein Mensch mit Verständnis für die Business Logic weiß, wer welche Daten eigentlich sehen darf.

Prüft als Erstes die Dependencies der Drittanbieter-Bibliotheken. Lasst die Audit-Befehle eures Paketmanagers laufen und aktualisiert Pakete mit bekannten Schwachstellen. Veraltete Libraries sind fast immer das größte Einfallstor, das Agenturen hinterlassen.

Für zwei Entwickler, die den Code nicht geschrieben haben, ist es verdammt schwer, eine fremde Architektur nur anhand einer OWASP-Liste abzusichern. Wenn die Zeit drängt, fokussiert euch rein auf Zugriffsrechte und Datenbankabfragen – verliert euch nicht in komplexen Krypto-Details.

schaut vor allem ob man über id parameter in der url auf bestellungen anderer zugreifen kann agenturen vergessen diese checks im backend echt ständig

Edit: Ich habe ein paar Tippfehler korrigiert.

Bei Verträgen mit Geschäftskunden im Logistikbereich ist es völlig normal, dass ein unabhängiger Sicherheitsprüfbericht verlangt wird. Euer internes Review stärkt das System zwar enorm, ersetzt aber rechtlich oft kein externes Audit.

Handelt es sich um eine Multi-Tenant-Architektur, teilen sich also alle Logistikkunden dieselbe Datenbank? Wenn ja, muss euer Hauptaugenmerk auf der Mandantentrennung liegen, damit kein Kunde jemals die Daten eines anderen einsehen kann.

Auch wenn es für kleine Teams erstmal einschüchternd wirkt: Den OWASP-Leitfaden Schritt für Schritt als Checkliste durchzugehen, bringt dem Team extrem viel Engineering-Know-how. Je mehr Logikfehler ihr jetzt behebt, desto stabiler und robuster wird am Ende eure gesamte Architektur.

Der billige Weg stellt sich oft im Nachhinein als teuer heraus. Dass das Backup im gleichen Netzwerk und mit derselben Identität erreichbar ist, macht es zum Teil des Ziels.

Ein Thema, das gerade aktuell ist. Wenn du das nicht von Anfang an schriftlich festhältst, gibt es später Streit.

Schreibt mir, wenn ihr Fragen habt, ich antworte so gut ich kann.

Teilweise stimme ich zu, teilweise nicht. Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten.

Ich fasse kurz zusammen, was bisher gesagt wurde. Fehler auf der owasp top 10 code review-Seite sind meist rückgängig zu machen, aber teuer.

Nur als Notiz, könnte nützlich sein.

Da verstehe ich etwas nicht ganz. Wenn der Benachrichtigungsweg lang ist, kommen keine Benachrichtigungen; keine Benachrichtigung bedeutet spät erkannte Vorfälle.

Nur weil alle es tun heißt es nicht, dass es richtig ist. Viel Erfolg.

Hier lauert eine Falle, die ich nicht unerwähnt lassen möchte. Menschen verteidigen nicht den Prozess sondern die Gewohnheit. Der Widerstand kommt daher.

Aus Erfahrung weiß ich das.

Ich spreche mal aus der Gegenperspektive, ich bin auf der Lieferantenseite. Verlasst euch nicht auf eine einzige Maßnahme; geht schichtweise vor.

Das allein zu versuchen, ist der teuerste Weg. An deiner Stelle würde ich so vorgehen.

gespeichert.

Im Großen und Ganzen richtig, aber ein Punkt fehlt. Schaut zuerst, welche Daten ihr bei der Entscheidungsfindung zur Hand habt.

Wenn ihr das Ergebnis hier postet hilft es auch anderen.

Genau so ist es. Bei uns war der größte Zeitfresser die Unklarheit darüber, wer entscheidet.

Das allein zu versuchen, ist der teuerste Weg.