Fundamentally, there’s nothing terribly new about the problems posed by Asynchronous JavaScript and XML (AJAX) when it comes to security, we just need to apply some good old security principles to this new technology.

The problems occur because, unfortunately, there are an awful lot of devils hidden inside the details.

One major security challenge for AJAX applications is that moving your code to the client involves a ton of data formats, protocols, parsers, and interpreters. These include JavaScript, VBScript, Flash, JSON, XML, REST, XmlHttpRequest, XSLT, CSS and HTML in addition to your existing server-side technologies. As if that wasn’t enough, each of the AJAX frameworks has its own data formats and custom framework formats.

An application’s “attack surface” approximates the ways in which an attacker can cause damage to your application or its users. The more technologies you use, the bigger your attack surface.

Here, then, are three simple ways of reducing your AJAX application’s attack surface:

Know what runs where

AJAX is making it increasingly difficult to be sure where your code is going to run. Take the Google Web Toolkit (GWT) for example. You program in Java and the environment takes some of that code and compiles it to JavaScript that runs on the client. If you make a mistake and implement authentication, access control, validation, or other security checks in the code that runs on the client, an attacker can simply bypass them with Firebug.

Imagine you’ve carefully coded rules to be sure that administrative functions are never shown to ordinary users. This sounds good, but you forgot that the user interface code is running on the client. So the attacker uses Firebug to invoke the administrative functions. If the proper checks aren’t in place on the server side, the attacker just gained administrative rights. Many Rich Internet Application (RIA) frameworks also have this issue.

The solution is to be very careful about making the boundary between the client and the server very clear.

Keep data separate from code

Hackers frequently use a technique called “injection” to bury commands inside innocent-looking data and get interpreters to execute their commands for them. This simple trick is at the heart of many security attacks including SQL injection, command injection, LDAP injection, XSS, and buffer overflows. Preventing injection in a target-rich environment like the modern browser takes discipline.

The key to stopping injection attacks is never executing data that might contain code. But with AJAX, lots of data and code get passed around and mashed together in the DOM. There has never been a data structure that mixes together code and data more than modern HTML.

So be very careful with data that might include user input. Assume it’s an attack unless you’ve carefully canonicalized, validated, and properly encoded. Imagine you’re invoking a REST interface and the request contains user data. The response you receive is a JSON string that includes that user data. Don’t evaluate that string until you’re sure that there can’t be anything but safe data in there. Even just adding that data to the DOM might be enough to get it to execute if there’s JavaScript code buried in there.

Beware encoding

Encoding makes everything complicated. Attackers can hide their attacks inside innocent-looking data by encoding it. Back-end systems may recognize the encoding used and execute the attack. Or they may decode the attack and pass it on to a system that’s vulnerable to it.

Attackers may use multiple different encoding schemes, or even double encode to tunnel their attacks through innocent systems. There are dozens and dozens of encoding schemes and no way to tell which schemes will be recognized by the interpreters you’re using. This makes recognizing attacks very difficult, if not impossible.

Every time you send or receive data both sides have to know the intended encoding. Never try to make a “best effort” attempt to guess the right encoding. You can’t prevent an attacker from sending data with some other encoding through the channel, but you don’t have to execute it. Here are a few examples:

Set HTTP encoding in the header:

     Content-Type: text/xml, charset=utf-8

Use a meta tag in the HTML:

Set XML encoding in the first line of XML documents:

<?xml version="1.0" encoding="utf-8"?>

Nail it

Remember, your AJAX application’s attack surface is under your control. The choices you make can drastically affect the size of your application’s attack surface. Be sure you ask questions about where your code runs, what data formats and protocols are involved, and which parsers and interpreters get invoked. And most importantly, be sure to nail down how you’re going to keep code and data separate.

If you use Yahoo! for your web search, then Yahoo! provides web services that may be included in web applications to generate dynamic content for an input.

In this article, we follow up Asynchronous JavaScript and XML (AJAX) to your Google search, by looking at adding AJAX to web search using Yahoo! Web Services in Oracle JDeveloper 11g. Why JDeveloper 11g? Because this provides a new feature for web and AJAX development – an integrated JavaScript editor.

Limits of AJAX

AJAX is a web technique to transfer XML data between a browser and a server without reloading the web page. Ajax is implemented using the XMLHttpRequest object.

