Understanding Ajax vulnerabilities

Protect the web applications you create with Ajax

Asynchronous JavaScript + XML (Ajax) is not a web technology; it is a collection of technologies created specifically to build dynamic web applications. Because of its range of functions and ease of use, Ajax is one of the most widely used tools for building web applications today. All applications, including those built using Ajax technologies, are vulnerable to exploits that compromise websites and the databases that drive them. In this article, learn about some of the threats to Ajax technologies and how to guard against them.

Share:

Jeffrey Orloff (jeff.orloff@gmail.com), Freelance Technology Writer

Jeff is a freelance technology writer who also works as a technology coordinator with the School District of Palm Beach County, Florida. Throughout his career he has worked with web technologies specializing in security. He has served as the Director of Technology for SafeWave, a Security Evangelist for Applicure Technologies, and as the editor of Developer Drive, a blog dedicated to website development tutorials.


developerWorks Contributing author
        level

01 May 2012

Also available in Chinese Russian Japanese

Introduction

Frequently used acronyms

  • Ajax: Asynchronous JavaScript + XML
  • CSS: Cascading style sheet
  • DOM: Document Object Model
  • HTML: Hypertext Markup Language
  • JSON: JavaScript Object Notation
  • SQL: Structured Query Language
  • UI: User interface
  • XML: Extensible Markup Language
  • XSS: Cross-site scripting

Ajax has boomed in popularity with web developers because it:

  • Has the ability to create robust web applications that data-driven websites rely upon
  • Is meant to increase the speed and usability of websites

However, the "technology" that many web developers rely on to make their web-based applications imitate traditional desktop applications isn't really a technology at all. Ajax is a collection of technologies, with each technology playing an important role in the finished product. Table 1 shows the technologies included in Ajax.

Table 1. Technologies used in Ajax
TechnologyUse
JavaScriptThe scripting language that enables all of the technologies to work together.
XMLThe markup language that allows data to be transferred, manipulated, and exchanged between the server and client.
HTML and CSSThe technologies that allow for the design of the UI and presentation of the application.
DOMThe technology that drives the dynamic display of content and interaction with the data.

The things that attract web developers to Ajax also present the biggest threats to its security. Most security experts agree that web applications are a large target for cyber criminals, but web security generally constitutes only a small portion of an organization's security budget. Because Ajax is used to develop many of the applications you see on the web, its popularity makes it a target for attackers looking for vulnerabilities in the JavaScript code.

The entire point of Ajax's existence is to create data-driven websites. But attackers aren't attracted to Ajax only for its use as a web application development tool. Because data—be it financial, personal, or confidential—is the golden fleece of online commodities, Ajax again finds itself a focus of cyber criminals.

In this article, explore some common vulnerabilities and threats to Ajax security, including browser-based attacks, SQL injections, XSS, and Ajax bridging, and learn some preventive measures you can take to protect against attacks.


Know the types of attacks

Ajax security: Behind the numbers

Determining the number of web applications created using Ajax would be impossible. Because Ajax is among the most popular choices for web application developers, however, I will hypothesize that among the 73% of web applications that have been admittedly compromised in the past 24 months:

  • 2,155 had known web application vulnerabilities
  • 83% had at least one serious vulnerability

Ajax plays into the equation rather heavily.

Vulnerabilities in JavaScript have created unwanted press for many companies. By attacking cross-site scripting (XSS) vulnerabilities, malicious hackers have obfuscated JavaScript code, which lets them steal session cookies from visitors to the sites. These cookies, which contain login information, allows the attackers to gain access to any of the victims' services tied into their various accounts.

The famous Samy worm actually started as a joke to gather more friends on a social networking site. The creator of the worm uploaded malicious code, through his profile, which:

  • Added anyone who visited his profile to their friend list
  • Wrote "Samy is my hero" at the bottom of the victims' profiles
  • Replicated itself to everyone on the victims' friend lists

Less than 24 hours after the first person fell victim, Samy had 1,000,000 friends and the site crashed.

Using Ajax doesn't put your website at any greater risk than if you used any other web technologies—especially if you know what the threats are. The rest of this article outlines some of the security vulnerabilities that you can anticipate and plan for in your development activities.


Browser-based attacks

JavaScript, which is a foundation of Ajax, is no stranger to malicious code. For a browser-based attack to work, malicious code must be able to exploit the web technology (in this case, JavaScript) and cause the browser itself to run the code the attacker wishes.

