Daniel Franke Tim Benedict Jagla Matthias Thimm Cross-Site-Scripting und Cross-Site-Request Schwachstellen in Web Applikationen Daniel Franke Tim Benedict Jagla Matthias Thimm
Cross-Site-Scripting
XSS Allgemein Cross Site Scripting Folge: Manipulation Zugang Einschleusen von Schadcode um Browserausgabe zu manipulieren Folge: Manipulation HTML-Formulare Cookies URL‘s Zugang Clientseitige Sprachen Z.B. JavaScript VBScript Flash
XSS (non-persistent/reflected)
XSS (non-persistent/reflected)
XSS (non-persistent/reflected)
XSS (non-persistent/reflected)
XSS (non-persistent/reflected) Gefahren CookieCatcher Link obfuscating „Nice to know“ Auch in <img> tag kann eine HTTP GET Request eingebettet werden
XSS (persistent/stored)
XSS (persistent/stored)
XSS (persistent/stored)
XSS (persistent/stored)
XSS (persistent/stored)
XSS (persistent/stored) MySpace Oktober 2005 „Samy Worm“ by Samy Kamkar OZ: “but most of all, Samy is my hero“ In 20 Stunden über eine Million “Infizierungen”
XSS (DOM-based)
XSS (DOM-based)
XSS (DOM-based) Twitter Anfang 2011 (function(g){ var a=location.href.split("#!")[1]; if(a){ g.location=g.HBR=a; } })(window); http://twitter.com/#!javascript:alert(document.domain);
Cross-Site Request-Forgery
CSRF Was ist CSRF? Unterschieben eines URL-Aufrufes Automatisches authentifizieren & ausführen
CSRF Vorgehen
CSRF Gefahr Jede Serverseitige Aktion ist anfällig Ja: JEDE !!! Bsp: http://www.example.com/Logout
CSRF Ursache Zustandslosigkeit Automatische Authentifikation (Cookies)
CSRF ING-Direct Sept. 2008 Google Mail 2007 U.a. Überweisungen möglich Automatische Authentifikation (Cookies) Google Mail 2007 Filteränderungen und Umleitungen möglich
CSRF Aspekte Authentizität Integrität (Verfügbarkeit) (Vertraulichkeit)
Schutzmaßnahmen
Allgemeine Schutzmaßnamen Clientseitig Session IDs Erweiterungen wie NoScript Cookies verbieten Serverseitig Tokens HTML Entities verwenden URL Encode verwenden
Exkurs: HTML Entities & URL Encode Beispiel Anfrage in Formularfeld: <script>alert('XSS')</script> Anfrage in HTML Entities: <script>alert('XSS')</script> Anfrage in URL Encode: %3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E JavaScript Interpreter: „?“
Üblicher Schutz vor CSRF Funktion Serverseitig werden HTTP Requests (bis auf POST) eingeschränkt Token werden verwendet Nachteile Server muss Token verwalten Token muss Formularfeld zugeordnet sein Abgelaufene Token müssen ungültig gemacht werden DoS [T1]
Schutz vor CSRF: Double-Submit Cookie [ZF08] Funktion Braucht keine serverseitigen Zustände mehr Zwei Tokens Einer im Cookie Einer im Request Vorteile „Same-Origin-Policy“ für Cookies Sind die Tokens identisch kommen Cookie und Request von derselben Ressource Nachteile Modifikationen im Applikation Code
Schutz vor CSRF: Double-Submit Cookie+ [LTJ12] Funktion Serverseitig Proxy („Gatekeeper“) validiert Token Whitelist für Einstiegspunkte in Applikation ohne Token (Bilder, JavaScript, CSS) „Gatekeeper“ fügt jedem ausgehenden HTML eine JavaScript Library hinzu HTTP Request Möglichkeiten Requests durch Interaktion mit DOM Implizite Requests durch HTML tags Requests von JavaScripts XMLHttpRequest Weiterleitungen seitens des Servers
Quellen [SJW07] [Kurtz10] [LTJ12] [ST12] [Klein05] [T1] A. Wiegenstein, Dr. M. Schuhmacher, X. Jia, F. Weidemann, „The Cross Site Scripting Threat“ [Kurtz10] A. Kurtz, „Bedrohung Cross-Site Request-Forgery – Grenzüberschreitung: Die „andere“ Schwachstelle in Web-Applikationen [LTJ12] S. Lekies, W. Tighzert, M. Johns, „Towards stateless, client-side driven Cross-Site Request Forgery protection für Web applications“ [ST12] L. K. Shar, H. B. K. Tan, „Defending against Cross-Site Scripting Attacks“ [Klein05] A. Klein, “DOM Based Cross Site Scripting or XSS of the Third Kind” [T1] http://wp.dynaperl.de/2008/11/29/tcp-syn-dos/
FRAGEN!?
Vielen Dank für die Aufmerksamkeit