An Empirical Analysis of XSS Sanitization in Web ... Flipbook PDF

An Empirical Analysis of XSS Sanitization in Web Application Frameworks Joel Weinberger Prateek Saxena Devdatta Akhawe M

---

124 Views
69 Downloads
FLIP PDF 252.52KB

DOWNLOAD FLIP

REPORT DMCA

An Empirical Analysis of XSS Sanitization in Web Application Frameworks

Joel Weinberger Prateek Saxena Devdatta Akhawe Matthew Finifter Richard Shin Dawn Song

Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2011-11 http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-11.html

February 9, 2011

Copyright © 2011, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission.

An Empirical Analysis of XSS Sanitization in Web Application Frameworks Joel Weinberger, Prateek Saxena, Devdatta Akhawe, Matthew Finifter, Richard Shin, Dawn Song University of California, Berkeley

Abstract Filtering or sanitization is the predominant mechanism in today’s applications to defend against cross-site scripting (XSS) attacks. XSS sanitization can be difficult to get right as it ties in closely with the parsing behavior of the browser. This paper explains some of the subtleties of ensuring correct sanitization, as well as common pitfalls. We study several emerging web application frameworks including those presently used for development of commercial web applications. We evaluate how effective these frameworks are in guarding against the common pitfalls of sanitization. We find that while some web frameworks safeguard against the empirically relevant use cases, most do not. In addition, some of the security features in present web frameworks provide a false sense of security.

1. Introduction Cross-site scripting (or XSS) attacks continue to plague existing and emerging web applications, despite receiving intense focus from both industry and academia. Researchers have proposed many novel defenses, ranging from purely server-side to browser-based or both. Sanitization or filtering, the practice of encoding or eliminating dangerous constructs in untrusted >



Sub-grammar(s) HTML HTML JavaScript, HTML URI, HTML CSS, HTML

Embedding contexts HTML tag content Double-quoted HTML attribute Single-quoted JavaScript string in double-quoted HTML attribute Domain of a URI in an unquoted HTML attribute RGB color specification in double-quoted HTML attribute

TABLE 1. Examples of common embedding contexts.

HTML code

HTML parser

URI parser

1. PC> This shows a fragment of HTML code with a context transition from an HTML attribute context to the URI parser’s scheme (e.g., http: or mailto:) context. Identifying static transitions is feasible using a high fidelity model of a web browser for parsing. Dynamic Context Transitions. Dynamic context transitions occur when > If the developer HTML entity escapes only the untrusted >Link supplied by user.

is a template variable in a > {% endif %}

map.addOverlay(new GMarker(point, {{ crime.icon }}))

We conclude that context-insensitive sanitization is inadequate. Developers using context-insensitive sanitization must implement their own sanitizers to ensure security anyway. To verify this, we investigated how often sites rely on Django’s auto-sanitization and for what fraction of the incorrectly autosanitized sinks the developer resorted to manual sanitization. We examined a random sample of 10 Django applications (from a list of open-source Django applications [21]) to determine the fraction of variables emitted into an application’s templates that are protected by Django’s autoescape. Our results are presented in Table 6. In all the applications in our sample, the majority of variable sinks were autoescaped. Though the majority of variables are emitted into HTML tag content contexts, and are therefore protected by autoescape, a significant fraction are not. Table 6 further distinguishes the fraction of sinks appearing in HTML tag content context versus others. In all contexts other than the HTML tag content context, inconsistent (and technically incorrect) sanitization is applied, which can lead to XSS vulnerabilities. Our subsequent manual investigation of all these cases revealed that the developer explicitly resorted to manual sanitization. 3.3.2. Context-Sensitive Sanitization. Three web frameworks, namely GWT, Clearsilver, and Ctemplate, support context-sensitive automatic sanitization. As in the other frameworks, when each template is emitted to the output, the platform automatically sanitizes the }}

Click to display name.
Homepage: {{PAGENAME}}

This template contains three separate data holes in which values of variables will be emitted. When the template is processed, the context of the first hole, {{NAME}}, is recognized as a JavaScript string context, and just before the hole is filled with the value of NAME, the :javascript_escape modifier will be applied to the variable. This modifier indicates to the template parser that the JavaScript escape sanitizer should be applied to variables in this data hole before variable substitution. This auto-escaping is equivalent to explicitly writing {{NAME:javascript_escape}}

instead of just {{NAME}}. For the second hole, {{URL}}, the :url_escape_with_arg=html modifier is applied indicating that the data hole is in a URL context and should be sanitized appropriately. Finally, the :html_escape modifier is automatically applied to the value of {{PAGENAME}} before the third hole is filled, indicating that the data hole is in an HTML context and variables should be HTML entity encoded. Handling Nested Contexts or Static Context Transitions. Support for nested contexts varies significantly, as shown in Table 4. The Google Ctemplate framework offers sanitization for the maximum number of contexts, including some of those that involve implicit static transition contexts. The HTML attribute context (e.g., href, style, onclick) is a transition context as defined in section 2, i.e., certain attributes are recognized as URI attributes. JavaScript event handlers or style attributes are examples of these. Most of the other frameworks do not support any nesting of contexts. Handling Dynamic Context Transitions. None of the web frameworks support sanitization for dynamic context transfers. That is, they do not identify potential context transfers due to the execution of JavaScript for auto-sanitization. Even the cases that can be dispatched with simple static analyses are not handled, such as in the following example

