Cross-site scripting, commonly referred to as XSS, is listed third in the OWASP Top 10 for 2013 Web Application Security risks. Unlike SQL injection attacks, which target data on the server, XSS provides a vector for attacking the users of a vulnerable web site. At a general level, XSS is when an attacker can cause a web site to render with unintended script content. This script content is considered the payload of an XSS attack and can range from a simple pop-up window all the way to browser exploitation for remote code execution. XSS occurs when a web application renders user controlled data without escaping special characters, such as angle brackets (Angle brackets designate hypertext markup unless they are escaped as < and > when sent to the browser). Cross-site request forgery, commonly known as XSRF or CSRF, weighs in eight in the OWASP Top 10 for 2013. Similar to XSS, CSRF (pronounced sea-surf) uses an oversight in the design of a web application to attack users rather than actually attacking the server itself. Successful exploitation of a CSRF vulnerability causes the web application to process an attacker-specified request within the context of the victim’s authenticated session. For a most basic example, let us consider a web-based payment system, which allows users to transfer money between accounts specified as arguments to a PHP script. Normally, transfers happen when the user clicks a series of links instructing the site to transfer money but it is also possible to craft a URL which will perform the transfer. Specifically, browsing to http://vulnerable-site/transfer.php?acct_to=123456&amount=1337 while authenticated to the vulnerable-site will transfer $1337 from the user’s account to account number ‘123456.’ This works because the web browser includes authentication details with each request to http://vulnerable-site regardless of whether the URL was linked from another page or if the location were directly entered into the URL bar. An attacker can use this behavior to their advantage in many ways but for this simple case, all that is needed is for the attacker to entice a victim to load an HTML document including <img src=http://vulnerable-site/transfer.php?acct_to=123456&amount=1337 height=0 width=0>. When the browser attempts to load that resource, it passes along authentication (if present) and the web application will process the transfer without recognizing that the request did not originate from itself. More complicated sites, which make use of form data posts, can also fall victim to CSRF attacks. For this situation, an attacker can clone a form from the vulnerable site, populate fields with values and use JavaScript to automatically submit the form. Often times, CSRF vulnerabilities can be exploited in unison with XSS vulnerabilities, thereby elevating the risks associated with a CSRF attack. For example, I recently identified that the phpScheduleIt application does not implement CSRF protection and consequently requests can be forged by other sites to perform actions on the phpScheduleIt application, including password reset. Although this in itself can be considered as a moderately severe vulnerability, the problem is compounded by the fact that certain administrator-controlled input is not filtered for script content. In theory, an attacker could then dupe an administrator into visiting a page, which will forge a request to insert XSS. Recently, VERT began an evaluation of a very cool packet capture sharing application. Almost immediately I noticed that it is prone to XSS in a variety of places and meanwhile, another VERT researcher, Ian, pointed out that the site is also prone to CSRF. Putting these two aspects together, I was able to create a proof-of-concept exploit demonstrating that CSRF could be used to exploit an XSS vulnerability, which is otherwise protected from the perspective of the web-based user interface. What’s worse is that when the XSS is inserted, it leaves behind a trail of evidence implicating the victim as the attacker thereby making it that much more difficult to attribute the attack back to the attacker. This proof-of-concept was developed very quickly by leveraging Google Chrome’s development tools to identify the vulnerable web form and copy it to a fresh HTML document. After copying the form it is just necessary to seed the form fields with the desired value attributes and add some JavaScript to submit the form. The resulting page can be loaded as an invisible IFRAME so that the user is unaware that they have submitted a request to the site. As previously mentioned, XSS vulnerabilities can be eliminated if proper precautions are made when handling user-controlled data. Over the years, several techniques have evolved for protecting against XSS within web application source code. One such defense is to prepare a white-list of allowable characters making sure to disallow markup characters such as the angle brackets (‘<’ and ‘>’). Alternatively, user-submitted data can be escaped so that unsafe characters are replaced with their safe counterparts. For example, < instructs the browser to display the ‘<’ without interpreting it as a delimiter. Many programming languages even have built-in mitigations such as XSS filters which when used properly will recognize and remove or alter malicious content. Protecting against CSRF, however, can require more fundamental changes to the architecture of a web site. One simple mitigation technique is to enforce an idle timeout so as to limit the window of opportunity for a CSRF. To properly solve CSRF, a secure web site must be able to validate that a request originated from itself rather than having been forged by a separate site. Although it is possible to use the ‘HTTP Referer’ header to infer the origin of a request, some browsers may withhold the field and some proxy servers will not relay it (It is also possible in some circumstances for an attack page to forge HTTP headers). A more thorough solution is to supplement requests with a secure identifier which can be verified by the server but not forged by the attacker. This identifier is commonly referred to as a CSRF token and library implementations are available for a variety of web technologies. XSS and XSRF/CSRF are prevalent threats to the security of web 2.0 applications and are all too often misunderstood. What’s worse is when these issues are written off as unimportant because the risk is primarily to the user and not to the site operator. If you are a web developer, I strongly encourage you to read up on mitigation techniques as well as to check your own applications for vulnerability. With so many tools and libraries available, it is not difficult to protect against these attack categories and it is often times even easier for an attacker to recognize the problems.
