Cross-Site Request Forgery – CSRF

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.

Was kann man als Entwickler dagegen tun?

Kritische Aktionen, wie Passwort oder Email-Adresse ändern, sollten immer mit der Abfrage des aktuellen Passwortes geschützt sein. Es ist dem Benutzer aber aus Usability Gründen nicht zuzumuten, dass bei jeder Anfrage an die Webseite das Passwort abgefragt wird, daher gibt es noch folgende effektive Abwehrmaßnahmen.

Man kann über den HTTP-Header verifizieren, dass der Request von der echten „Origin“ ist. Details dazu am besten auf der OWASP Seite entnehmen. Diese Maßnahme für sich alleine kann schon sehr effektiv sein. Ich empfehle aber auch noch folgendes zu implementieren.

Anti-CSRF Tokens sind ein nachhaltiger Schutz gegen die Attacke, da diese Tokens, nicht wie ein Cookie automatisch bei jeder Anfrage übertragen werden, sondern nur wenn der Benutzer im Browser ein Formular absendet oder auf eine Link klickt, wo diese als POST- oder GET-Parameter übertragen werden. Details dazu bitte auch der OWASP Seite entnehmen.

Links:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Aller Anfang ist leicht – OWASP

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.

OWASP TOP 10 – 2017

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.

DeepSec 2017 – Tag 2

Auch der 2. Tag der DeepSec 2017 war sehr abwechslungsreich und interessant – eine breite Palette an Themen wie Botnets, Probleme die es nach einem Blackout des Stromnetzwerkes geben wird bis hin zu unterschiedlichen Angriffszeniaren wurde abgedeckt.

Die Highlights aus meiner Sicht:

Wie leicht es ist Ransomware zu schreiben zu verbreiten zeigte Thomas Fischer eindrucksvoll. 

“How I rob banks” von Freakyclown. Video auf YouTube. 

Damit ist die DeepSec 2017 vorbei und ich freu mich jetzt schon auf die DeepSec 2018 🙂

DeepSec 2017 – Tag 1

“Science First” lautet das Motte der DeepSec 2017 und in der Key Note von Dr. Jessica Barker sogar “Social Science First”. Soll heißen, dass man bei Security nicht nur auf die Technologie schauen muss, sondern der Faktor Mensch wesentlich ist. Man soll positiv denken, Vorbild sein, offen für Neues und die Leute nicht einschüchtern mit Security Problemen, sondern Lösungen aufzeigen. 

Dass der Faktor Mensch wesentlich ist zeigte auch der Vortag von Vincent Haupert über das FinTech Startup N26. Er zeigt auf, dass nicht nur Usability wichtig sein sollte (bei Startups), sondern eben auch Security wesentlich ist. Für mich der beste Vortrag den ich heute gesehen habe. Hier mehr dazu.

“Insecurity in IT” von Tanya Janca schlägt auch in die selbe Kerbe. Es ist wichtig nicht mit dem Finger auf Programmierer, die Lücken eingebaut haben, zu zeigen, sondern diesen die Lösung zu zeigen und sie zu schulen. Dazu auch ihr OWASP Projekt DevSLop welches beim Lernen helfen soll.

Auch die anderen Vorträge waren großteils wirklich sehr gut. Bin gespannt auf Tag 2 …

PS: liebe Leute von der Organisation, das nächste Mal den Beamer vor Beginn der Key Note einstecken 😉

 

CSP – Content Security Policy

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”

DeepSec 2017

Die DeepSec 2017 steht vor der Tür. Die DeepSec ist für mich eine wirklich tolle Security Konferenz und noch dazu findet diese in Wien, in Österreich statt – quasi ein Heimspiel für mich.

Heuer findet die Konferenz von 14. bis 17. November statt und zwar wieder im Hotel „Imperial Riding School Vienna” (S-Bahn Station Rennweg).

Ich war im letzten Jahr das erste Mal dort und kann die Konferenz nur wärmstens empfehlen.

Der Inhalt ist nicht nur auf Web-Application-Security beschränkt, es geht allgemein um IT-Security – aber es schadet nicht auch ein wenig über den Tellerrand zu blicken. In den ersten zwei Tagen finden Trainings statt, die eigentliche Konferenz von Do. 16.11. bis Fr. 17.11.

Bis 13.11. läuft noch das „Last Minute Booking“, also rasch anmelden!

Mehr Infos gibt es auf der Homepage der DeepSec bzw. im Blog:
https://www.deepsec.net/
http://blog.deepsec.net/