3.4. Sanitization Strategy: Blacklists vs. Whitelists One web framework we studied employs a blacklist-based sanitization approach. CodeIgniter employs a blacklist of filters in its xss clean function, which applies several regular expression replacements in sequence. These regular expressions serve to blacklist potentially dangerous code that may appear in any context. For example, all instances of document.cookie are replaced with the text [removed]. Unfortunately, this blacklisting approach inspires little confidence in the completeness of the filter. Additionally, it may break functionality because it essentially applies each context’s filter regardless of which context the data will ultimately appear in. This means, for example, that any occurrence of the term document.cookie will be removed, even if it is simply in the body of a user’s forum post, and therefore intended to be placed in an HTML context. Other than CodeIgniter, all frameworks used a whitelistingbased canonicalization approach described in Section 2. For HTML tag contexts, basic HTML entity encoding was supported in all frameworks. In addition, we found more comprehensive handling of HTML contexts in a number of other frameworks. For instance, Yii provides an interface to HTML Purifier [29] and its documentation recommends this interface as the preferred XSS defense mechanism. HTML Purifier fully parses an HTML snippet, and it claims to remove arbitrarily nested scripts in HTML tag content contexts. While it robustly

Web Application

GRAMPS Genealogy Management HicroKee’s Blog FabioSouto.eu Phillip Jones’ Eportfolio EAG cms Boycott Toolkit Damned Lies oebfare Malaysia Crime Philippe Marichal’s web site

Num. Sinks

% Autosanitized Sinks

% Sinks not sanitized (marked safe)

% Sinks manually sanitized

% Sinks in HTML Context

% Sinks in URL Attr. (including scheme)

% Sinks in JS Attr. Context

66.4

% Sinks in URL Attr. (excluding scheme) 3.4

286

77.9

0.0

22.0

92 55 94

83.6 90.9 92.5

7.6 9.0 7.4

19 347 359 149 235 13

94.7 96.2 96.6 97.3 98.7 100.0

5.2 3.4 3.3 2.6 1.2 0.0

% Sinks in JS Number/String Context

% Sinks in Style Attr. Context

30.0

0.0

0.0

0.0

8.6 0.0 0.0

83.6 67.2 73.4

6.5 7.2 11.7

7.6 23.6 12.7

1.0 0.0 0.0

0.0 1.8 2.1

1.0 0.0 0.0

0.0 0.2 0.0 0.0 0.0 0.0

84.2 71.7 74.6 85.2 77.8 84.6

0.0 1.1 0.5 6.0 0.0 0.0

5.2 25.3 17.8 8.0 1.7 15.3

0.0 0.0 0.0 0.0 0.0 0.0

0.0 1.7 0.2 0.0 20.4 0.0

10.5 0.0 6.6 0.6 0.0 0.0

TABLE 6. Actual usage of auto-sanitization in Django applications. The first two columns are the number of sinks in the templates and the percentage of these sinks for which auto-sanitization has not been disabled. Each of the remaining columns shows the percentage of sinks that appear in the given context.

handles untrusted data emitted into an HTML tag content context, it does not provide functionality for emitting untrusted data into any other contexts.

3.5. Placement of Sanitizers Finally, we find that for frameworks that support autosanitization, there are variations in where to apply the sanitizers. Borrowing terminology from aspect-oriented programming, we refer to each set of program points at which autosanitization is applied as a sanitization pointcut. We have identified three different sanitization pointcuts in the frameworks we studied; Table 5 indicates which one is employed by each framework. Request reception. Sanitizing at request reception has the advantage of precisely identifying all untrusted data. However, the disadvantage is that at this pointcut, there is no knowledge of where this untrusted data is going to end up. This makes it impossible to apply the least restrictive safe sanitization policy; instead you must apply an extremely restrictive sanitization policy under the assumption that the untrusted data could end up being emitted into any context. Database insertion. Sanitizing at database insertion time ensures that no unsafe data is ever stored. Accordingly, this pointcut does not protect against reflected XSS vulnerabilities, but only stored XSS vulnerabilities (and SQL injection vulnerabilities, which we do not consider in the present work). We have anecdotal evidence that this pointcut can lead to subtle bugs. In a program that we analyzed, all data was sanitized before entering the database. This meant that when a user registered for the web site, his username was escaped before being stored. For a user whose name contains a character that is escaped, all login attempts fail because the username entered

