Vortrag JUGMBest Practice für Webapplikationen zurAbwehr von Cross-Site ScriptingJohannes KirchnerConsultantOPITZ CONSULTI...
Agenda1.   Einführung2.   Grundlegende Angriffsarten3.   Vorstellung: Ausgewähltes Werkzeug zur automatisierten     Identi...
Agenda6.   Ausgewählte spezielle Maßnahmen gegen Cross-Site     Scripting7.   Darstellung spezieller Maßnahme gegen Cross-...
1   Einführung     JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting   © OPITZ CONSULTING GmbH...
1. Einführung Definition Cross-Site Scripting (XSS)   Angriffstechnik, die kompromittierte Webseite zwingt, (schadbringe...
1. Einführung XSS Angreifer hat Zugriff auf folgende Informationen     Betriebssystemversion     Zwischenablage von Sys...
1. Einführung Folgende erweiterte Angriffen sind mit Hilfe von XSS  denkbar   Session Hijacking über Diebstahl von Cooki...
2   Grundlegende Angriffsarten     JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting   © OPITZ...
2. Grundlegende Angriffsarten Reflektives bzw. nicht persistentes Cross-Site Scripting   Cross-Site Scripting findet unt...
2. Grundlegende Angriffsarten Lokales bzw. DOM basiertes Cross-Site Scripting   Nicht auf die Mitwirkung eines Webserver...
2. Grundlegende Angriffsarten Persistentes Cross-Site Scripting bzw. HTML Injection   Tritt in öffentlichen Webbereichen...
Vorstellung:    Ausgewähltes Werkzeug zur    automatisierten Identifizierung von3   Cross-Site Scripting Sicherheitslücken...
Allgemeine und spezielle4   Abwehrmechanismen der Browser     JUGM – Best Practice für Webapplikationen zur Abwehr von Cro...
4. Allgemeine Abwehrmechanismen der Browser Sandbox Prinzip   Einschränkung der Rechte und Möglichkeiten von Skript Code...
4. Allgemeine Abwehrmechanismen der Browser Same Origin Prinzip   Skript darf nur auf Browser-Dokumente zugreifen, die d...
4. Allgemeine Abwehrmechanismen der Browser Zonenmodell und individuell anpassbare  Sicherheitseinstellungen   Sicherhei...
4. Spezielle Abwehrmechanismen der Browser Microsoft Internet Explorer   Ab Version 8 XSS-Filter integriert   Schutz be...
4. Spezielle Abwehrmechanismen der Browser Mozilla Firefox   NoScript Erweiterung (umfangreiche XSS Abwehrmechanismen, W...
Allgemeine Abwehrmaßnahmen5   gegen Cross-Site Scripting     JUGM – Best Practice für Webapplikationen zur Abwehr von Cros...
5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Gründliche Validierung von eingehenden Daten auf Typ,  Länge, Syn...
5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Filterung von Inhalten   2 grundlegende Filter Konzepte: die Fil...
5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Filterung von Inhalten     Suche innerhalb von Zeichenketten und...
5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Filterung von Inhalten     Suche innerhalb von Zeichenketten und...
5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Filterung von Inhalten     Verwendung von regulären AusdrückenVo...
5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Kodierung von Inhalten   Teilweise erforderlich, dass Skript Cod...
5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Erhöhung der Sicherheit bei Verwendung von Cookies   Großer Teil...
Ausgewählte spezielle Maßnahmen6   gegen Cross-Site Scripting     JUGM – Best Practice für Webapplikationen zur Abwehr von...
6. Ausgewählte spezielle Maßnahmen gegenCross-Site Scripting Java Servlet – Verwendung von regulären Ausdrücken bei  der ...
6. Ausgewählte spezielle Maßnahmen gegenCross-Site Scripting Java Servlet – Verwendung Kodierung von HTML-Inhalten  zur D...
Darstellung spezieller Maßnahmen    gegen Cross-Site Scripting in7   Apache MyFaces Tomahawk     JUGM – Best Practice für ...
7. Darstellung spezieller Maßnahmen gegenCross-Site Scripting in Apache MyFaces Tomahawk Apache MyFaces Tomahawk JSF Fram...
7. Darstellung spezieller Maßnahmen gegenCross-Site Scripting in Apache MyFaces Tomahawk Sicherheitskritische Stelle in V...
7. Darstellung spezieller Maßnahmen gegenCross-Site Scripting in Apache MyFaces Tomahawk Stelle in Version 1.1.6  org.apa...
7. Darstellung spezieller Maßnahmen gegenCross-Site Scripting in Apache MyFaces Tomahawk Stelle in Version 1.1.6  org.apa...
Darstellung Cross-Site Scripting8   in Apache Struts     JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Si...
8. Darstellung Cross-Site Scripting in ApacheStruts Apache Struts Framework Cross-Site Scripting  Sicherheitslücke   ver...
8. Darstellung Cross-Site Scripting in ApacheStruts WebContentexercisebean-parameter.jsp <%@ taglib uri="/tags/struts-bean...
9. Referenzen und Links   http://projects.webappsec.org/Cross-Site-Scripting   http://www.owasp.org/index.php/XSS_(Cross...
Was sollte man mitnehmen Allgemeines Bewusstsein der Gefahren der ungeprüften  Ein- und Ausgaben im Umfeld von Webanwendu...
Fragen und Antworten      JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting   © OPITZ CONSULTI...
Nächste SlideShare
Wird geladen in …5
×

Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting (JUGM) - OPITZ CONSULTING - Johannes Kirchner

3.082 Aufrufe

Veröffentlicht am

Vortrag "Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting (JUGM)" von Johannes Kirchner, OPITZ CONSULTING

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
3.082
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting (JUGM) - OPITZ CONSULTING - Johannes Kirchner

  1. 1. Vortrag JUGMBest Practice für Webapplikationen zurAbwehr von Cross-Site ScriptingJohannes KirchnerConsultantOPITZ CONSULTING GmbHMünchen, 14.03.2011 JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 1
  2. 2. Agenda1. Einführung2. Grundlegende Angriffsarten3. Vorstellung: Ausgewähltes Werkzeug zur automatisierten Identifizierung von Cross-Site Scripting Sicherheitslücken4. Allgemeine und spezielle Abwehrmechanismen der Browser5. Allgemeine Abwehrmaßnahmen gegen Cross-Site Scripting JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 2
  3. 3. Agenda6. Ausgewählte spezielle Maßnahmen gegen Cross-Site Scripting7. Darstellung spezieller Maßnahme gegen Cross-Site Scripting in Apache MyFaces Tomahawk8. Darstellung Cross-Site Scripting in Apache Struts9. Referenzen und Links JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 3
  4. 4. 1 Einführung JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 4
  5. 5. 1. Einführung Definition Cross-Site Scripting (XSS)  Angriffstechnik, die kompromittierte Webseite zwingt, (schadbringenden) Skript Code im Browserkontext des Besuchers einer Webseite auszuführen  Beteiligte Webserver und darauf laufende kompromittierte Webseite bleiben weitestgehend unangetastet  Ziel von XSS Angriff ist die Erlangung der vollen Kontrolle des Browsers eines Webseiten-Besuchers  Voraussetzung ist die Aktivierung der Optionen zur Ausführung von Skripten in Browsereinstellungen des XSS Opfers Ursprünge von XSS Angriffen  Der Webseiten-Betreiber hat selbst den schadbringenden Code auf den Server gelegt  Der Webserver wurde kompromittiert(Defacement)  Der Angreifer hat den schadbringenden Skript Code innerhalb eines öffentlichen Bereichs (z. B. Gästebuch) der Seite platziert.  Der Angreifer hat einen Link verbreitet, welcher eine nicht-persistente Attacke durchführt. JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 5
  6. 6. 1. Einführung XSS Angreifer hat Zugriff auf folgende Informationen  Betriebssystemversion  Zwischenablage von System (Internet Explorer)  Browsertyp und -version  Cookie Informationen  Evtl. vom Browser gespeicherte Daten in Formularen  Evtl. vom Browser gespeicherte Passwörter  Installierte Browser Erweiterungen (z. B. Flash, .NET)  Client IP und Hostname  Evtl. Router IP JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 6
  7. 7. 1. Einführung Folgende erweiterte Angriffen sind mit Hilfe von XSS denkbar  Session Hijacking über Diebstahl von Cookie Informationen  Mitschneiden von Tastatureingaben  Intranet Angriffe  Manipulation von Browser Historie  Direkte Ausführung von Binärcode über Browser-Sicherheitslücken (z. B. Buffer Overflow)  ... Folgende Angriffen sind mit Hilfe von XSS nicht "direkt" durchführbar  Manipulation von Darstellungsinformationen direkt auf Webserver  Gezielter Zugriff bzw. Manipulation der Programm Informationen von Anwendungsserver hinter Webserver  Gezielter Zugriff bzw. Manipulation der Datenbank Informationen von Datenbank Server hinter Webserver JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 7
  8. 8. 2 Grundlegende Angriffsarten JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 8
  9. 9. 2. Grundlegende Angriffsarten Reflektives bzw. nicht persistentes Cross-Site Scripting  Cross-Site Scripting findet unter Mithilfe eines vermeintlich "vertrauenswürdigen" Webservers statt, welcher unter Manipulation von URL-Eingabeparametern schadhaften Skript Code wiedergibt  Angriff eignet sich besonders gut bei HTML Texteingabeelementen (z. B. ein Sucheingabefeld), welche Inhalte in Folgeverarbeitung wiedergeben (Reflektion)  Verbreitung von präparierten Link über E-Mail (z. B. Spam) in Webforen oder mit Hilfe von Instant Messaging Diensten – in der Hoffnung, möglichst viele Anwender referenzieren auf Link  Besonders gefährlich, da es sich um eine echte "vertrauenswürdige" Domainadresse handelt, von der vordergründig keine Gefahr auszugehen scheint  Proof of Concept: http://www.xssed.com/pagerank http://controlshift.aol.com/search/?q=%27%22%3E%3C%2Ftitle%3E%3Cscript%3Eal ert(1337)%3C%2Fscript%3E% 3E%3Cmarquee%3E%3Ch1%3EXSS+by+Xylitol%3C%2Fh1%3E%3C%2Fmarquee% 3E ) JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 9
  10. 10. 2. Grundlegende Angriffsarten Lokales bzw. DOM basiertes Cross-Site Scripting  Nicht auf die Mitwirkung eines Webservers bei der Wiedergabe von schadhaftem Skript Code angewiesen  Schadcode wird direkt beim Aufruf der URL ausgeführt  Manipulierter Aufruf wird nicht an vom Benutzer aufgerufenen Webserver gesendet, sondern nur lokal auf Client ausgeführt  Beispiel: http://www.xss- vermittler.de//angebot?produkt_id=100&ueberschrift=Foo#<SCRIPT>alert(teste%20a uf%20XSS)</SCRIPT> JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 10
  11. 11. 2. Grundlegende Angriffsarten Persistentes Cross-Site Scripting bzw. HTML Injection  Tritt in öffentlichen Webbereichen wie z. B. Web Foren oder Web E-Mail auf  Angriff benötigt keine speziell zusammengesetzten Links  Angreifer platziert schadhaften Code direkt in öffentlich zugänglichen Bereich auf Webseite  Angriff ist gefährlicher als nicht persistentes Cross-Site Scripting, da Browser eines potentiellen Opfers automatisch und in der Regel ohne Vorwarnung schadbringenden Code ausführt JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 11
  12. 12. Vorstellung: Ausgewähltes Werkzeug zur automatisierten Identifizierung von3 Cross-Site Scripting Sicherheitslücken JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 12
  13. 13. Allgemeine und spezielle4 Abwehrmechanismen der Browser JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 13
  14. 14. 4. Allgemeine Abwehrmechanismen der Browser Sandbox Prinzip  Einschränkung der Rechte und Möglichkeiten von Skript Code, auf das System des Nutzers zuzugreifen  Code darf nur innerhalb eines Browser-Fensters operieren  Zugriff auf Dateien, Betriebssystem- oder Browsereinstellungen werden unterbunden  Skript Code darf keine Programme auf dem Rechner vom Anwender installieren bzw. vorhandene Programme aufrufen  Möglichkeiten des Sandbox Prinzips werden nicht voll ausgeschöpft (z. B. Öffnen von Browser-Fenster) JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 14
  15. 15. 4. Allgemeine Abwehrmechanismen der Browser Same Origin Prinzip  Skript darf nur auf Browser-Dokumente zugreifen, die die selbe Herkunft(URI) haben  Es besteht die Möglichkeit, auf externe Elemente wie Popup-Fenster, Frames, Inner Frames und Cookies zu zugreifen, welche vom gleichen Ursprung sind  Auch bei dieser Richtlinie existieren Ausnahmen, um Einsatzmöglichkeiten von Skripten zu erhöhen z. B. mit Hilfe des SCRIPT Tag oder IMG Tag  Obwohl Skript nicht auf Daten einer Grafik zugreifen kann, ist zum Versenden von Informationen über Servergrenzen hinaus diese Verfahrensweise äußerst etabliert  Manipuliert Skriptzuordnung von Domainname zur Server IP Adresse, können weitere nicht autorisierte Webinhalte nachgeladen werden und Same Origin Prinzip verletzt werden  Bei Webseiten, die über HTTPS übermittelt werden, wäre diese Art der Manipulation evtl. durch fehlerhaft gemeldete Zertifikate (fehlerhafter Fingerprint) im Browser sichtbar JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 15
  16. 16. 4. Allgemeine Abwehrmechanismen der Browser Zonenmodell und individuell anpassbare Sicherheitseinstellungen  Sicherheitskonzept, welches bezogen auf die Herkunft des Skript Codes unterschiedliche Sicherheitseinstellungen anwendet  Restriktivere Einstellung für Webseiten, welche aus dem Internet stammen, als für Webseiten, welche aus lokalem Intranet aufgerufen wurden  Bei einigen Browsern möglich, für jede Webseite ganz individuelle skript-spezifische Einstellungen vorzunehmen  Leider gibt es jedoch immer wieder Sicherheitslücken, welche Zonenmodell von Browser unterlaufen JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 16
  17. 17. 4. Spezielle Abwehrmechanismen der Browser Microsoft Internet Explorer  Ab Version 8 XSS-Filter integriert  Schutz beschränkt sich auf Abwehr von reflektivem bzw. nicht persistentem Cross-Site Scripting  Bei möglichen Angriff weist Meldung im Informationsbalken des Browsers den Benutzer auf XSS-Attacken hin  Schadbringender Code wurde zuvor vom Browser gefiltert  Filter scheint nicht Schutz gegenüber jeglichen bekannten XSS Attacken zu gewährleisten. (http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-iv-the- xss-filter.aspx) JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 17
  18. 18. 4. Spezielle Abwehrmechanismen der Browser Mozilla Firefox  NoScript Erweiterung (umfangreiche XSS Abwehrmechanismen, White List, Anzeige von Meldungen, Regeln auf Basis von Regulären Ausdrücken) http://noscript.net/faq#xss  noXSS (Ziel ist es, umfangreichen Schutz gegenüber XSS Angriffen zu gewährleisten) http://www.noxss.org/ JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 18
  19. 19. Allgemeine Abwehrmaßnahmen5 gegen Cross-Site Scripting JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 19
  20. 20. 5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Gründliche Validierung von eingehenden Daten auf Typ, Länge, Syntaktik und fachliche Semantik Nutzung von Kanonischen Formaten Sichere Kodierung von ausgehenden Daten Festlegung der Kodierung der Webinhalte z. B. ISO 8859-1 oder UTF 8 Vermeidung von Schwarzen Listen, welche nur einzelne kritische Zeichen z. B. "<"enthalten Vermeidung von zu detaillierten Fehlermeldungen, welche eingegebene Daten reflektieren JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 20
  21. 21. 5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Filterung von Inhalten  2 grundlegende Filter Konzepte: die Filterung der Eingabe und der Ausgabe  Am meisten benutzte Filterung ist die Eingabe-Filterung, da effektiver (bestimmte Inhalte meist nur an einer Stelle eingegeben aber an mehreren Stellen wieder ausgegeben)  Säuberung von Eingabeinhalten gleicht für Angreifer oft Säuberung von Ausgabeinhalten, speziell bei reflektivem Cross-Site Scripting  Im Gegensatz zur Ausgabe werden Inhalte der Eingabe meist nach ihrer Filterung analysiert und verarbeitet, während Ausgabeinhalte an Client für Darstellung der Webinhalte gesendet werden  Bei zu strengen Säuberung von Eingabeinhalten kann Bedeutung von Inhalten verloren gehen oder Bedeutung von Inhalten wird verändert  Skript Code kann in verschiedenen Formaten eingegeben werden (http://www.xss- vermittler.de/index.php?sessionid=32425255&username=%3C%73%63%7...) JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 21
  22. 22. 5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Filterung von Inhalten  Suche innerhalb von Zeichenketten und spezifisches Löschen gefährlicher InhalteVorteile Nachteile einfach zu implementieren  Liste gefährlicher Inhalte muss ggf. angepasst werden  Gefahr von Nichtbeachtung von Groß-/ Kleinschreibung JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 22
  23. 23. 5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Filterung von Inhalten  Suche innerhalb von Zeichenketten und spezifisches Ersetzen gefährlicher InhalteVorteile Nachteile benutzerfreundlicher Workflow  Liste gefährlicher Inhalte muss ggf. angepasst werden  Ersetzung könnte harmlose Inhalte betreffen  Ersetzen gefährlicher Inhalte erhöht Anfälligkeit gegenüber weiteren Sicherheitslücken  Evtl. Verfälschung von Logik der Eingabe JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 23
  24. 24. 5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Filterung von Inhalten  Verwendung von regulären AusdrückenVorteile Nachteile Benutzerfreundlicher Workflow  Evtl. Verfälschung von Logik der Eingabe  Gefahr von Verwendung unzureichender regulärer Ausdrücke JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 24
  25. 25. 5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Kodierung von Inhalten  Teilweise erforderlich, dass Skript Code eingegeben werden kann, der später gefahrlos dargestellt werden soll (z. B. Forum für Webdesigner)  Kodierung wandelt schadhafte Zeichenketteneinheiten, die ausgeführt werden könnten, in Zeichenketteneinheiten, die lediglich dargestellt werden  Nachteil, dass Performanz von Anwendung leidet  Potentieller Angreifer kann unterschiedliche Darstellungen für ein und das selbe sicherheitskritische Zeichen verwenden JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 25
  26. 26. 5. Allgemeine Abwehrmaßnahmen gegenCross-Site Scripting Erhöhung der Sicherheit bei Verwendung von Cookies  Großer Teil von XSS Angriffen versucht, Cookie-Informationen des Opfers auszuspähen  Neben Authentifizierungsinformationen ebenfalls Speicherung der originären, öffentliche Quell IP Adresse des Webseitenbesuchers  Zugriff soll nur in Kombination von Cookie Inhalt und korrekter IP Adresse möglich sein  Verliert Wirkung, sobald Opfer und Angreifer über NAT oder einem Web Proxy dieselbe öffentliche Quell IP Adresse verwenden  Weitere Maßnahme zum Schutz besteht in Nutzung von "HttpOnly" Flag  Flag verhindert Zugriff von client-basiert Skripten auf Cookie Informationen  Flag kann nicht zuverlässig Diebstahl von Informationen lokal gespeicherter Cookies vermeiden JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 26
  27. 27. Ausgewählte spezielle Maßnahmen6 gegen Cross-Site Scripting JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 27
  28. 28. 6. Ausgewählte spezielle Maßnahmen gegenCross-Site Scripting Java Servlet – Verwendung von regulären Ausdrücken bei der Filterung von Eingabeparametern // replace tag brackets parameterValue = parameterValue.replaceAll("<", "&lt;") .replaceAll(">", "&gt;"); // remove <javascript> tag parameterValue = parameterValue.replaceAll( "["][s]*((?i)javascript):(.*)["]", """"); // remove <script> tag parameterValue = parameterValue.replaceAll("((?i)script)", ""); // remove eval() script command parameterValue = parameterValue.replaceAll("eval((.*))", ""); // remove remove on* attributes like onLoad or onClick parameterValue.replaceAll("(?i)<.*?s+on.*?>.*?</.*?>", "");  Zur besseren Unterstützung zur Vermeidung von XSS Angriffen in Java Servlets, empfiehlt sich der Einsatz von freien XSS Filter Bibliotheken z. B. https://xssfilter.dev.java.net/ JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 28
  29. 29. 6. Ausgewählte spezielle Maßnahmen gegenCross-Site Scripting Java Servlet – Verwendung Kodierung von HTML-Inhalten zur Darstellung im Browser /** Encode HTML content for display in web browser into its * equivalent form, using decimal character references * * @param decodedData decoded HTML data * @return encoded HTML data */ public static String encode(String decodedData) { final StringBuffer encodedStringBuffer = new StringBuffer(); final char[] decodedDataChars = decodedData.toCharArray(); for (int i = 0; i < decodedDataChars.length; i++) { encodedStringBuffer.append("&#" + (int) decodedDataChars [i]); } return encodedStringBuffer.toString(); } JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 29
  30. 30. Darstellung spezieller Maßnahmen gegen Cross-Site Scripting in7 Apache MyFaces Tomahawk JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 30
  31. 31. 7. Darstellung spezieller Maßnahmen gegenCross-Site Scripting in Apache MyFaces Tomahawk Apache MyFaces Tomahawk JSF Framework Cross-Site Scripting Sicherheitslücke  Verwundbare Version: 1.1.5  Cross-Site Scripting Sicherheitslücke in “autoscroll” Parameter  http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=544  Proof of Concept 1: http://<server adresse:server port>/xss_security_jsf/home.jsf?autoScroll=0%2C275);//- -></script><IMG%20src="bla"%20onerror="alert(document.cookie)"><script>(  Proof of Concept 2: http://< server adresse:server port>/xss_security_jsf/home.jsf?autoScroll=111-222- 1933email@address.tst&javax%2Efaces%2EViewState=<script>alert(document.cooki e)</script> JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 31
  32. 32. 7. Darstellung spezieller Maßnahmen gegenCross-Site Scripting in Apache MyFaces Tomahawk Sicherheitskritische Stelle in Version 1.1.5 org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils if (oldViewId != null && oldViewId.equals(facesContext.getViewRoot().getViewId())) { //ok, we stayed on the same page, so lets scroll it to the former place String scrolling = (String)externalContext.getRequestParameterMap().get(AUTO_SCROLL_PARAM); if (scrolling != null && scrolling.length() > 0) { String x = "0"; String y = "0"; int comma = scrolling.indexOf(,); if (comma == -1) { log.warn("Illegal autoscroll request parameter: " + scrolling); } else { x = scrolling.substring(0, comma); if (x.equals("undefined")) x = "0"; y = scrolling.substring(comma + 1); if (y.equals("undefined")) y = "0"; } script.append("window.scrollTo(").append(x).append(",").append(y).append(");n"); } } writer.writeText(script.toString(),null); JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 32
  33. 33. 7. Darstellung spezieller Maßnahmen gegenCross-Site Scripting in Apache MyFaces Tomahawk Stelle in Version 1.1.6 org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils if (oldViewId != null && oldViewId.equals(facesContext.getViewRoot().getViewId())) { //ok, we stayed on the same page, so lets scroll it to the former place String scrolling = (String)externalContext.getRequestParameterMap().get(AUTO_SCROLL_PARAM); if (scrolling != null && scrolling.length() > 0) { int x = 0; int y = 0; int comma = scrolling.indexOf(,); if (comma == -1) { log.warn("Illegal autoscroll request parameter: " + scrolling); } else JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 33
  34. 34. 7. Darstellung spezieller Maßnahmen gegenCross-Site Scripting in Apache MyFaces Tomahawk Stelle in Version 1.1.6 org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils else { try { //we convert to int against XSS vulnerability x = Integer.parseInt(scrolling.substring(0, comma)); } catch (NumberFormatException e) { log.warn("Error getting x offset for autoscroll feature. Bad param value: " + scrolling); x = 0; //ignore false numbers } try { //we convert to int against XSS vulnerability y = Integer.parseInt(scrolling.substring(comma + 1)); } catch (NumberFormatException e) { log.warn("Error getting y offset for autoscroll feature. Bad param value: " + scrolling); y = 0; //ignore false numbers } } script.append("window.scrollTo(").append(x).append(",").append(y).append(");n"); } } writer.writeText(script.toString(),null); JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 34
  35. 35. Darstellung Cross-Site Scripting8 in Apache Struts JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 35
  36. 36. 8. Darstellung Cross-Site Scripting in ApacheStruts Apache Struts Framework Cross-Site Scripting Sicherheitslücke  verwundbare Version: 1.2.7  Cross-Site Scripting Sicherheitslücke in “bean” Parameter  Proof of Concept: http://<server adresse:server port>/xss_security_struts/exercise/bean- parameter.jsp?param1=<script>alert(406101462670)</script>&param2=value2 JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 36
  37. 37. 8. Darstellung Cross-Site Scripting in ApacheStruts WebContentexercisebean-parameter.jsp <%@ taglib uri="/tags/struts-bean" prefix="bean" %> <html> <head> <title>Test struts-bean:parameter Tag</title> </head> <body> <div align="center"> <h1>Test struts-bean:parameter Tag</h1> </div> <p>If called from the <code>index.html</code>page, two request parameters will be included and their values displayed below. If you call this page without including the appropriate request parameters, you will receive a JSP runtime error instead.</p> <bean:parameter id="param1" name="param1" /> <bean:parameter id="param2" name="param2" /> <bean:parameter id="param3" name="param3" value="UNKNOWN VALUE" /> <table border="1"> <tr> <th>Parameter Name</th> <th>Correct Value</th> <th>Test Result</th> </tr> <tr> <td>param1</td> <td>value1</td> <td> <%= param1 %> </td> </tr> JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 37
  38. 38. 9. Referenzen und Links http://projects.webappsec.org/Cross-Site-Scripting http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_S heet http://ha.ckers.org/xss.html http://httpd.apache.org/info/css-security/ http://www.cgisecurity.com/xss-faq.html http://recon.cx/2008/a/alexander_sotirov/recon-08-sotirov.pdf Ct 26/2006, S. 234 iX Februar 2010, S. 48 JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 38
  39. 39. Was sollte man mitnehmen Allgemeines Bewusstsein der Gefahren der ungeprüften Ein- und Ausgaben im Umfeld von Webanwendungen Spezielles Bewusstsein über Wirkungsweise und Gefahren von XSS Wissen über grundlegende XSS Angriffsarten Referenz auf Abwehrmechanismen und Maßnahmen gegen XSS JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 39
  40. 40. Fragen und Antworten JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 40

×