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

Vortrag JUGM
Best Practice für Webapplikationen zur
Abwehr von Cross-Site Scripting
Johannes Kirchner
Consultant

OPITZ CONSULTING GmbH

München, 14.03.2011

JUGM – Best Practice für Webapplikationen zur Abwehr von Cross-Site Scripting © OPITZ CONSULTING GmbH 2011 Seite 1

Agenda
1. Einführung

2. Grundlegende Angriffsarten

3. Vorstellung: Ausgewähltes Werkzeug zur automatisierten
Identifizierung von Cross-Site Scripting Sicherheitslücken

4. Allgemeine und spezielle Abwehrmechanismen der
Browser

5. Allgemeine Abwehrmaßnahmen gegen Cross-Site
Scripting


Agenda
6. Ausgewählte spezielle Maßnahmen gegen Cross-Site
Scripting

7. Darstellung spezieller Maßnahme gegen Cross-Site
Scripting in Apache MyFaces Tomahawk

8. Darstellung Cross-Site Scripting in Apache Struts

9. Referenzen und Links


1 Einführung


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.


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


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


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 )


 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>


 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


Vorstellung:
Ausgewähltes Werkzeug zur
automatisierten Identifizierung von
3 Cross-Site Scripting Sicherheitslücken


Allgemeine und spezielle
4 Abwehrmechanismen der Browser


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)


 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


 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


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)


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/


Allgemeine Abwehrmaßnahmen
5 gegen Cross-Site Scripting


5. Allgemeine Abwehrmaßnahmen gegen
Cross-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


 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...)


 Suche innerhalb von Zeichenketten und spezifisches Löschen gefährlicher Inhalte

Vorteile Nachteile
 einfach zu implementieren  Liste gefährlicher Inhalte muss ggf.
angepasst werden
 Gefahr von Nichtbeachtung von Groß-/
Kleinschreibung


 Suche innerhalb von Zeichenketten und spezifisches Ersetzen gefährlicher Inhalte

Vorteile 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


 Verwendung von regulären Ausdrücken

Vorteile Nachteile
 Benutzerfreundlicher Workflow  Evtl. Verfälschung von Logik der Eingabe
 Gefahr von Verwendung unzureichender
regulärer Ausdrücke


 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


 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


Ausgewählte spezielle Maßnahmen
6 gegen Cross-Site Scripting


6. Ausgewählte spezielle Maßnahmen gegen
 Java Servlet – Verwendung von regulären Ausdrücken bei
der Filterung von Eingabeparametern
// replace tag brackets
parameterValue = parameterValue.replaceAll("<", "<")
.replaceAll(">", ">");

// 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/


6. Ausgewählte spezielle Maßnahmen gegen
 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();
}


Darstellung spezieller Maßnahmen
gegen Cross-Site Scripting in
7 Apache MyFaces Tomahawk


7. Darstellung spezieller Maßnahmen gegen
Cross-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>


 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 let's 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);


 Stelle in Version 1.1.6

if (oldViewId != null && oldViewId.equals(facesContext.getViewRoot().getViewId()))
{
//ok, we stayed on the same page, so let's 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


 Stelle in Version 1.1.6
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);


Darstellung Cross-Site Scripting
8 in Apache Struts


8. Darstellung Cross-Site Scripting in Apache
Struts
 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


8. Darstellung Cross-Site Scripting in Apache
Struts
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>


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
 C't 26/2006, S. 234
 iX Februar 2010, S. 48


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


Fragen und Antworten


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

Recommandé

Recommandé

Contenu connexe

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

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

Plus de OPITZ CONSULTING Deutschland

Plus de OPITZ CONSULTING Deutschland (20)

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