Änderungen

Wechseln zu: Navigation, Suche

Cross-Site Scripting

2.037 Bytes hinzugefügt, 19:58, 21. Aug. 2017
keine Bearbeitungszusammenfassung
Über injizierten Code könnte der Benutzer auch auf eine manipulierte Webseite weitergeleitet werden, die von einem Hacker kontrolliert wird. Die manipulierte Seite sieht genauso aus wie die Original-Webseite. Erfolgt darüber ein Login des Benutzers, kann der Angreifer diese Daten sammeln und missbrauchen.
 
 
=== Angriffsarten ===
 
Es wird zwischen drei grundlegenden Arten von Cross-Site-Scripting-Angriffen unterschieden: Es gibt reflektierte, persistente und DOM-basierte Angriffe.
 
==== Reflektiert oder nicht-persistent ====
 
Das nicht-persistente (non-persistent) oder reflektierte (reflected) Cross-Site-Scripting ist eine Angriffsart, bei welcher die Benutzereingabe direkt vom Server wieder zurückgesendet wird. Wenn in der Eingabe Skriptcode enthalten, der vom Browser des Benutzers anschließend interpretiert wird, kann dort Schadcode ausgeführt werden.
 
Bei dieser Angriffsart nutzt der Angreifer die Tatsache aus, dass dynamisch generierte Webseiten ihre Inhalte oft über Parameter (also bestimmte Eingabewerte) in der URL (HTTP-GET-Methode) oder bei Formularen (HTTP-POST-Methode) anpassen. Diese Art wird als "Nicht-persistent" bezeichnet, weil der der Schadcode nur temporär bei der jeweiligen Generierung der Webseite eingeschleust, aber gespeichert wird. Ruft man die Seite ohne die manipulierte URL oder das manipulierte Formular auf (also ohne bestimmte Parameter bzw. Eingabewerte), ist der Schadcode nicht mehr enthalten.
 
==== Persistent oder beständig ====
 
Im Unterschied zum nicht-persistenten (non-persistent) oder reflektierten (reflected) Cross-Site-Scripting wird beim persistenten (persistent) oder beständigen (stored) Cross-Site-Scripting der Schadcode auf dem Webserver gespeichert, wodurch er bei jeder Anfrage ausgeliefert wird.
 
==== DOM-basiert oder lokal ====
 
Beim DOM-basierten (DOM Injection) oder lokalen (local) Cross-Site-Scripting ist die Webapplikation auf dem Server nicht beteiligt, wodurch auch statische HTML-Seiten mit integriertem JavaScript anfällig sind. Bei dieser Variante wird der Schadcode zur Ausführung direkt an ein clientseitiges Skript übergeben. Denkbar wäre ein JavaScript, welches einen URL-Argumentwert zur Ausgabe von Daten verwendet, ohne diesen '''ausreichend zu prüfen'''. Für einen solchen Angriff muss gezielt eine kompromittierten URL aufgerufen werden.
2.372
Bearbeitungen

Navigationsmenü