Reflected XSS

Reflected XSS occurs when client-supplied data is echoed back to the enduser without being validated properly by the web application. If this client-supplied data is insufficiently validated, an attacker may be able to inject HTML or JavaScript code into a web parameter, causing the web application to echo this code back to the enduser. This injected code is then interpreted and executed by the user's web browser.

This vulnerability can be used, for example, to alter the look of the vulnerable web page or to trick a user into running malicious JavaScript code, including the ability to capture session identifiers or perform JavaScript port scanning against your internal network. The following code listing demonstrates how an attacker is able to inject malicious JavaScript into a vulnerable web application parameter that when echoed back to the user will rewrite the entire web page. This code listing relies on the browser supporting the document.clear() and document.write() JavaScript functions. Similarly an attacker can use the JavaScript AttackAPI that has functions to implement a range of different attacks via XSS, including rewriting the page content.

http://www.organization.com/?vulnparam=

<IMG SRC=%javascript:document.clear();document.write("XSS")%>

This attack causes the actual URL for the organization's web application to be maintained within the address bar of the victim's web browser even though the entire contents of the page have been rewritten. This allows an attacker to exploit the trust relationship that the user has with the URL when the user sees the correct domain name shown in the address bar of his or her browser. This may keep some users from becoming suspicious about entering their details on the malicious web page.

XSS-Proxy is a Perl-based application that allows an attacker to proxy web requests through a victim's web browser. This is generally performed via an XSS vulnerability where the XSS-Proxy JavaScript file is injected into the malicious web page that the victim has visited. This may allow an attacker to gain proxied authenticated access to a web application as the victim, compromising the victim's account.

Universal Cross-Site Scripting (UXSS) is a unique XSS attack that takes advantage of the way PDF files are served and vulnerabilities in certain versions of Adobe Acrobat Reader. If attackers are able to convince their victims into requesting a PDF file with malicious PDF anchors, as shown in the following code listing, they can exploit the UXSS vulnerability found in Adobe Acrobat Reader Plugin 7.0.x or less.

http://www.malicious site.com/file.pdf#malicious=javascript:alert("xss");

Stored XSS

Stored XSS (or persistent XSS) is slightly different, since instead of the client-supplied data being echoed back to the enduser immediately, the data is actually 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 type of attack can be used to deface a website by permanently rewriting the vulnerable page, as described in "Spoofing Web Applications," or can be used to perform session hijacking attacks by injecting JavaScript that posts session identifiers to the attacker each time a user visits the page. The latter attack may compromise the account of every user who views the vulnerable page.

Figure 13-6 demonstrates how an attacker can successfully used XSS to inject an HTML iFrame tag into a vulnerable web page. This causes the external Google website to be inserted into the middle of the page since the web application parameter was not validated sufficiently.

Figure 13-6 XSS exploited to inject the Google website into the vulnerable page

A new exploitation technique has been developed by Alexander Sotirov, which uses specific sequences of JavaScript allocations to enable precise manipulation of browser heap layouts. This allows an attacker to exploit difficult heap corruption vulnerabilities within web browsers with great reliability and precision, dramatically increasing the risk associated with stored XSS vulnerabilities since they can now be used as a distribution platform for extremely accurate client-side exploits.

DOM-Based XSS

DOM stands for Document Object Model, which is a storage mechanism used by your web browser 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/#<script>alert(document.cookie);</script>

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.

Was this article helpful?

0 0
The Ultimate Computer Repair Guide

The Ultimate Computer Repair Guide

Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.

Get My Free Ebook


Post a comment