(which is not sanitized) does not match any stored username (all of which have been sanitized). As in the request reception pointcut, this problem results from a lack of knowledge regarding where the untrusted data will end up being used. In this case, its correct use in a comparison is precluded by being sanitized before database insertion. Template processing. Sanitizing at template processing time has the advantage of being fail-safe because every output is sanitized by default. The disadvantage of this pointcut is very much the inverse of that of the request reception pointcut: at template processing time, the separation between untrusted and trusted data might have been lost. You cannot tell at this pointcut whether the data is trusted or untrusted. For this reason, some variables may accidentally be escaped multiple times, which could break functionality. The developer is responsible for manually marking the pieces of data that should be considered trusted, which is an inconvenient and error-prone process, though the errors do fall on the side of breaking functionality rather than security.

4. Web Applications We evaluate a set of large, widely used web applications to compare the features provided by web frameworks with those required for authoring real-world applications. We gather empirical evidence from 8 diverse web applications, ranging from email clients to medical record management systems, about their use of embedded contexts and sanitizers. First, we evaluate whether applications use contexts that are inherently difficult to secure (as outlined in Section 2.5). Second, we compare the set of contexts used by applications with the set of contexts supported by web frameworks. Third, we evaluate whether these applications employ whitelisting or blacklisting

Application

Description

RoundCube Drupal Joomla WordPress MediaWiki PHPBB3 OpenEMR Moodle

IMAP Email Client Content Management System Content Management System Blogging Application Wiki Hosting Application Bulletin Board Software Medical Records Management E-Learning Software

LOC

19,038 20,995 75,785 89,504 125,608 146,991 150,384 532,359

HTML Context

• • • • • • • •

URL Attr. (excluding scheme) • • • • • •

URL Attr. (including scheme)

JS Attr. Context

JS Number/String Context

• • • • • •

• •

•

•

• • • • • • • •

• • • •

Number of Sanitizers

Number of Sinks

30 32 22 95 118 19 18 43

75 2557 538 2572 352 265 727 6282

TABLE 7. Details of the web applications we study and details on various contexts used by these applications.

based sanitizers. Finally, we evaluate whether the level of expressiveness supported by web frameworks is sufficient to enforce the sanitization policy that applications presently use.

4.1. Subject Applications & Analysis Infrastructure Systematically studying large code bases requires an automatic analysis infrastructure. To limit our effort in building analysis infrastructure, we decided to focus on one language, namely PHP. We chose PHP because it is a popular web application language with over 20 million domains running PHP applications [45]. Our smallest subject application was over 19,000 lines of PHP code, while the largest was over half a million lines of code. Several of these applications, including PHPBB, WordPress and MediaWiki have been studied in previous research evaluations. Finally, we believe that these applications are widely used — for instance, MediaWiki is the framework behind Wikipedia. Analysis of PHP applications. We describe the analysis infrastructure we build for systematically studying PHP applications. It provides two primary features: automatic extraction of sanitizers (as defined by Definition 2 in Section 2) and inference of contexts in which untrusted data is embedded by applications. PHP is a highly dynamic, interpreted language. PHP has dynamic types, dynamically dispatched functions, invocations through dynamic arrays, and variable argument functions, which are challenging for static analysis. Notably, Facebook’s HipHop PHP compiler and analyzer provides a level of type inference support [26], but the analysis is generally imprecise, unable to infer types across function calls. Though previous research has had success in automatic extraction of sanitizers in statically typed languages [37], these are not directly usable in our study of PHP because they operate on the assumption of having (a priori) inter-procedural dataflow graphs. As a result, our entire analysis infrastructure relies on dynamic analysis. To drive the analysis infrastructure, we used a combination of automated blackbox fuzzing and manual interaction with the applications. Specifically, we built a PHP fuzzer that (a) systematically invokes all the PHP files in each application,

(b) identifies all uses of GET, POST, and COOKIE input parameters, and (c) re-executes each file with random values for the newly identified inputs found in step (b). PHP functionality that was not properly explored using this mechanism was subject to addition manual interaction as well. We found a large number of distinct sinks containing untrusted data in our analysis, which we summarize in Table 7. Extracting Sanitizers. Using dynamic analysis, we identify sets of sanitizers in web applications. We check the input and output of each function call that an application makes in a dynamic run. We use Definition 2 in Section 2.3 to identify sanitizer functions, and we identify sanitizers that provide HTML context chain safety, as per Definition 4. For each dynamically executed path in the application, we extract all of the called functions with at least one string argument. We fork execution of the PHP engine, replacing the string arguments with an XSS attack vector known to cause JavaScript execution in a large number of HTML contexts [25]. The modified PHP engine logs the argument values and the return values for all such function calls. From these logs, we extract all the function calls that both took an attack vector as an argument and returned a string. By Definition 2, these functions are sanitizers. However, we want to approximate the fact that these are sanitizers that provide HTML context chain safety as per Definition 4. Thus, we pass the return values of the sanitizers through an edit distance algorithm, comparing the attack vector string to the function’s return value. We negate the effects of standard encoding functions like htmlentities before running the edit distance algorithm. If the edit distance is small, we mark the function as a sanitizer. While there are pathological cases in which our algorithm would fail, we manually evaluated the output of the algorithm for Wordpress and MediaWiki and found that the algorithm had very few false positives. At worst, the number of sanitizers we find is an undercount of the actual number of sanitizers in the web application. Context Inference. Our aim is to identify the context in which an untrusted input was embedded. To define untrusted data, we use the intuition that sanitized input data is very likely untrusted. Taking the list of extracted sanitizers for a particular web application, we instrument the sanitizers in the

