Difference between revisions of "Cross-Site-Scripting (XSS)"
| Line 2: | Line 2: | ||
== Cross-Site-Scripting (XSS) == | == Cross-Site-Scripting (XSS) == | ||
Cross-Site Scripting is a class of web application vulnerabilities, which is still one of the most common security vulnerabilities in web applications. In general, XSS vulnerabilities allow an attacker to execute script code in the web browser of the victim and can be used to gain data from users, like cookies or private information. It's also possible to trigger actions on websites, redirect to other sites or hide advertisements. A short game with which some options can be seen easily: [https://xss-game.appspot.com/ XSS game] | |||
== Types == | == Types == | ||
| Line 8: | Line 8: | ||
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]] | [[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]] | ||
=== | === Stored (Type I) === | ||
With Stored XSS, also referred to as persistent XSS, the application or API saves uncleaned user input on the server, such as in a database, comment field, visitor log, etc., which then is displayed at a later point in time by another user or administrator, that requested the stored information. | |||
=== Reflected (Type II) === | === Reflected (Type II) === | ||
Reflected XSS is a non-persistent attack and is used to steal session cookies from a user. With Reflected XSS, the application or API includes unchecked and unmasked input from the user as part of the HTML output. If the attack was successful, the attacker could execute arbitrary HTML and a scripting language such as Javascript in the victim's browser. Typically, a user will have to click on a malicious link to do this. The attacker tries to bring this harmful link to the victim, via advertising, e-mail etc. | |||
=== DOM Based (Type 0) === | === DOM Based (Type 0) === | ||
DOM Based | A DOM-based XSS vulnerability happens when dynamic content is generated with the help of the Document Object Model (DOM). The DOM is a programming interface that specifies the structure of documents. In the scenario of a DOM-Based attack, the DOM contains user inputs that are further processed without being checked. A corresponding attack takes place in the JavaScript in the user's browser. | ||
== Prevention== | == Prevention== | ||
* | |||
* | In the case of reflected and stored XSS, the of prevention of both vulnerabilities are the task of the programmer. The programmer should be encouraged to use secure programming measures, like Context-sensitive server-side output encoding, to ensure that it is not possible to inject malicious scripts into the site through incorrect or unchecked entries. Problematic meta characters should be filtered out of the input and the permissible inputs should be fully described using regular expressions. The user, on the other hand, can protect himself from executing script commands in the browser only by deactivating scripts in the browser. | ||
* | |||
== References == | |||
* https://owasp.org/www-community/attacks/xss/ | |||
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html | |||
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS) | |||
Revision as of 16:04, 21 November 2021
Cross-Site-Scripting (XSS)
Cross-Site Scripting is a class of web application vulnerabilities, which is still one of the most common security vulnerabilities in web applications. In general, XSS vulnerabilities allow an attacker to execute script code in the web browser of the victim and can be used to gain data from users, like cookies or private information. It's also possible to trigger actions on websites, redirect to other sites or hide advertisements. A short game with which some options can be seen easily: XSS game
Types
There are two ways to classify XSS attacks. Up until 2012 the types DOM-based (Type 0), stored/persistent (Type I) and reflected/non-persistent (Type II) were used. As these three types can overlap the research community started to use the terms Server XSS and Client XSS from 2012 on.
Stored (Type I)
With Stored XSS, also referred to as persistent XSS, the application or API saves uncleaned user input on the server, such as in a database, comment field, visitor log, etc., which then is displayed at a later point in time by another user or administrator, that requested the stored information.
Reflected (Type II)
Reflected XSS is a non-persistent attack and is used to steal session cookies from a user. With Reflected XSS, the application or API includes unchecked and unmasked input from the user as part of the HTML output. If the attack was successful, the attacker could execute arbitrary HTML and a scripting language such as Javascript in the victim's browser. Typically, a user will have to click on a malicious link to do this. The attacker tries to bring this harmful link to the victim, via advertising, e-mail etc.
DOM Based (Type 0)
A DOM-based XSS vulnerability happens when dynamic content is generated with the help of the Document Object Model (DOM). The DOM is a programming interface that specifies the structure of documents. In the scenario of a DOM-Based attack, the DOM contains user inputs that are further processed without being checked. A corresponding attack takes place in the JavaScript in the user's browser.
Prevention
In the case of reflected and stored XSS, the of prevention of both vulnerabilities are the task of the programmer. The programmer should be encouraged to use secure programming measures, like Context-sensitive server-side output encoding, to ensure that it is not possible to inject malicious scripts into the site through incorrect or unchecked entries. Problematic meta characters should be filtered out of the input and the permissible inputs should be fully described using regular expressions. The user, on the other hand, can protect himself from executing script commands in the browser only by deactivating scripts in the browser.