Ajax and Mashup Security (original) (raw)

Home

Abstract

The OpenAjax Alliance has assembled a set of white papers as a guide to help Web developers and IT managers understand and evaluate Ajax, define a successful Ajax strategy, and become familiar the important role OpenAjax plays in the development of the Ajax market.

The white papers are:

• Introducing Ajax and OpenAjax
• When Does Ajax Make Business Sense
• Next-Generation Applications Using Ajax and OpenAjax
• Successful Deployment of Ajax and OpenAjax
• Ajax and Mashup Security (this document)
• Introduction to Mobile Ajax for Developers
• [ Good News for Ajax - The Browser Wars Are Back](/whitepapers/Good News for Ajax - Browser Wars Are Back.php "Good News for Ajax - The Browser Wars Are Back")
• [ Introducing OpenAjax Hub 2.0 and Secure Mashups](/whitepapers/Introducing OpenAjax Hub 2.0 and Secure Mashups.php "Introducing OpenAjax Hub 2.0 and Secure Mashups")
• [ OpenAjax Hub 2.0 and Mashup Assembly Applications](/whitepapers/OpenAjax Hub 2.0 and Mashup Assembly Applications.php "OpenAjax Hub 2.0 and Mashup Assembly Applications
  ")

Contents

• 1 Introducing Ajax and Mashups
  • 1.1 Ajax
  • 1.2 Mashups
• 2 Understanding the Same-Origin Policy
  • 2.1 Avoiding the Same-Origin Policy: JSON and the Dynamic Script Tag
  • 2.2 Avoiding the Same-Origin Policy: Ajax Proxy
  • 2.3 Avoiding the Same-Origin Policy: Browser Extensions and Plugins
• 3 Examining Attack Scenarios
  • 3.1 Cross-Site Scripting (XSS)
  • 3.2 Cross-Site Request Forgeries (CSRF) and JSON Hijacking
  • 3.3 Denial of Service (DoS) Attacks
  • 3.4 Mashups Attack Opportunities
• 4 Understanding the Effect of Attacks
  • 4.1 Stealing Cookies or Passwords
  • 4.2 Stealing Keyboard Events with a Key Logger
  • 4.3 Stealing Keyboard Events with a Mouse Sniffer
  • 4.4 Inserting Wrong Information
  • 4.5 Stealing JSONP Messages
  • 4.6 Stealing JSON Messages by JSON Hijacking
• 5 Recommended Best Practices
  • 5.1 Add an Input Value Check
  • 5.2 Use Vulnerability Checking Tools
  • 5.3 Don't Generate and Execute Code Dynamically
  • 5.4 Don't Insert Untrusted HTML Content Without Sanitizing
  • 5.5 Preventing CSRF Attacks
  • 5.6 Secure the Use of JSON
  • 5.7 Preventing JSON Hijacking Attacks
  • 5.8 Use When Integrating Distrusted Contents
• 6 Conclusions
• 7 Resources
• 8 Notes

1 Introducing Ajax and Mashups

Ajax and mashups represent two new Web application development approaches that both fit under the Web 2.0 umbrella.

1.1 Ajax

Asynchronous JavaScript + XML (Ajax) [1]allows user interaction with Web pages to be decoupled from the Web browser's communication with the server. In particular, Ajax drives mashups, which integrate disparate content or services into a single user experience. However, Ajax and mashup technology introduce new types of threats because of their dynamic and multidomain nature. It is important to understand these threats and to avoid them by adhering to some best practices.

Ajax is built on Dynamic HTML (DHTML) technologies, including these most common ones:

• JavaScript: JavaScript is a scripting language commonly used in client-side Web applications.
• Document Object Model (DOM): DOM is a standard object model for representing HTML or XML documents. Most of today's browsers support DOM and allow JavaScript code to use DOM to read and modify the HTML content dynamically.
• Cascading Style Sheets (CSS): CSS is a stylesheet language used to describe the presentation of HTML documents. JavaScript can modify a stylesheet at run time, allowing the presentation of the Web page to update dynamically.

In Ajax, client-side JavaScript updates the presentation of a Web page by dynamically modifying the DOM tree and the stylesheet. In addition, asynchronous communication, enabled by the following technologies, allows dynamic updates of data without the need to reload the entire Web page:

• XMLHttpRequest : XMLHttpRequest is an API that allows client-side JavaScript to make HTTP connections to remote servers and to exchange data, such as plain text, XML, or JavaScript Serialized Object Notation (JSON).
• JSON: JSON, as proposed by Request for Comments (RFC) 4627 [2]of the Internet Engineering Task Force (IETF), is a lightweight, text-based, language-independent, data-interchange format. It's based on a subset of the ECMAScript language (making it part of the JavaScript language), and it defines a small set of formatting rules to create a portable representation of structured data.

Note that there are other commonly used alternatives to JSON in Ajax applications, such as XML and unformatted plain text. We chose to discuss JSON here, since it has some security implications that we'll examine later in this article.

Readers who are not familiar with Ajax are encouraged to read the articles in the OpenAjax Alliance Ajax's Security Resources wiki page.

1.2 Mashups

A mashup is a website or application that combines content from more than one source into an integrated experience. Usually, the mashup components interact with each other. In the classic example of a mashup, a Craigslist component is combined with a mapping component (e.g., Google or Yahoo maps) such that when a user clicks on a new Craigslist entry, the mapping component updates its view to show the new address.

Mashups typically allow the end user to discover and integrate third party, Ajax-powered mashup components onto the mashup's canvas. Examples in the consumer social networking space include Facebook Widgets and MySpace Widgets, which end users can discover and insert into their pages.

From a technology perspective, mashup components represent Ajax-powered "mini applications" that are assembled into an Ajax-powered mashup container application that provides a framework for the components to communicate with each other. Sometimes the mashup container application enables cross-site communications by providing proxy services to allow server-side redirection to Web servers that are associated with a given mashup component.

2 Understanding the Same-Origin Policy

One of the foundations of Web security is the "same-origin" policy that is implemented by all popular Web browsers. Browsers implement the same-origin policy as a protection mechanism in order to isolate Web applications coming from different domains from each other, under an assumption that different domains represent different originators. As a result, if applications in multiple windows or frames are downloaded from different servers, they will not be able to access each other's data and scripts.

Note that the same-origin policy only applies to HTML documents. Resource files, such as JavaScript files and images, can be imported into an HTML document (e.g., <script src="..." >) from other domains, but operate within the context of the host HTML document and are regarded as part of the same-origin as the HTML document.

In the context of XMLHttpRequest, the same-origin policy is intended to control an application's interaction with remote servers. However, the same-origin policy has only limited impact on Web 2.0 applications for several reasons:

• You can bypass the same-origin policy in many ways: We will illustrate some of these ways later in the article.
• A major characteristic of Web 2.0 applications is the users' contribution to the content: That is, the content is usually not provided by a trusted service but often rather by anonymous users through blogs, wikis, and so on. Therefore, even the contents from a single server can actually come from multiple sources.
• Browsers enforcing the same-origin policy check the domain name of the server as a string literal: For example, http://www.abc.com/ and http://12.34.56.78/ are treated as different domains even if the IP address of www.abc.com is actually 12.34.56.78. In addition, any path expression of the URL is ignored. For example, http://www.abc.com/~alice is identified as the same-origin as http://www.abc.com/~malroy, ignoring the fact that both directories probably belong to different users.
• Most Web browsers allow a Web application to relax its domain definition to the super domain of the application itself: For example, if the application is downloaded from www.abc.com, the application can override the document.domain property to abc.com or just com (in case of Firefox). Most of the latest browsers only allow access to window objects between windows or frames that have overridden their document.domain property to the same value. However, some older versions of browsers allow making XMLHttpRequest connections to the domain specified by the document.domain property.
• Even if a Web server is in the trusted domain, it might not be the originator of the contents, especially in the context of Web 2.0: For example, an enterprise portal server, Web-based mail server, or wiki may be trusted, but the contents they're hosting may include input from potentially malicious third parties, which could be the target of cross-site scripting (XSS) attacks (which we'll describe later). Therefore, the domains of the servers don't represent trustworthiness of the contents.

2.1 Avoiding the Same-Origin Policy: JSON and the Dynamic Script Tag

Since JSON is just plain text with a simple bracketed structure, many channels can exchange a JSON message. Because of the same-origin policy, you cannot use XMLHttpRequest when communicating with external servers. JSON with Padding (JSONP) [3]is a way to bypass the same-origin policy by using JSON in combination with the <script> tag, as shown in Listing 1:

Listing 1. JSON example