application to surround untrusted data with a special identifier markup. We feed all GET, POST and COOKIE inputs a specific key string, so that the instrumentation in the sanitizers can distinguish untrusted inputs from other internal data. We use techniques similar to taint-inference [52] to identify where untrusted inputs are embedded in output. Finally, we log all web application output for context inference. We use a modified Python HTML5 parser to parse the application output. While parsing, we search all contexts for the special identifying markup. When found, we record the context the parser is in. We repeat this until the document is completely parsed. When it is finished, we have a list of all contexts where the key string appeared as well as which sanitizers it went through. We present the contexts we found in Table 7.

4.2. Evaluating Sanitization Practices We manually evaluated whether these applications predominantly use whitelisting sanitizers or blacklisting. Note that our goal is not to check whether sanitizers in these applications were correct, but only to illustrate what security-conscious applications are employing as a defense strategy. We observed that the number of sanitizers varied from 18 to 119, which is much larger than the number of contexts we encountered. On inspection, we did not find any duplication – this implies that applications have multiple sanitizers applied even for the same contexts. We characterize this variation in sanitizer choice in Section 4.4. To the extent of our analysis, we observe that the common pattern of sanitization in the PHP applications is the whitelist based canonicalization policy that we discussed previously. The applications commonly allow only a whitelist of contextspecific syntactic constructs. Example 1 WordPress allows fairly expressive HTML constructs in untrusted user content. Users can place comments on blog posts, and these comments can contain some HTML tags with HTML tag attributes for a more rich editing experience. Of course, WordPress applies a variety of sanitizers to this content to ensure its safety. However, WordPress’s sanitizers are a set of filters that take a whitelist of allowed tags, attributes, protocols, or a number of other options depending on the sanitization context, and ensure that nothing off the whitelist is syntactically present. These filters are sufficient for WordPress, and we see similar implementations in the other applications. Evaluation Summary. We find that primarily all of the applications use a whitelisting-based canonicalization strategy for the HTML tag context, as discussed earlier in Section 2.5. For instance, we find that the kses library used in WordPress and Drupal, the HTMLPurifier library used in Moodle and the PHPInputFilter library used in Joomla all employ this strategy.

4.3. Evaluating Usage of Contexts As Table 7 shows, the various output contexts where we observed untrusted user input is fairly small. For instance, in MediaWiki, a user may create or edit a wiki entry. Their new text passes through sanitizers and a database but eventually flows to the HTML context of the output in that particular wiki article. Thus, in the table, the “HTML” column is marked for MediaWiki because it allows untrusted content in the HTML tag content context. The listed contexts are as follows: • HTML tag content: The basic HTML content context between two tags. Note, however, that this does not include the content between script tags. Content between script tags is a separate JavaScript context because the JavaScript, not HTML, parser is applied to it • URL: A context where a URL is expected, such as an anchor tag href attribute or an image tag src attribute. This also includes the document schema. • JS String: A JavaScript context where data appears within a quoted JavaScript string. For example, if the program places a user name inside a JavaScript string to add to a DOM text node. • Attr: A non-URL HTML attribute context, such as the name attribute or the alt attribute. Evaluation Summary. To the extent of our analysis, we find that the set of contexts in use by web applications matches well with the expressiveness supported by the most expressive web frameworks and previous research [59]. This implies that, in principle if the Ctemplate framework were available for PHP, its context support would be empirically sufficient for all the applications we study. Another interesting point is that applications do not emit data in HTML contexts that are inherently hard to secure. For example, we did not find any untrusted content flows to the general, non-string JavaScript context. Similarly, all the applications refrained from embedding untrusted data in unquoted HTML attributes, which are hard to sanitize due to browser variation and a large set of attack vectors.

4.4. Evaluating Expressiveness of Sanitization Policies As we observe in Table 7, there is more than one sanitizer for each embedding context. This implies that each web application may sanitize different fragments of untrusted data in a different way based on its security policy. This notion of “picking a sanitizer” for each fragment of untrusted data before outputting it to the HTTP response is what we formulate as a sanitization policy function below. Definition 5: (Sanitization Policy Function) The application’s sanitization policy function ψ is an n-ary function ψ : (I1 , I2 , . . . In ) → S ∗

