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

Like this? Share it with your network

Share

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

on

  • 2,511 views

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

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

Statistics

Views

Total Views
2,511
Views on SlideShare
2,511
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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. 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. 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. 1 Einführung JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 4
  • 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. 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. 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. 2 Grundlegende Angriffsarten JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 8
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Fragen und Antworten JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 40