Non-Persistent cross-site scripting or non-persistent XSS, also known as Reflected XSS, is one of the three major categories of XSS attacks, the others are; persistent (or Stored) XSS and DOM-based XSS. In general, XSS attacks are based on the victim’s browser trust in a legitimate, but vulnerable website or web application (the general XSS premises). The reflected XSS condition is met when a website or web application employs user input in HTML pages returned to the user’s browser, without validating the input first.
With Non-Persistent cross-site scripting, malicious code is executed by the victim’s browser, and the payload is not stored anywhere; instead, it is returned as part of the response HTML that the server sends. Therefore, the victim is being tricked into sending malicious code to the vulnerable web application, which is then reflected back to the victim’s browser where the XSS payload executes.
Non-Persistent XSS is the most commonly carried out XSS attack, as the vulnerabilities which make it possible are more common than those which enable other types of XSS. Non-Persistent XSS is also called Type 1 XSS because the attack is carried out through a single request / response cycle.
Typical Steps in a Non-Persistent XSS Attack
Non-Persistent XSS [click to enlarge]
At this stage, the attacker searches vulnerable websites that can be used to carry out the attack. A visual verification is conducted in order to determine if user input is used in the response HTML page as in the following examples:
- Websites having search functionality and displaying the searched term on the HTML page returned with the results
- Websites with log on functionality, displaying the logged on user name on the returned HTML page
- Websites displaying information encoded in the HTTP headers, such as browser type and version
- Websites making use of DOM parameter values, such as
document.URL
Once a website is identified as being potentially vulnerable, the attackers try to inject script code into the relevant areas and verify if the script is returned in its original form (and executed). This process can either be manual or automatic, depending on the website /web application and the potential injection points found.
Malicious code (JavaScript) can be delivered in a URL in an encoded format, HTTP POST request, Flash video or image – so it is not obvious to the victim or victim’s browser.
Examples of Malicious Code Delivery
1) Potential injection point: URL
- Example:
www.mywebsite.com/search.asp?term=my+search+term
- Malicious example:
www.mywebsite.com/search.asp?term=<script>MaliciousFunction(...)</script>
2) Potential injection point: DOM
- Example:
www.mywebsite.com/logon.asp?user=Mary
- Malicious example:
www.mywebsite.com/logon.asp?user=<script>MaliciousFunction(...)</script>
b) Social engineering
Using social engineering, the attacker will influence the user into clicking on a crafted link that contains the malicious URL which injects code into vulnerable web pages / web applications, using one or more of the following techniques:
- SPAM email containing a crafted link
- SPAM email containing HTML code
- Malicious web pages containing a malicious URL
- ClickJacking
- Social media: messages / posts containing a malicious link
- XSS techniques: using Persistent (Stored) XSS, malicious links can be saved as part of forum posts / comments and reflected back to visiting users
- Other types of attacks: DNS rebinding – compromises the hosts file causing your browser to get redirected to malicious pages instead of the intended web page, compromising the wireless router, etc.
c) Payload execution/consequences
Once the victim has clicked on the malicious link, and if the attack is successful, the payload will get executed in the victim’s context and call home to the attacker in order to communicate the results, as well as upload stolen data, etc. The consequences vary, because the attack enables execution of arbitrary code, usually with elevated privileges – most home users still use the default “administrator” account and although latest Windows operating systems come with user access control and hardened browser policies, they are usually disabled in order to improve on the user experience. Usual targets of attacks are:
- Cookie theft – attackers can read authentication cookies that are still active, and can be used to perform further attacks.
- Data theft – attackers can read browser history, directory listings, file contents, helping prepare for next attacks or using information in other malicious ways.
Defending Against Non-Persistent XSS
a) Server-side
The best way to prevent cross-site scripting is to make sure that the web application does not make use of user input in the return HTML pages, without validating it first. Validation implies verification of the user input to determine if the input is valid, according to its purpose. In case the validation functions find script tags, either in plain text or encoded, they should sanitize the input before it is passed on to the response HTML and make sure that the script is rendered harmless. The strength of the sanitization depends on the ability of the validation functions to identify scripts in the user input.
With the increased dynamics in web page content, as well as web 2.0, keeping the web application XSS-free also involves regular assessment tests carried out using web vulnerability scanners that are able to perform penetration testing against the web application, identify XSS vulnerabilities and provide the necessary information on how to fix them.
b) Client-side
Users should always be weary of what they click on; avoid playing seemingly harmless games, claiming random prizes or opening emails that don’t come from a trusted source. At the same time, users should avoid installing browser plugins which do not have a good reputation and those which are not really a necessity (such as toolbars), since these may make their browser vulnerable too. Using secure and up-to-date web browsers will also help users keep away from “victim” status. Vulnerable websites are just the medium – the real target is you.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