where S is the set of sanitizers in the application and I1 , . . . , In are application-specific policy attributes. Note that the sanitization policy function returns an ordered list of sanitizers to apply, and could even return with an empty list. One of our goals is to identify what the policy attributes are for real applications, how much they vary across applications and how complex they may be. We argue that the larger the n, the more complex the decision for picking a sanitizer. We find that an application’s sanitization policy can be very complex. Specifically, how an application selects a sanitizer can be more complex than simply looking at the syntactic context. This real-world example from the Drupal application illustrates the complexity. Example 2 In the content management system Drupal, one of the default behaviors is the ability to post and reply to comments on a page. By default, any logged in user can do this, but one may enable it for “anonymous” (not logged in) users as well. When the user creates or replies to a post, the application presents a choice of HTML filters to apply to their post. The set of roles assigned to a user by the system administrator determines the choice of filters presented to the user. By default, “authenticated user” is the sole role of a logged in user, but the administrator may assign an arbitrary number of roles. Similarly, the program assigns the “anonymous user” role to anonymous users. An administrator may assign HTML filters to each role. By default, the “authenticated user” role is only assigned the “Full HTML” filter that filters out all HTML control structures. However, the administrator can create arbitrary HTML filter policies and assign them to various roles. Thus, the administrator can apply the “Full HTML” filter to all users by default, but explicitly allow trusted users to post comments with links in HTML anchor tags. The administrator is not governed by roles and is always allowed to post arbitrary HTML.Thus, when a logged in user is posting a comment or a reply, a different sanitization function may be applied to her post based on her role. If she is an administrator, the program will not apply a filter, but if she is in a different role, the program may apply a restrictive filter. Thus, context alone does not define the arity of the sanitization function policy. In this case, the role of the logged-in user increases the arity. That is, not just the context determines the sanitizer to apply (a comment or reply HTML context in this case) but also on the user’s role. However, in this instance, it is even more complicated, because the user may select any of the valid filters assigned by her roles. For example, if the user is both a trusted user for posting links and, separately, a trusted user for posting images, she may choose which filter (either the link or image filter) applies to her post. Therefore, the arity of the Drupal sanitization function policy again increases because user selection is also a deciding factor in sanitization function application.

Evaluation Summary. We find that sanitization policy functions are implicit in today’s web application code. Specifically, we found that for many applications, sanitizer selection is more complex than simply looking at the syntactic HTML context, which is the functionality of the default auto-sanitization protections enabled in those web frameworks that support context-sensitive auto-sanitization. This implies that the sanitization policy functions are definitely beyond 0-ary functions (as context-insensitive auto-sanitization assumes), or unary functions (as assumed by context-sensitive auto-sanitization). We have found several variations in policy functions in implicit use by these applications. One common sanitization policy attribute observed is that of role-based sanitization, where the application applies different sanity checks based on the privilege of the content. Drupal’s variations in sanitizers applied based on the user’s role is perhaps an extreme. Other simpler policies we observe are where the site administrator’s content is not subject to sanitization (by design), as in the case of PHPBB3. For such simple policies, there are legitimate code paths which have no sanitization requirements. Sanitization policies have a direct impact on the security offered by web frameworks. If a framework does not recognize and support the intended security model of the application, it cannot ensure that the sanitization is consistently applied in the application. Presently, this represents a gap between the expressiveness of the abstractions supported by web frameworks and what web applications require and implement.

5. Results and Findings In this study, we characterized the nature of XSS sanitization. Using a formal notion of XSS sanitization allowed us to systematically investigate and contrast the nature of XSS sanitization in applications and frameworks. The following are some of our key findings: 1) Only 3 out of the 13 frameworks studied support all the contexts that complex web applications employ (Tables 4 and 7). 2) Many existing frameworks that provide auto-sanitization perform context-insensitive sanitization. With multiple examples, we demonstrated that context-insensitive sanitization can give a false sense of security. We also find that replacing auto-sanitization with the use of a manual sanitizer is not uncommon. 3) Newer frameworks support simple templating mechanisms for identifying untrusted data, defaulting to a fail-closed design. Such mechanisms put the burden of trusted data identification on the developer. 4) We find that context-sensitive sanitization is the norm across complex web applications. 5) Across frameworks and applications, the approach to sanitization generally adopted is whitelisting. Developers identified a subset of HTML that is sufficiently expressive for their needs. Variance in browser implementation does not seem to be a factor in any of the sanitizers we observed.

6) Many web applications employ a set of sanitizers much larger that the set of contexts they support. 7) We also find that the decision to pick a sanitizer is not a simple zero- or single-arity function; fine grained data attributes (e.g., is the source of the data an administrator?) along with application configuration often dictate the sanitizer picked for a particular flow. 8) None of the web frameworks we studied support the complex sanitization policies we observed in real world web applications. It is not clear to us why such a large number of sanitizer functions are employed by web applications. We conjecture that in the absence of easy correctness arguments for sanitizers, applications err on the side of caution. Simple and practical mechanisms for correctness guarantees of sanitizers and sanitizer policies deserve research attention. The complete absence of support for complex multi-arity sanitizer policy in frameworks was also salient. We believe that the next generation of frameworks need to address this issue to achieve adoption by complex web applications — our notion of sanitization policy function is one possible abstraction that newer frameworks could employ.

