Cross site scripting

from Wikipedia, the free encyclopedia

Cross-Site-Scripting ( XSS ; German  cross- website scripting ) describes the exploitation of a computer security hole in web applications by inserting information from one context in which it is not trustworthy into another context in which it is classified as trustworthy. An attack can then be launched from this trustworthy context.

The goal is usually to get to sensitive data of the user, for example to take over his user accounts ( identity theft ).

A special application of the XSS is cross-site tracing .

terminology

The term “cross-site” refers to the fact that the attack takes place between different visits to the same page, but usually not that different websites are involved. Mostly script languages ​​- especially JavaScript  - are used for this type of attack due to their widespread use : hence “scripting”.

The X is understood in English as an abbreviation for cross (= "Kreuz").

Despite the similarity of names, cross-site cooking and cross-site request forgery and their applications, such as cross-site authentication attacks, are not forms of cross-site scripting.

functionality

Cross-site scripting is a type of HTML injection. Cross-site scripting occurs when a web application accepts data from a user and then sends that data to a browser without checking the content. This enables an attacker to also send scripts indirectly to the victim's browser and thus execute malicious code on the client's side.

A classic example of cross-site scripting is the transfer of parameters to a server-side script that creates a dynamic website. This can be the input form of a website, as is common in web shops, forums, blogs and wikis. The data entered is output as page content on the website again when the page is accessed by users. This makes it possible to send manipulated data to all users, provided the server script does not prevent this. This data is often code of a client-side scripting language (mostly JavaScript ).

Common types of attack are the hijacking of user sessions , website defacements , posting negative content, phishing attacks and taking control of the user browser.

This becomes particularly dangerous if the website on which the malicious code was placed has special security rights (privileges) in the local browser. Depending on the power of the scripting language, the malicious code can then do various things that are possible with the rights of the local user. As the local user is often given administrator rights on Microsoft Windows systems (before Windows Vista) for convenience , this is already a very dangerous constellation. But even without administrator rights, the attacker can try to gain these rights by exploiting security gaps when executing the relevant scripting language.

As a rule, XSS is widely distributed in forums, for example, and is not targeted specifically at selected people. However, this is also possible. In addition to the classic XSS in the web browser , e-mail programs often interpret script code, which enables an attack via e-mail. To do this, the attacker slips the victim an HTML document that he has prepared and that is then sent by email. Or the attacker sends the victim a hyperlink that points to a website prepared by the attacker or that contains the malicious code itself. Short URLs , URL spoofing techniques and other coding methods are often used to disguise the link or make it appear trustworthy.

Recently, web spiders have also been misused to carry out XSS and SQL injection attacks. For this purpose, a prepared link is published on a website. As soon as a web spider follows this link, it triggers the attack. As a result, the IP address of the spider and not that of the actual attacker appears in the logs of the attacked system. The attacker can thus act anonymously. In serious cases it would still be possible to find out the IP address of the computer that published the manipulated link.

Types of attack

There are three basic types of cross-site scripting attacks: reflected, persistent, and DOM-based. These are explained below.

The examples use simple JavaScript code to illustrate alert("XSS");this, which is incorporated into an HTML document using the script element: 

<script type="text/javascript">alert("XSS");</script>

This JavaScript code only describes a harmless warning dialog with the text "XSS". But any other JavaScript code can be injected in the same way.

Reflected or non-persistent

The non-persistent (non-persistent) or reflected (reflected) cross-site scripting is an attack in which a user input is sent back from the server. If this input contains script code that is then interpreted by the user's browser, malicious code can be executed there.

This makes use of the fact that dynamically generated websites often adapt their content to input values transferred via URL ( HTTP-GET method) or forms ( HTTP-POST method). This type is called non-persistent , as the malicious code is only introduced temporarily when the website is generated, but not saved. If you then call up the page without the manipulated URL or the manipulated form, the malicious code is no longer contained.

Example:

A search function should enable all documents on a website to be searched. The search term is displayed again separately on the results page ("reflected"). The search term can be transferred to the function either via a URL argument or via a form. Such a request looks something like this:http://example.com/?suche=Suchbegriff

The transferred search terms are now returned to the results page without being checked by a server-side web application: 

<p>Sie suchten nach: Suchbegriff</p>

If the following search term were used here: the <script type="text/javascript">alert("XSS")</script>following HTML code would then be generated: 

<p>Sie suchten nach: <script type="text/javascript">alert("XSS")</script></p>

Using the same principle, malicious code can also be smuggled in via manipulated forms or form entries. Here, the victim has to be lured to a website with a manipulated form. The form can be invisibly loaded in the background in an iframe and automatically sent via JavaScript so that user interaction is not required.

Persistent or constant