Simple examples of a browser-based attack occur when victims find their home page changed, or they are redirected to a different site when they enter a URL in their browser's address bar. Though annoying and troublesome, these examples are not the worst-case scenarios.

Many browser-based attacks are designed to prevent infected computers from noticing or to mitigate other attacks. Often, an attack on the victim's browser keeps them from accessing a malware removal site or signature file update using the web. Other threats include browser proxying and keystroke logging.

Preventive measures

Protecting yourself against browser-based attacks can be as easy as disabling Java™ technology, JavaScript, and Microsoft® ActiveX® controls. Doing so, however, prevents a great many web applications from running. Instead, you should keep operating system software, browser software, and antimalware software up to date. Also use a reputable firewall application and exercise caution when downloading files and visiting websites.


SQL injections

How can an SQL injection be a threat to Ajax? After all, there's no "S" in Ajax. Simply put, SQL injection poses a threat because Ajax runs on the client side. The server side of the web application still requires a database, and that means SQL.

SQL injections occur when the attacker inputs malicious code in a poorly developed area of a website, such as a form. If the site under attack is vulnerable, the entire contents of the database can be exposed. This method of attack was used when a password database was exposed and credit card data was stolen from an online payment system. More recently, the method was used to steal email addresses of fans from a popular entertainer's site. Though no money was stolen, spammers looking to spread malware under the guise of this entertainer's merchandise offers did use the addresses.

Mitigating against SQL injections in an application developed using Ajax is the same as for any other web technology. However, simply using JavaScript-based sanitation techniques is not enough to protect against this type of exploit. JavaScript runs on the client side rather than the server side where an SQL injection would take place.

Preventive measures

To protect your database when using Ajax, you must validate user input with validation occurring on the server side. Parameterized statements, or prepared statements, work to prevent SQL injections because values are not put directly into the database or SQL statement. Instead, a placeholder (also called a bind variable) is used and the values for the placeholder are provided through a separate API call.


Cross-site scripting

XSS is another example of an injection attack where malicious code is inserted into the application. Web applications vulnerable to XSS attacks include browser-side scripts like those common to Ajax. Usually, this type of vulnerability is exploited to pass malicious scripts to unsuspecting visitors to the website. These scripts are responsible for identity theft, stolen cookies, spying on visitors' web use, accessing confidential information, and even denial-of-service attacks.

A well-known XSS attack that made the news in 2010 involved a social messaging site. Started by a user called @Matsta, the attack caused JavaScript pop-ups to appear when viewers moused over the malicious message. Other XSS attacks against this site caused users to be redirected to a survey site or sites hosting inappropriate content.

Preventive measures

When developing with Ajax, take the following steps to protect against XSS vulnerabilities.

  • Ensure that JavaScript variables are quoted.
  • Employ JavaScript hex encoding.
  • Employ JavaScript Unicode encoding.
  • Avoid backslash encoding (\", \', or \\).
  • Use the JSON.parse or json2.js library to parse JSON.
  • Avoid parsing JSON with the eval() method, which executes any script included with the JSON.

Ajax bridging

Ajax applications are built to connect to the website on which they are hosted. As a security measure, an application from site A cannot connect to site B. However, many sites rely on third-party websites and data sources to create mash-ups. The Ajax service bridge was created to provide a web service, through a host, that acts as a proxy that forwards traffic between the JavaScript running on the browser and the third-party site. Using Ajax bridging, site A can now provide data or content to its visitors who come from site B.

Just as Ajax is not a specific technology but a collection of technologies, bridging is not a specific vulnerability. Ajax bridging increases the threat landscape by providing an additional avenue of attack for malicious hackers. Attacks such as XSS and SQL injections can be passed through the Ajax bridging service. Although site B might have done everything to protect its web application from threats accessible to its visitors, site A may be used to attack site B using the Ajax bridge that was overlooked.

Preventive measures

Avoiding the bridging vulnerability requires trust among sites that provide access to third parties using a bridge. You should also audit how the third-party sites access your website and scan for any vulnerabilities that can be exploited by bridging.


Conclusion

Ajax itself does not present any new or unique security vulnerabilities. Nor should it be considered less safe than any other method of developing web applications. In this article, you learned about some Ajax security vulnerabilities and threats as well as how to take corresponding preventive measures in your development activities.

Protecting against vulnerabilities should be a priority in the early development stages, when you're first planning your application. Frequent testing and scanning should be part of any organization's web security strategy.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Web development on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Web development
ArticleID=812629
ArticleTitle=Understanding Ajax vulnerabilities
publish-date=05012012