6. Related Work Cross-site scripting defense techniques have received a great deal of attention in research. XSS Analysis and Defense. Much of the research on crosssite scripting vulnerabilities has focused on finding XSS flaws in web applications, specifically on server-side code [5, 31, 33, 35, 36, 39, 43, 63, 65] but also more recently on JavaScript code [6, 23, 48, 49]. These works have underscored the two main causes of XSS vulnerabilities: identifying untrusted data at output and errors in sanitization by applications. There have been three kinds of defenses: purely server-side, purely browser-based, and those involving both client and server collaboration. BLUEPRINT [59], SCRIPTGARD [50] and XSSGUARD [11] are two server-side solutions that have provided insight into context-sensitive sanitization. In particular, BLUEPRINT provides a deeper model of the web browser and points to paths between the browser components may vary across browsers. The browser model detailed in this work builds upon BLUEPRINT’s model and more closely upon SCRIPTGARD’s formalization. We provide additional details in our model to demystify the browser’s parsing behavior and explain subtleties in sanitization which the prior work did not address. Purely browser-based solutions, such as XSSAuditor, and client-only solutions, such as DSI, are implemented in modern browsers. These mechanisms are useful in nullifying common attack scenarios by observing HTTP requests and intercepting HTTP responses during the browser’s parsing. However, they do not address the problem of separating untrusted from trusted data, as pointed out by Barth et al. [10]. Other

language-based solutions for customizable XSS security policies are also an area of active research [41]. Research shows that cross-site scripting attacks sometimes results from unsafe parsing of CSS [30], optimistic content-sniffing algorithms in browsers [7], and from vulnerabilities in extensions [6, 9]. Failure to isolate mashups and advertisements may also result in code injection vulnerabilities, but typically the safety properties that these attacks violate are treated as a separate class From XSS vulnerabilities. These violated properties include isolation of principles in web browser primitives [61], authority safety [38] and statically verified containment [22]. BEEP, DSI and NonceSpaces investigated client-server collaborative defenses. In these proposals, the server is responsible for identifying untrusted data which it reports to the browser, and a modified browser ensures that XSS attacks can not result from parsing the untrusted data. While these proposals are encouraging, they require updates in browser implementations as well as server-side code. The closest practical implementation of such client-server defense architecture is the recent content security policy specification [55]. Correctness of Sanitization. While several systems have analyzed server-side code, the SANER [5] system empirically showed that custom sanitization routines in web applications can be error-prone. FLAX [49] and KUDZU [48] empirically showed that sanitization errors are not uncommon in clientside JavaScript code. While these works highlight examples, the complexity of the sanitization process remained unexplained. Our observation is that sanitization is pervasively used in emerging web frameworks as well as large, security-conscious applications. We discuss whether applications should use sanitization for defense in light of previous bugs. Among server-side defenses, BLUEPRINT provided a sanitization-free strategy for preventing cross-site scripting attacks, which involved the explicit construction of the intended parse tree in the browser via JavaScript. We observe that sanitization-free mechanisms stand in contrast to whitelistbased canonicalization sanitization which is what is generally implemented in emerging frameworks, the security of which has neither been fundamentally broken nor proven. Research on string analysis and other automata-based verification systems is currently active, and this research is directly relevant to these questions [27, 34, 48]. Techniques for Separating Untrusted Content. Tainttracking based techniques aimed to address the problem of identifying and separating untrusted data from HTML output to ensure that untrusted data gets sanitized before it is output [14, 33, 43, 51, 60, 65]. Challenges in implementing taintanalysis as well as performance overheads have precluded their use in deployed web applications. Security-typed languages and type-systems offer another mechanism to ensure the robust isolation of untrusted data from HTML code output [15, 46, 53, 57]. The generality of type systems allows for creating a finer separation between untrusted inputs, a property we motivate with our empirical analysis. HTML templating engines, such

as those studied in this work, offer a different model in which they coerce developers into explicitly specifying trusted content. This offers a fail-closed design and has seen adoption in practice because of its ease of use.