A limitation of XMLHttpRequest is that AJAX requests may be made only to the same web server that serves the web page from where the AJAX request is sent. If the web application is running on one server and the web service is on another server a XMLHttpRequest request does not get sent. Various methods are available to send an AJAX request to a remote server some of which are digitally signing your scripts and using an alternative XMLHttpRequest API. One of the methods, which we shall discuss in this article, is to use a proxy web server that routes AJAX requests from the web application to the web service.

Yahoo! Web Services provide various web search services and content that may be included to develop dynamic web applications. Yahoo! Web Search AJAX Web Services have an advantage over the Google web search AJAX web services. Yahoo! Web Services have the provision to search within a context; contextual web search. For example, search for the term “Eclipse” in the context of “Java IDE”. The various Web Search Web Services provided by Yahoo! are discussed in following Table.

Before Yahoo! Web Service may be used, register with Yahoo Web Services (https://login.yahoo.com/config/login_verify2?.src=devnet&.done=https%3A%2F%2Fdeveloper.yahoo.com%2Fwsregapp%2Findex.php) to obtain an application identity with which Yahoo! Web Services may be accessed.

Create a web application

First, create a JDeveloper application, WebSearchApp, and project, WebSearchWebService. Create a JSP file, input.jsp, in the project. The web application URL, which is used to register with Yahoo! Web Services, is http://127.0.0.1:8988/WebSearchApp-WebSearchWebService-context-root/input.jsp. In the web application we shall use the Contextual Web Search service to submit a context-base web search query.

The request URL for the contextual web search web service is http://search.yahooapis.com/WebSearchService/V1/contextSearch. The required request parameters to a contextual web search query are appid and context. The value of the appid parameter is the application ID provided by Yahoo! Web Services and the context parameter specifies the context string in which the web search query is sent.

Send an AJAX request

To send an AJAX request we shall use a proxy servlet that routes the XMLHttpRequest from the browser to the Yahoo! Web Service. If an XMLHttpRequest is sent without a proxy servlet the XMLHttpRequest does not get sent and an error, such as the one below, is generated.

Error: uncaught exception: Permission denied to call method XMLHttpRequest.open

A proxy servlet may be developed or the HTTP proxy servlet (http://www.servletsuite.com/servlets/httpproxy.htm) may be used. Download httpProxyPackage.jar. Add the proxy servlet JAR file to the Libraries of the WebSearchWebService project. To the web.xml file add <servlet/> and <servlet-mapping/> elements for the proxy servlet.

<servlet>         <servlet-name>HttpProxy</servlet-name>         <servlet-class>com.jsos.httpproxy.HttpProxyServlet</servlet-class>         <init-param>             <param-name>host</param-name>             <param-value>http://search.yahooapis.com/WebSearchService/V1/contextSearch</param-value>         </init-param>     </servlet>     <servlet-mapping>         <servlet-name>HttpProxy</servlet-name>         <url-pattern>/servlet/yahoo</url-pattern>     </servlet-mapping>

The procedure to send an AJAX request is as follows:

1. Initiate an AJAX request from an HTML event such as a button click
2. Create a XMLHttpRequest object
3. Open a connection with the web service URL using the open() method of the XMLHttpRequest object
4. Register a callback function to be invoked when the Ajax request is complete
5. Send the AJAX request with the send() method
6. Update the web page with the web service response

In the input.jsp, to the input element of type button add a onclick event handler to invoke a JavaScript function displaySearchResults(). In the displaySearchResults function create an XMLHttpRequest object. XMLHttpRequest is supported as a native object in some browsers such as Netscape 6 or later and Internet Explorer 7 and as an ActiveXObject in other browsers such as IE 6.

Specify the proxy servlet URL to which an AJAX request is to be sent. Obtain the values for query, results and context request parameters from the input form. Open an XMLHttpRequest request using the open() method. Register a callback function that is to be invoked when the request state changes using the onreadystatechange property of the XMLHttpRequest object. Send the XMLHttpRequest request using the send() method. In the callback function check if the request is complete and invoke the JavaScript function processResponse() to update the web page with the Web Service response. The complete input.jsp is available in this (http://regmedia.co.uk/2008/01/29/yahooajax_resources.zip) zipped folder.

Integrated JavaScript editor

JDeveloper 11g includes an integrated JavaScript editor for creating JavaScript. In the previous section we added the JavaScript directly to the JSP, but the JavaScript may also be created in a separate .js file and the .js file added to the JSP using the <script/> tag. Create a JavaScript file by selecting File>New and in the New Gallery window Web Tier>HTML>JavaScript File. Copy the JavaScript from the input.jsp JSP to the JavaScript file and delete the JavaScript from the JSP.

Another useful feature of the JavaScript editor is Go To Declaration, to navigate to or from a JavaScript variable or function. You can try this by selecting a use for the variable xmlHttpRequest and then right click and select Go To Declaration to go to the declaration of the xmlHttpRequest variable. JavaScript editor also provides brace matching and code folding.

Error underling and error audits are also helpful. Here’s a simple way to test them: add an error by removing the ‘{‘ for a function declaration. An error analysis will then be run and the error underlined. Usages for a variable or function may be retrieved by selecting the variable/function and selecting Find Usages. For example, select xmlHttpRequest, right click and select Find Usages. The usages of the xmlHttpRequest variable get listed in the log window.

A JavaScript file is integrated with the Structure pane from which different variables and functions may be navigated to. JavaScript editor also provides refactoring to rename or delete a variable or function. To refactor, right click and select Refactor>Rename or Delete Safely. To add the JavaScript file to the input.jsp drag and drop the file from the Application navigator to the JSP. A <script/> element for the JavaScript file gets added to the JSP.

Run the AJAX web search

Next, we shall run the AJAX web application to send a query using AJAX an update the web page with the query response. Right click on input.jsp and select Run. In the web search form specify a query term and a context term. As an example, search for the term “AJAX” in the context of “web services”. Click on the Submit Query button. The web page gets updated with the AJAX web service response.

More than one context terms may be specified and the number of results to be returned may also be specified. As an example specify results as five and specify context terms as “web services”, “XML”, and “ADF” for query term “AJAX”. The specified number of web pages get displayed for the context based web search.

Conclusion

You now have the recepie for building fast and efficient web services. Contextual web search using Yahoo Web Services will help you narrow down your search results. The addition of AJAX will help reduce response times and the amount of network bandwidth consumed as the complete web page is not reposted.

In fact, before you commit any of the deadly sins, you’re much more likely to commit a few lesser sins. So we’ll start with those. These are the ones that make everybody’s list. These mistakes are so common that you can find most of them in a simple Google search.

The Seven Lesser Sins

1.Misuse of the Back Button – This is the one mistake everyone’s going to have on their list. The Back Button has become a user expectation in many kinds of Web apps. Many new AJAX developers drop a Back Button into their AJAX app and promptly break it, for several reasons. First, JavaScript isn’t the friendliest language for it; and second, AJAX design requires a new way of thinking.
It’s not always readily apparent to a new AJAX developer that “Back” isn’t best. “Back” is a feature you’ll need at a page-update point or more often, when you want an event-specific “Undo” feature. Think this through before you code, or you’ll end up doing it twice.
2.Not telling the user what’s happening – Part of how AJAX works is that it doesn’t use conventional Web UI page loading. So you need to explicitly design some visual cue to let the user know what’s happening.
3.Neglecting Links — Here’s another AJAX standard blunder: neglecting URLs that can be cut-and-pasted for uses outside the app. How many times have we grabbed a URL and e-mailed it to someone? When you’re using AJAX, the only way to provide your user with useful cut-and-pasteable URLs is to manually provide them. Why? Because in an AJAX app, the server is not providing the page: JavaScript is dynamically generating it! Don’t neglect your users’ potential interest in this all-too-common feature of Web apps. Take pains to provide URLs, since the server won’t.
4.Trading content control for page control — Breaking with the traditional client-server interaction is a wonderful gift, if you’re seeking dynamic content control. But it’s also a curse: rewriting highly-specific areas of a page to fine-tune a user’s interactive experience does indeed give you fine control, but this pulls you away from the big picture.
All too often, we focus on processing some sector of the page and forget that the page isn’t going to be refreshed by the server. This can lead to a fragmented page, a confusing user experience, wherein the screen they’re looking at can be out-of-date with itself! Take care to keep your attention on the entire page; make sure that any dynamic content event evokes changes everywhere the user will need to see them.
5.Killing spiders – The upside of AJAX is the truckloads of text you can feed a page without a reload. And the downside of AJAX is the truckloads of text you can feed a page without a reload. If the app is intended to be search-engine-friendly — well, you can imagine. Whatever is happening in the guts of the page, be sure to plant plenty of stable text up top, for the spiders to play with.
6.Producing unspeakable text — AJAX doesn’t support many character sets. This isn’t a life-or-death limitation, but forgetting it can create real problems. Your basic character set is UTF-8. Don’t forget to properly encode whatever JavaScript is sending, and remember to set the server-side character set for content.
7.Not letting the JavaScript-challenged user know what’s going on. There are browsers out there that don’t have JavaScript enabled, and users out there who don’t understand immediately what that means. Be sure to clue them in.

Truth to tell, most of those are common-sense issues. The real killers are less obvious.

The Seven Deadly AJAX Sins

1.Letting memory leak – Anyone who has worked in development for very long understands cyclic references and the danger they pose to memory management. JavaScript, the workhorse of AJAX, is a memory-managed language. What that means is that JavaScript has built-in garbage collection, so that it sniffs out variables no longer accessible by any reference path and de-allocates the memory they’re using.
That’s fine as a general principle; but you can’t count on it to keep your memory usage optimised, because of those cyclic references, when a Model-layer object is referencing a View element and vice versa. Nulling the object nulls the element, in principle, but if there’s a backward reference from element to object, then the garbage collector won’t touch the object.
Now, here’s where it gets tricky: in the Document Object Model, any DOM node that’s part of the document tree may be referenced by virtue of its presence in the tree, whether it’s explicitly referenced by another object or not! So any object you tag for garbage collection that is back-referenced by a DOM node must be explicitly nulled in that direction, or its memory remains allocated!
2.Not knowing what “asynchronous” means – Asynchrony can be really unsettling to a user unaccustomed to it, and this can be ironic, since the Web apps you’ll design and build for those users wouldn’t find them at all unsettling if they were desktop apps. This is a crucial design point! Most Web apps are functionally very similar to their desktop counterparts. But in a Web app, there’s a looming characteristic that sets it apart: user expectations.
Users carry a very different set of biases and anticipations into a session with a Web browser that they don’t tote into a desktop app exchange. So while it may be incredibly cool and efficient to have myriad responses trotting back to the page from the server, and the page revising itself in the meantime, it can be deeply disorienting to the user to see this constant barrage of change. For this reason, you need to apply two rules, and consider them with every change that comes into the user’s field-of-vision: If the update is not immediately essential to the user, make the update unobtrusive, so that it does not distract; and if the update is vital to the user’s interaction with the app, make its presence on the page clear and prominent.
3.Keeping the server in the dark – The decoupling of client and server has a huge downside that seldom occurs to us up-front. Server-side apps know all and see all: every exception, every reload, every event can be watched and recorded, and of course the server knows exactly what the client looks like, because the server basically wrote whatever’s on the screen.
In an AJAX app, this isn’t the case. Stuff happens, and it happens independently of the server, and this means that there can be problems on the client side that the server won’t immediately be privy to. Capture and log events and exceptions on the client side, in a place and manner that enables the server to home in on problems that require its intervention as soon as possible.
4.Getting lazy with GET – GET is for retrieving data; POST is for setting it. Don’t use GET when you know you shouldn’t, even if you think it will do no harm. GET operations change state, and links that change state are confusing to users; most are accustomed to links as guides to navigation, not function.
5.Not accounting for data type –JavaScript, isn’t part of the .NET Framework. While this may draw tears of sorrow, it presents us with an example of a problem you’ll eventually run into: making certain that JavaScript understands the data types of the platform it’s running on, and vice versa, be it .NET or otherwise. There are various converters available to you, and you should seek them out. The Ajax.NET Pro library, for instance, offers converters that can convert objects between .NET and JavaScript Object Notation.
6.Some apps just don’t know when to shut up – Dynamic generation of content, with no dependency on page-reload, can be disastrous if left open-ended. How many Web pages have you seen that were longer than the Congressional Record? If Web pages that go on forever are a confusing nightmare for users, just imagine how they’ll feel about an application that goes on and on and on. Make your Web app pages dynamic, but build in some practical limits.
7.Keep your JavaScript out of your DOM — Remember that AJAX is built on the Model-View-Controller structure. Take this seriously. JavaScript belongs in the Model layer, DOM in the View layer, and the Controller is their marriage counselor. Make sure your Web document has the same content independent of JavaScript (this helps with the JavaScript-disabled user) — except when the content itself is only meaningful or practical if the user can use JavaScript. In that instance, create that content with JavaScript.