Cross Site Scripting (XSS)
Introduction to XSS
Cross Site Scripting or simply XSS attacks are types of injection, in which malicious scripts are injected into the web-sites. XSS attacks occur when an attacker uses a web application to send malicious code, mostly in form of browser side script (javascript or VBscript), to the end user. By using these scripts, user bypasses the access controls and limits. Flaws that allow these attacks are quite widespread and occur anywhere on the web application that uses input box to ask for input from user and uses it without any kind of validation and encoding.
Working of XSS
An attacker can use XSS to send malicious script to the victim. The browser has no way to know whether to trust script or not, and hence browser have no issues in executing these scripts. These scripts may be written for the purpose of stealing cookies, session tokens, or any other sensitive data retained by the browser. These scripts can even rewrite the content of the HTML page.
Types of XSS:
XSS are of three types:
1.
Stored XSS: In Stored XSS (or persistent XSS), the data is stored within the web application database and is sent to the user each time the data is used within a web page. This functionality is commonly seen when posting messages on web forums, where the user’s message is stored on the server and is sent back to any user who opens the message. If the data contained within the user’s message is not validated properly by the web application, an attacker may be able to inject malicious JavaScript code into the message that will be run by every user who views the message. This attack may compromise with the account of every user who views the vulnerable page.
2.
Reflected XSS: Reflected attacks are those where the injected codes are reflected off the web server, such as in any error message, search result or any other response that includes some or all of the inputs sent to the server, as part of the request. Reflected attacks are delivered to the victims via another route such as a link in an email message or on some other web server. When user clicks on such link then the code written behind this script gets executed within the victims browser, and as already stated, browser thinks it from any trusted source, so don’t show any problem in executing them. Once the code gets executed, then depending on the type of the script, it can perform actions like stealing cookies, sessions, sensitive data from user’s browser etc.
3.
DOM based XSS: These are very rarely used type of XSS. DOM stands for Document Object Model, which is a storage mechanism, is used by web browsers to store information relating to your current web sessions. DOM-based XSS takes advantage of DOM sections that store the requested URL, such as document.BaseURI, document.location, and document.location.href. If an XSS exploit is included within the URL, and the resulting page retrieves and displays the contents of any of these DOM elements, then XSS is triggered. To make things even worse, if the exploit is placed after a hash (#) symbol, everything after the hash symbol isn’t actually sent to the web application, as shown here: http://www.example.com/#This means that developers can’t actually protect against this type of XSS vulnerability within the server-side code, but must actually rely on client-side security, usually implemented in JavaScript, to perform encoding and data validation on the DOM data.
Searching for vulnerability
We can use either manual method or a vulnerability scanner to check for the vulnerability. To test an xss vulnerability, we need to enterin serach box of the web page. If in return, you get any popup alert, it means this page is vulnerable to XSS. We can use different combination of hex codes also, like %3C instead of <, %3E instead of > and so on.
Consequences of XSS:
1. Disclosure of user’s session data
2. Cookie stealing
3. Disclosure of end users’ files
4. Installation of Trojan horse
5. Redirecting users to any other site
6. Modify the content of the HTML
Prevention from XSS
This section is intended for web developers, who want to write their codes in such a way so as to get prevented from being attacked by XSS. We can do it, simply by following some good coding practices.
Encode output based on input parameters for special characters
Filter input parameters for the special characters
Filter output based on the input parameters for special characters
Possible sources of malicious data
Query string
Cookies
Posted data
URLs and piece of URL e.g. PATH_INFO
Data retrieved from users that is persisted in some fashion in a database
XSS Attack types with example payloads
Simple script injection into a variable
o http://localhost/page.asp?variable=
Simple variable injection that displays the victim’s cookie
o http://localhost/page.asp?variable=
Injection into an HTML tag: This injected link will e-mail the victim’s cookie to a malicious site
o http://localhost/page.php?variable=”>
Injection using HTML BODY “onload” attribute
o http://localhost/frame.asp?var=onload=alert(document.domain)
Injection using IMG tag
o http://localhost//cgi-bin/script.pl?name=>”’>