References [1] G. Aas. CPAN: URI::Escape. http://search.cpan.org/∼ gaas/URI-1.56/ URI/Escape.pm. [2] Adsafe : Making javascript safe for advertising. http://www.adsafe.org/. [3] How To: Prevent Cross-Site Scripting in ASP.NET. http://msdn. microsoft.com/en-us/library/ff649310.aspx. [4] Microsoft ASP.NET: Request Validation – Preventing Script Attacks. http://www.asp.net/LEARN/whitepapers/request-validation. [5] D. Balzarotti, M. Cova, V. Felmetsger, N. Jovanovic, E. Kirda, C. Kruegel, and G. Vigna. Saner: Composing Static and Dynamic Analysis to Validate Sanitization in Web Applications. In Proceedings of the IEEE Symposium on Security and Privacy, Oakland, CA, May 2008. [6] S. Bandhakavi, S. T. King, P. Madhusudan, and M. Winslett. Vex: Vetting browser extensions for security vulnerabilities, 2010. [7] A. Barth, J. Caballero, and D. Song. Secure content sniffing for web browsers, or how to stop papers from reviewing themselves. In Proceedings of the 30th IEEE Symposium on Security and Privacy, pages 360–371, Washington, DC, USA, 2009. IEEE Computer Society. [8] A. Barth, A. P. Felt, P. Saxena, and A. Boodman. Protecting browsers from extension vulnerabilities, 2009. [9] A. Barth, A. P. Felt, P. Saxena, and A. Boodman. Protecting browsers from extension vulnerabilities, 2010. [10] D. Bates, A. Barth, and C. Jackson. Regular expressions considered harmful in client-side xss filters. In Proceedings of the 19th international conference on World wide web, WWW ’10, pages 91–100, New York, NY, USA, 2010. ACM. [11] P. Bisht and V. N. Venkatakrishnan. Xss-guard: Precise dynamic prevention of cross-site scripting attacks. In Proceedings of the 5th international conference on Detection of Intrusions and Malware, and Vulnerability Assessment, DIMVA ’08, pages 23–43, Berlin, Heidelberg, 2008. Springer-Verlag. [12] google-caja a source-to-source translator for securing javascript-based web content. http://code.google.com/p/google-caja/. [13] CakePHP: Sanitize Class Info. http://api.cakephp.org/class/sanitize. [14] E. Chin and D. Wagner. Efficient character-level taint tracking for java. In Proceedings of the 2009 ACM workshop on Secure web services, SWS ’09, pages 3–12, New York, NY, USA, 2009. ACM. [15] S. Chong, J. Liu, A. C. Myers, X. Qi, K. Vikram, L. Zheng, and X. Zheng. Secure web applications via automatic partitioning. In Proceedings of twenty-first ACM SIGOPS Symposium on Operating systems principles, pages 31–44, New York, NY, USA, 2007. ACM. [16] ClearSilver: Template Filters. http://www.clearsilver.net/docs/man filters.hdf. [17] CodeIgniter/system/libraries/Security.php. http://bitbucket.org/ellislab/ codeigniter/src/tip/system/libraries/Security.php. [18] CodeIgniter User Guide Version 1.7.2: Input Class. http://codeigniter. com/user guide/libraries/input.html. [19] Ctemplate: Guide to Using Auto Escape. http://google-ctemplate. googlecode.com/svn/trunk/doc/auto escape.html. [20] django: Built-in template tags and filters. http://docs.djangoproject.com/ en/dev/ref/templates/builtins. [21] Django sites : Websites powered by django. http://www.djangosites.org/. [22] M. Finifter, J. Weinberger, and A. Barth. Preventing capability leaks in secure javascript subsets. In Proc. of Network and Distributed System Security Symposium, 2010. [23] A. Guha, S. Krishnamurthi, and T. Jim. Using static analysis for ajax intrusion detection. In Proceedings of the 18th international conference on World wide web, WWW ’09, pages 561–570, New York, NY, USA, 2009. ACM.

[24] Google Web Toolkit: Developer’s Guide – SafeHtml. http://code.google. com/webtoolkit/doc/latest/DevGuideSecuritySafeHtml.html. [25] G. Heyes. One vector to rule them all. http://www.thespanner.co.uk/ 2010/09/15/one-vector-to-rule-them-all. [26] HipHop for PHP. http://github.com/facebook/hiphop-php/wiki. [27] P. Hooimeijer and W. Weimer. A decision procedure for subset constraints over regular languages. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), pages 188– 198, June 2009. [28] PHP Manual : html entity decode. http://php.net/manual/en/function. html-entity-decode.php. [29] HTML Purifier : Standards-Compliant HTML Filtering. http:// htmlpurifier.org/. [30] L.-S. Huang, Z. Weinberg, C. Evans, and C. Jackson. Protecting browsers from cross-origin css attacks. In ACM Conference on Computer and Communications Security, 2010. [31] Y.-W. Huang, F. Yu, C. Hang, C.-H. Tsai, D.-T. Lee, and S.-Y. Kuo. Securing web application code by static analysis and runtime protection. In Proceedings of the 13th international conference on World Wide Web, WWW ’04, pages 40–52, New York, NY, USA, 2004. ACM. [32] JiftyManual. http://jifty.org/view/JiftyManual. [33] N. Jovanovic, C. Kr¨ugel, and E. Kirda. Pixy: A static analysis tool for detecting web application vulnerabilities (short paper). In IEEE Symposium on Security and Privacy, 2006. [34] A. Kie˙zun, V. Ganesh, P. J. Guo, P. Hooimeijer, and M. D. Ernst. HAMPI: A solver for string constraints. In International Symposium on Software Testing and Analysis, 2009. [35] B. Livshits and M. S. Lam. Finding security errors in Java programs with static analysis. In Proceedings of the Usenix Security Symposium, 2005. [36] B. Livshits, M. Martin, and M. S. Lam. SecuriFly: Runtime protection and recovery from Web application vulnerabilities. Technical report, Stanford University, Sept. 2006. [37] B. Livshits, A. Nori, S. Rajamani, and A. Banerjee. Merlin: Specification inference for explicit information flow problems. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), June 2009. [38] S. Maffeis, J. C. Mitchell, and A. Taly. Object capabilities and isolation of untrusted web applications. In Proceedings of the 2010 IEEE Symposium on Security and Privacy, pages 125–140, Washington, DC, USA, 2010. IEEE Computer Society. [39] M. Martin and M. S. Lam. Automatic generation of XSS and SQL injection attacks with goal-directed model checking. In 17th USENIX Security Symposium, 2008. [40] The Mason Book: Escaping Substitutions. http://www.masonbook.com/ book/chapter-2.mhtml. [41] L. Meyerovich and B. Livshits. ConScript: Specifying and enforcing fine-grained security policies for JavaScript in the browser. In IEEE Symposium on Security and Privacy, May 2010. [42] Y. Nadji, P. Saxena, and D. Song. Document structure integrity: A robust basis for cross-site scripting defense. Proceedings of the 16th Network and Distributed System Security Symposium, 2009. [43] A. Nguyen-Tuong, S. Guarnieri, D. Greene, J. Shirley, and D. Evans. Automatically hardening web applications using precise tainting. 20th IFIP International Information Security Conference, 2005. [44] XSS Prevention Cheat Sheet. http://www.owasp.org/index.php/XSS (Cross Site Scripting) Prevention Cheat Sheet. [45] PHP usage statistics. http://www.php.net/usage.php. [46] W. Robertson and G. Vigna. Static enforcement of web application integrity through strong typing. In Proceedings of the 18th conference on USENIX security symposium, SSYM’09, pages 283–298, Berkeley, CA, USA, 2009. USENIX Association. [47] Ruby on Rails Security Guide. http://guides.rubyonrails.org/security. html. [48] P. Saxena, D. Akhawe, S. Hanna, F. Mao, S. McCamant, and D. Song. A symbolic execution framework for javascript. In Proceedings of the 2010 IEEE Symposium on Security and Privacy, SP ’10, pages 513–528, Washington, DC, USA, 2010. IEEE Computer Society. [49] P. Saxena, S. Hanna, P. Poosankam, and D. Song. FLAX: Systematic dis-

