Zenz.cc

Der Angriffsvektor “SQL-Injection” ist seit Jahren die Nummer 1 bei den OWASP Top 10, und aus meiner Sicht ist das auch absolut berechtigt.

Was ist eine SQL-Injection?

Kurz gesagt, ermöglicht man einem Angreifer beliebige SQL-Kommandos auszuführen. Die Konsequenz: der Angreifern kann beliebige Daten aus der Datenbank abfragen (z. B. Passwörter), Daten in der Datenbank manipulieren oder die Struktur der Datenbank zu ändern bzw. Daten zu löschen.

Technisch gesehen wird das eigentlich SQL-Kommando, das von der Applikation ausgeführt wird, so manipuliert, dass auf Daten zugegriffen werden kann, auf ein “normaler” Benutzer keinen Zugriff haben sollte.

Eine detaillierte Beschreibung kann auf der Seite der OWASP finden. Continue reading “SQL Injection”

Die CSRF-Attacke kann dazu führen, dass der Benutzer ungewollte Aktionen ausführt, ohne dass er dies bemerkt. Beispielsweise könnten so Passwörter oder Email-Adressen im jeweiligen System, auf vom Angreifer ausgewählte Werte, geändert werden.

Da schon viele Frameworks Gegenmaßnamen eingebaut haben, kommt diese Lücke nur noch recht selten vor und ist deshalb 2017 aus den OWASP Top 10 rausgeflogen. Allerdings kann diese sehr mächtig sein, daher halte ich es für wichtig, dass man als Web-Entwickler darüber Bescheid weiß.

Wie funktioniert die Attacke?

Aufgrund des Session-Cookies, nachdem man sich eingeloggt hat, bleibt man auf der Webseite angemeldet. Bei manchen Webseiten (z.B. Facebook) gibt es ein recht langes Timeout, meist mehrere Wochen, sodass man sofort wieder angemeldet ist, wenn man das nächste Mal die Webseite besucht.
Diesen Umstand kann man ausnutzen, wenn es dem Angreifer gelingt eine gefälschte Anfrage an diese Website zu stellen, wenn man gerade eingeloggt ist. Falls es keine Gegenmaßnahmen gibt, ist es dem Angreifer möglich alle Aktionen die man als echter Benutzer durchführen kann, auch durchzuführen. Beispiele: Passwort ändern auf ein Passwort das der Angreifer aussucht, Email-Adresse auf eine Adresse des Angreifers ändern oder sonstige Daten so zu manipulieren, dass der Angreifer einen Vorteil daraus hat.
Dem Angreifer gelingt eine solche gefälschte Anfrage an die Website entweder über Links in Phishing-Mails oder aber auch über versteckte Links (z.B. hinter Bildern) auf einer anderen unsicheren Webseite. Continue reading “Cross-Site Request Forgery – CSRF”

Der Einstieg um sicherer Web-Applikationen zu erstellen ist gar nicht mal so schwer – OWASP (Open Web Application Security Project) sei Dank.

Auf den OWASP Internetseiten findet man eigentlich alles was man braucht. Es wird im Detail erklärt welche Angriffsvektoren es gibt, wie man sich davor schützen kann und auch einen „Guide“ für Einsteiger gibt es.

Darüber hinaus gibt es auch Software-Libs, die bei der Implementierung sicherer Software, hilfreich sind und verschiedenste Tools, wie z.B. den ZAP-Proxy, die Sicherheitslücken automatisch auffinden können.

Und, und, und … am besten man schaut sich das ganze einfach an.

Die neuen OWASP Top 10 wurden gestern veröffentlicht.

Die Top 3 sind zu Recht „A1: Injection” (z.B. SQL-Injection), „A2: Broken Authentication“ und „A3: Sensitive Data Exposure“. Wobei A3 zuletzt an Position 6 war.
Neu in den Top 10 sind „A4: XML External Entities (XXE)“, „A8: Insecure Deserialization“, „A10: Insufficient Logging & Monitoring“. A4 und A8 wurden in den letzten Jahren in Community schon sehr breit behandelt und es ist daher auch nicht verwunderlich, dass es diese in die Top 10 geschafft haben. A10 finde ich interessant und es wichtig, dass es das es der Punkt „Logging & Monitoring“ in die Top 10 geschafft hat. „Cross-Site Request Forgery (CSRF)“ ist rausgeflogen, da die Lücke kaum noch vorhanden ist (nur mehr in 5% der Applikationen) und es gute Ansätze und Frameworks gibt um diesen Angriffsvektor zu unterbinden.

„A5: Broken Access Control“ ist für mich auch ein sehr wichtiger Punkt, der die alten Punkten, „Insecure Direct Object References“ und „Missing Function Level Access Control“, nun zusammenfasst. Er ist deshalb für mich sehr wichtig, da mit (automatischen) Tools und Scannern eigentlich nicht gefunden werden kann, da der Grund für die Lücke oft auch Fehler in der Business-Logik zurückzuführen sind (z.B. fehlende Prüfung ob die Daten zum eingeloggten Kunden gehören) und nicht „klassische“ Sicherheitslücken wir z.B. „SQL-Injection“ sind.

Die OWASP Top 10 sind natürlich keine vollständige Liste von relevanten Sicherheitslücken – da gibt es noch einige andere Typen von Lücken die man mit geeigneten Gegenmaßnahmen behandeln muss. Die Top 10 sind aber einerseits ein guter Startpunkt falls man neu ist in der Web-App-Security Materie und andererseits ein guter Anstoß um das bestehende Security-Model kritisch zu hinterfragen.

Die Content Security Policy ist ein Standard des W3C mit dessen Hilfe es möglich ist das Ausnutzen diverse Sicherheitslücken zu verhindern – insbesondere Cross-Site-Scripting (XSS).

Dabei handelt es sich um einen „passiven Schutz“, da der Client (Browser) das Ausnützen von vorhanden Sicherheitslücken verhindert. Eine nachhaltige Lösung ist es die Lücken im Source-Code zu beheben und ich rate dringend davon ab sich nur auf die CSP zu verlassen. Es ist aus meiner Sicht aber sinnvoll eine vernünftige CSP einzusetzen, da diese quasi als Fangnetzt dienen kann, wenn mal eine Sicherheitslücke rein rutscht oder man diese schlicht und einfach nicht beheben kann.

Wirklich vernünftig einsetzen kann man die CSP, aus meiner Sicht, erst mit der Version 3 (noch nicht von allen Browser unterstützt), da dort das „nonce-{random}“ und „strict-dynamic“ eingeführt wurden. Siehe Beitrag von Google und das „CSP policy example“. Sonst wird die List der Ausnahmen oft viel zu lange und unwartbar.

Continue reading “CSP – Content Security Policy”