Cross-site scripting/de

Cross-Site Scripting, XSS oder arbitrary JavaScript injection ist eine Art von Computersicherheits Problemen, die typischerweise in Webseiten vorkommen, die es dem Angreifer ermöglichen Benutzerseitigen Programmcodein Webseiten einzufügen, die von anderen Benutzern besucht werden.

Beispiele
Beispiele für Cross-site scripting:


 * Der Angreifer bringt einen angemeldeten Benutzer dazu eine speziell präparierte URL zu besuchen, oder eine Webseite, die der Angreifer kontrolliert und den Benutzer zu der präparierten URL weiterleitet.
 * Die URL zeigt auf deine Webseite und enthält JavaScript in eine String. Die Webseite fügt dieses gefährliche JavaScript, wegen mangelnder Maskierung, in die Seite ein und führt es bei dem Benutzer aus.
 * Das JavaScript hat vollen Zugriff auf die Benutzer Cookies. Es kann die Webseite beliebig verändern und im Namen des Benutzers Formulare ausfüllen und absenden. Das Risiko ist besonders hoch, wenn die Zielperson ein Administrator ist.

"Sie auch: Exploit examples auf Wikipedia für mehr Beispiele."

Beispiel:

Der Angreifer sendet dem Opfer eine URL wie:

POST requests are also vulnerable, using offsite JavaScript.

Victims do not even have to directly visit the page to be affected. Malicious 3rd party websites can embed hidden iframes to crafted URLs to attack a user while visiting a website of theirs. As well they may be tricked into visiting a malicious or crafted URL using short URL services or disguising the URL as another.

Cross-site scripting verhindern
Um Cross-site scripting zu verhindern machen sie folgendes:


 * Überprüfe die Eingaben
 * Maskiere die Ausgaben

Du kannst die Überprüfung überspringen, aber du kannst NIEMALS die Maskierung auslassen. Maskiere alles.

It does not matter if the escaping is redundant with the validation, the performance cost is a small price to pay in exchange for a demonstrably secure web app. It does not matter if the input comes from a trusted source, escaping is necessary even then, because escaping gives you correctness as well as security.

Escape as close to the output as possible, so that the reviewer can easily verify that it was done. It helps you to verify your own code as well.

Output encoding (escaping) is context sensitive. So be aware of the intended output context and encode appropriately (e.g. HTML entity, URL, JavaScript, etc.)

The OWASP Abridged XSS Prevention Cheat Sheet is a useful and up to date quick reference guide for mitigating XSS issues.

All this is true of any text-based interchange format. We concentrate on HTML because web apps tend to generate a lot of it, and because the security issues are particularly severe. Every text format should have a well-studied escaping function.

Here are some convenience functions which do HTML escaping for your site.

MediaWiki escape output
MediaWiki also has some elegant building interfaces which implicitly escape your output. For SQL using the 'key' => 'value' syntax of conditions implicitly escapes values. And the Html:: and Xml:: interface methods escape attributes, and depending on the method used may escape a text value as well.

Externe Links

 * Escaping, w3.org. Very well written definition of escaping.