[50]

[51]

[52] [53] [54] [55] [56]

[57]

[58] [59]

[60] [61]

[62]

[63]

[64] [65]

[66] [67]

covery of client-side validation vulnerabilities in rich web applications. In 17th Annual Network & Distributed System Security Symposium, (NDSS), 2010. P. Saxena, D. Molnar, and B. Livshits. Scriptgard: Preventing script injection attacks in legacy web applications with automatic sanitization. Technical report, Microsoft Research, September 2010. E. J. Schwartz, T. Avgerinos, and D. Brumley. All you ever wanted to know about dynamic taint analysis and forward symbolic execution (but might have been afraid to ask). In Proceedings of the 2010 IEEE Symposium on Security and Privacy, SP ’10, pages 317–331, Washington, DC, USA, 2010. IEEE Computer Society. R. Sekar. An efficient black-box technique for defeating web application attacks. In NDSS, 2009. J. Seo and M. S. Lam. Invisitype: Object-oriented security policies, 2010. Smarty Template Engine: escape. http://www.smarty.net/manual/en/ language.modifier.escape.php. S. Stamm. Content security policy, 2009. Z. Su and G. Wassermann. The essence of command injection attacks in web applications. In Conference record of the 33rd ACM SIGPLANSIGACT symposium on Principles of programming languages, POPL ’06, pages 372–382, New York, NY, USA, 2006. ACM. N. Swamy, B. Corcoran, and M. Hicks. Fable: A language for enforcing user-defined security policies. In Proceedings of the IEEE Symposium on Security and Privacy (Oakland), May 2008. Template::Manual::Filters. http://template-toolkit.org/docs/manual/ Filters.html. Ter Louw, Mike and V.N. Venkatakrishnan. BluePrint: Robust Prevention of Cross-site Scripting Attacks for Existing Browsers. In Proceedings of the IEEE Symposium on Security and Privacy, 2009. W. Venema. Taint support for PHP. ftp://ftp.porcupine.org/pub/php/php5.2.3-taint-20071103.README.html, 2007. H. J. Wang, X. Fan, J. Howell, and C. Jackson. Protection and communication abstractions for web browsers in mashupos. In Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles, SOSP ’07, pages 1–16, New York, NY, USA, 2007. ACM. G. Wassermann and Z. Su. Sound and precise analysis of web applications for injection vulnerabilities. In Proceedings of the ACM SIGPLAN conference on Programming language design and implementation, pages 32–41, New York, NY, USA, 2007. ACM. Y. Xie and A. Aiken. Static detection of security vulnerabilities in scripting languages. In Proceedings of the Usenix Security Symposium, 2006. xssterminate. http://code.google.com/p/xssterminate/. W. Xu, S. Bhatkar, and R. Sekar. Taint-enhanced policy enforcement: A practical approach to defeat a wide range of attacks. In Proceedings of the 15th USENIX Security Symposium, pages 121–136, 2006. Yii Framework: Security. http://www.yiiframework.com/doc/guide/1.1/ en/topics.security. Zend Framework: Zend Filter. http://framework.zend.com/manual/en/ zend.filter.set.html.