Persistent (persistent) or permanent (stored) cross-site scripting differs from reflected XSS in principle only in that the malicious code is stored on the web server, which means that it is delivered with every request. This is possible with any web application that stores user input on the server and delivers it again later, as long as the user input is not checked or the output is appropriately encoded .

Example:

A website offers a guest book in which visitors can leave messages or greetings. The entered data is stored in a database on the server and output again with each call.

Enter the following as a message: 

Eine wirklich sehr informative Website!<script type="text/javascript">alert("XSS")</script>

this would be delivered with each call and the script would be executed by the user's browser.

DOM-based or local

This type of attack is called DOM- based (dom injection) or local (local) cross-site scripting. In contrast to the common XSS variants mentioned above, the web application on the server is not involved at all. This means that even static HTML pages with JavaScript support are susceptible to this attack. The malicious code is passed directly to a client-side script for execution. This can, for example, be a JavaScript that uses a URL argument value to output data without checking it sufficiently. Such an attack requires a targeted call to a compromised URL.

Example:

A client-side scripting language such as JavaScript reads an argument value from the URL: http://example.com/foobar.html?arg=Argumentwert

And inserts this unchecked into the HTML document according to the following scheme: 

<p>Sie haben an die URL diesen String angehängt: Argumentwert</p>

If the calling URL is now manipulated as follows: The HTML code generated by the client-side script would look like this: http://example.com/foobar.html?arg=<script type="text/javascript">alert("XSS")</script>

<p>Sie haben an die URL diesen String angehängt: <script type="text/javascript">alert("XSS")</script></p>

Thus the above script would be executed in the context of the calling page.

This simple example does not work easily in Firefox because it implicitly encodes the characters of a URL in a link. However, DOM injections are known to which Firefox is also susceptible.

protection

Protective measures for website operators

In order not to provide a basis for XSS attacks through a web application , all incoming input values ​​must be regarded as insecure and checked on the server side before further processing. You should not rely on defining “bad” inputs ( black list ) in order to filter them out, as you cannot know exactly which attack methods are available. It is therefore better to define the “good” entries exactly ( white list ) and only allow such entries. This procedure is generally one of the best practices in programming and should be used wherever possible in order to prevent unexpected program behavior. However, depending on the application, it is not always easy to implement in practice, especially if the permitted input values ​​are very numerous.

Preventing a DOM injection is far less easy, since user input cannot be checked on the server side. Since this attack takes place by bypassing the server, the validity check for input data on the client side must take place in the browser, which, however, can easily be manipulated.

In order to secure an output (especially with reflected and persistent XSS ), it is necessary to replace the HTML metacharacters with appropriate character references so that they are treated as normal characters and not as metacharacters.

If the output occurs as part of URLs, the URL encoding must be applied to the input values. When outputting to JavaScript code, the characters must be escaped with a backslash " \".

It should be noted that in these three contexts (HTML, URL, JavaScript) different characters have a meta-function (for example " \" is not a metacharacter for HTML), so an encoding that is adapted to the output medium must always be used.

Most programming and scripting languages have predefined functions for replacing the metacharacters.

The possible solutions are diverse in the individual programming languages, although they always follow a similar principle. So in Java the problematic characters can be replaced or masked . Corresponding functions are available in PHP ( htmlspecialchars () ) and Perl ( HTML :: Entities :: encode_entities () ) that mask the problematic HTML characters .

In addition, the use of web application firewalls (WAF) can prevent simple (primitive) XSS attacks, at least in theory. In practice, secure applications are preferable to any WAF.

By using a content security policy , the website owner can effectively prevent cross-site scripting by defining permitted sources for website components such as Javascript.

Protective measures for website users

You can protect yourself against client-side XSS attacks by switching off JavaScript support (Active Scripting) in the browser. However, some browsers offer additional attack vectors . However, this only applies to "real" XSS, i.e. those that work with JavaScript. If only HTML injection (e.g. with <iframe .../>) is used, switching off Active Scripting in the browser does not help.

For some browsers there are also extensions that can be used to specifically detect and prevent possible XSS attacks (see NoScript ).

Web links

Individual evidence

  1. ↑ Christiane Rütten, Tobias Glemser: Security of Web Applications Heise Security , 2006, accessed October 6, 2012.
  2. ^ A b Amit Klein: DOM Based Cross Site Scripting or XSS of the Third Kind Web Application Security Consortium, 2005; Retrieved May 18, 2008.
  3. ↑ CLASP Security Principles: Input Validation OWASP Project (English), accessed May 19, 2008
  4. ↑ XSS (Cross Site Scripting) Cheat Sheet ( Memento from September 11, 2012 in the Internet Archive ) ha.ckers.org (English)
  5. ↑ Mask your own HTML characters ( memento of the original from March 11, 2015 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. in the selfhtml wiki @1@ 2Template: Webachiv / IABot / wiki.selfhtml.org