SQL Injection

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”

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. Continue reading “Cross-Site Request Forgery – CSRF”

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/