Cross Site Request Forgery FAQ
In Anlehnung zu dem heute erschienenen CSRF FAQ auf CGISecurity.com möchte ich auch hier ein paar Takte zu diesem Begriff sagen, obgleich mein Weblog hier immer mehr zu einem Security Blog mutiert.
Nun die ersten Gedanken die man sich stellt, werden vermutlich sein, was CSRF ist und was damit angestellt werden kann. Der Begriff ähnelt ein Stück weit dem wohl bekannteren Cross Site Scripting (XSS), kann vergleichbar großen Schaden anrichten, baut jedoch auf anderen Prämissen auf. Während das primäre Ziel bei XSS Angriffen das ist, Schadcode in eine Website einzuschleusen, um ihn anschließend im Browser des Nutzers ausführen zu können (beispielsweise zum Diebstahl von Cookie Inhalten), werden bei CSRF die bereits vorhandenen (z.B. Session) Informationen dazu missbraucht, gezielte HTTP Requests an eine Website abzusetzen. Der Angreifer geht also davon aus, dass der Nutzer, der letzenendes unwissentlich den Request absetzt, authorisiert ist, eine bestimmte Aktion auf der anzugreifenden Website durchzuführen. Durch entsprechendes Social Engineering ist es mit CSRF genauso möglich, auf ein lokales Firmennetzwerk zuzugreifen.
Soviel zu dem Begriff. Wie ein solcher Angriff im Einzelnen durchgeführt wird, lässt sich leicht ergooglen bzw. im oben verlinkten FAQ nachzulesen. Wesentlich ist, wie man seine Applikationen davor schützen kann. Oft wird erwähnt, man solle POST statt GET verwenden, was jedoch kein effektiver Schutz ist, da es mit JavaScript ohne weiteres möglich ist, auch POST Requests abzusetzen. Von Schutz kann hier also keinesfalls gesprochen werden.
Ein weiteres Mittel zur Vorbeugung sind Session Tokens in Formularen, um sicher zu gehen, dass POST Daten auch wirklich aus den Formularen der eigenen Website stammen. Befindet sich allerdings eine durch XSS verwundbare Komponente auf der gleichen Seite wie das Formular, ist auch diese Schutzmaßnahme hinfällig, da es mittels XMLHttpRequest oder FlashRequest möglich ist, entsprechende Tokens aus den Formularen auszulesen (1). Selbiges gilt für Referrer Checks, Header können leicht manipuliert werden.
Wirklich effektiven Schutz hat man nur, wenn sichergestellt ist, dass Http Requests auch tatsächlich vom Nutzer abgesendet werden. Die einzige Möglichkeiten die ich sehe, um dies zu realisieren, sind zusätzliche Bestätigungen wie z.B. CAPTCHA's oder manuelle Passworteingabe, bei allen sicherheitsrelevanten Aktionen.
(1) Eine Methode dem entgegenzuwirken, hat Stefan Esser bereits vor einiger Zeit in seinem Blog beschrieben.
