Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

2,558
views

Published on

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

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,558
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

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