What is Cross-Site Scripting (XSS)?
- Stored XSS Attacks -
Injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log or comment field. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.
This vulnerability can be used to conduct a number of browser-based attacks including:
- Hijacking another user’s browser
- Capturing sensitive information viewed by application users
- Pseudo defacement of the application
- Port scanning of internal hosts (“internal” in relation to the users of the web application)
- Directed delivery of browser-based exploits
- Other malicious activities
Stored XSS does not need a malicious link to be exploited. A successful exploitation occurs when a user visits a page with a
- Reflected XSS Attacks -
Injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web site. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.
Testing for XSS Vulnerability
A browser pop-up titled “XSS” might come up if not dealing with XSS correctly.
<body onload=alert('test1')> <b onmouseover=alert('Wufff!')>click me!</b> <img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>
Tools for testing XSS vulnerability
- Burp Suite
We will cover the details of the tools in future posts.