Bypassing XSS Auditor: Taking Advantage of Badly Written PHP Code

INTRODUCTION PHP (a recursive acronym for “PHP Hypertext Preprocessor”) is an open source server-side scripting language designed for web development, but it is also used as a general-purpose programming language. According to Netcraft’s Web Server Survey [1], by January 2013, PHP was installed on more than 240 million websites. The most prominent websites that use PHP include Google, Facebook, Yahoo!, Wikipedia, Amazon, Ebay, YouTube, Flickr, and many more. PHP code can be mixed with HTML code or it can be used in combination with various template engines and web frameworks. PHP code is usually processed by a PHP interpreter, which is implemented as a web server’s native module or a Common Gateway Interface (CGI) executable. After the PHP code is interpreted and executed, the web server sends the resulting output to its client, usually as a part of the served web page. Although PHP is a powerful, free, and easy to learn and use programming language, it comes with certain features that makes easy to write insecure code. According to the National Vulnerability Database [2], in 2013, 9% of all vulnerabilities reported were related to PHP [3]. Furthermore, it is worth noting that since 1996 about 30% of all vulnerabilities, which are reported to the same database are related to PHP. Web applications that are implemented in PHP can be vulnerable to various exploit vectors, such as XSS (Cross-Site Scripting), SQL Injections, CSRF (CrossSite Request Forgery) injections etc. The OWASP Top Ten for 2013 [4] lists XSS as the most common security risks to web applications. More specifically, XSS [5] is an application-layer threat that emanates from the security weaknesses of client-side scripting languages, HTML and JavaScript (or more rarely VB Script, ActiveX or Flash). The purpose of an XSS attack is to inject malicious code in a website, in order to bypass security access controls and compromise data or perform session hijacking. An XSS attack occurs when an adversary manipulates and injects a malicious code in a web application (usually JavaScript), in order to alter data contexts in HTML code into a scripting context -usually by injecting new HTML, JavaScript strings or CSS markup. This injection code is sent to the web application via HTTP parameters and it is executed by the client browser and eventually, inserted into the output of the web application. There are three categories of XSS vulnerabilities: a) Reflected XSS: The concept of this kind of XSS attack is that the victim clicks on a crafted link and the attack is initiated. More specifically, an XSS vulnerability is reflected in the application’s output, if the injection is echoed by the server in the response of an HTTP request. Reflection can occur with error messages, search engine submissions, comment previews, etc. This form of attack can be mounted by persuading a user to click a link or submit a form of the attacker’s choice, issues that may involve emailing the target, mounting a UI Redress attack, or using a URL shortener service to disguise the URL. b) Stored XSS: The injection is resilient throughout sessions by being permanently stored in a data storage and it is echoed every time a user visits the unsafe web site or views the targeted data. Obviously, the range of potential victims is greater than in the reflected XSS, since the payload is displayed to any visitor. c) DOM-Based XSS: DOM-based XSS attacks control the web page’s Document Object Model (DOM), which serves as a cross-platform and a language-independent model that interacts with objects in HTML. DOM-based XSS can be either reflected or stored. The attacker is allowed to run JavaScript scripts in a web browser through targeting vulnerabilities in the HTML code and interacting with the DOM of the web page. The current countermeasures to detect XSS attacks are: i) server-side, ii) network-based using Web Application Firewalls (WAF), and, iii) client-based using XXS filters at the level of browsers. In this work, we will specifically focus on XSS filters and how can be trivially bypassed using simple yet effective techniques. By design, web browsers must execute the HTML and JavaScript code which is obtained from a web application through the HTTP protocol. The objective of XSS filters is to detect “dangerous” attribute tags inside HTTP parameters of the GET and POST HTTP methods and prevent the execution of the injected JavaScript code. An XSS filter, named XSS auditor [6] has been implemented in the WebKit browser engine [7] and it is used by the most widely used browser, that is Google Chrome / Chromium as well as by the Apple Safari browser. Microsoft’s Internet Explorer browser, from version 8 to the latest, provides an XSS filter [8]. On the other hand, Mozilla Firefox does not include a pre-installed XSS filter, but there is a free plugin named NoScript [9], which can be installed by end-users and it is considered to be an efficient XSS filter for Firefox browser. Each of the above XSS filters detects XSS attack vectors with different techniques. More specifically: a) The XSS filter of Internet Explorer handles regular expressions to identify malicious attack vectors in outgoing HTTP requests. The filter creates a unique signature of the potentially malicious part, instead of removing it, and waits for the HTTP response to arrive at the web browser. If the signature matches anything that is contained inside the response, the filter blocks and eliminates the suspicious parts. b) NoScript Firefox Plugin handles regular expressions to identify outgoing HTTP requests for malicious attack vectors. If there is a match discovered between the regular expressions and the parts of the URL concerning the attack vector, then these URL parts are removed from the HTTP request. c) Unlike the previous two filters, XSS Auditor does not use regular expressions to filter outgoing HTTP requests [10]. In particular, the XSS Auditor examines the DOM tree created by the HTML parser, making the semantics of those bytes clear. In this way, the XSS Auditor can easily identify which parts of the response are being treated as script. We have pinpointed that badly written web application has the unfortunate ability of disabling XSS filters. Thus, developers of web applications may unintentionally help malicious actors to perform XSS attacks. In this paper, we analyze two attacks that take advantage of poorly written PHP code to bypass the XSS filter of WebKit (i.e., XSS Auditor) and perform XSS attacks. In particular, the first attack is called PHP Array Injection, while the second attack is a variant of the first one and it is named as PHP Array-like Injection. Both attacks exploit improper use or management of variables and arrays in PHP code to bypass the XSS Auditor. We elaborate on these attacks by presenting concrete examples of poorly written PHP code and constructing attack vectors to bypass the XSS Auditor. We have also audited the source code of PHP applications to examine the prevalence of the identified attacks. We have discovered that many opensource Content Management Systems (CMS) are vulnerable to PHP Array-like Injection attacks. Finally, to defend against the identified attacks, we provide proper code writing rules for developers, in order to build secure web applications. Additionally, we have managed to patch the XSS Auditor, so that it can detect our identified XSS attacks. The rest of the paper is organized as follows. Section 2 provides the background analyzing the related work and the architecture of the XSS Auditor. Section 3 present examples of badly written PHP code that may result in bypassing XSS Auditor and elaborates on the identified XSS attacks. Section 4 provides secure code writing guidelines and analyzes the patches that we have committed to XSS Auditor. Finally, Section 5 includes the conclusions.