Ajax technology has been present on websites for many years due to its interactive capabilities. Google Suggest and Google Maps were two early applications of this technology. Today, companies are pondering how to leverage it, web designers are striving to learn from it, security experts are working to secure it, while penetration testers are considering how to hack it. Regardless, any new technique that can enhance server throughput, provide more flexible state transitions, and create richer web applications for users ultimately seeks to establish a foothold in the industry.
Ajax is seen as the next step in the “Web 2.0” generation. The purpose of this article is to introduce some fundamental security issues associated with modern Ajax web technology. With Ajax, applications can be challenging to test; therefore, security experts have prepared appropriate methods and necessary tools. We will discuss whether it’s time to say goodbye to traditional web applications in favor of Ajax, which could also mean welcoming new security vulnerabilities. Now, let’s briefly discuss the internal techniques of Ajax and examine how Ajax applications impact security.
Core of Ajax
Traditional web applications operate on a synchronous model, meaning that when a web request is made, it is accompanied by a response that performs some actions in the presentation layer. For instance, clicking a link or pressing a submit button generates a request to the web server with relevant parameters. This “click and wait” habit has limited the interactivity of applications. This issue is alleviated by using Ajax (Asynchronous JavaScript and XML). For the purposes of this article, I will consider Ajax primarily as an asynchronous calling method that interacts with the web server without refreshing the entire webpage. This type of interaction is made possible by three components: client-side scripting language, the XmlHttpRequest (XHR) object, and XML.
Let’s briefly discuss these components:
The client-side scripting language is used to initiate calls to the server, which are then used to access programs and update the DOM within the client’s browser. The most popular choice on the client-side is JavaScript due to its strong compatibility with various browsers. The second component is the XHR object, which is the true heart of this technique. Languages like JavaScript utilize the XHR object to send requests to the web server hidden behind the script and use HTTP as a transport medium. XML formats the data for the messages that can change.
Many sites use JSON (JavaScript Object Notation) instead of XML, as its syntax is easier. When using JavaScript to parse JSON, the process becomes significantly simpler. On the other hand, one can also use XPath to parse back into XML syntax. There are also many Ajax applications that do not use XML or JSON, opting instead to send dynamically inserted HTML fragments into the webpage.
As mentioned earlier, Ajax is not a brand-new technology; rather, it is a combination of pre-existing technologies brought together to develop highly interactive web applications. In fact, all the above components had already appeared before and were widely used with IE 5.0. Designers have introduced Ajax use cases such as “suggestive” textboxes and automatically refreshing data lists. All XHR requests are still processed by typical server-side frameworks similar to J2EE, .Net, and PHP. The asynchronous nature of Ajax applications is illustrated in the image below.
Ajax Security
Having reviewed Ajax, let’s now discuss its security. Ajax does not introduce new security vulnerabilities in web applications. Instead, applications face the same security issues as traditional web applications. Unfortunately, the most common actions of Ajax have not been well-developed, leaving many areas with potential errors. This includes proper awareness, authorization, access control, and input validation. Some potential areas related to the use of Ajax are as follows:
* Client-Side Security Controls
Some may argue that the reliance on client-side programming brings about certain orientation issues. Such capabilities relate to the security of poorly designed client-side controls. As discussed in the previous section, the use cases for Ajax are quite limited for client scripting code. However, designers today are required to write both server-side and client-side code. Therefore, they may be drawn to focus on security controls on the client side. Clearly, the client side is not safe because attackers can alter any code running on their client machine. Consequently, security controls must be supplemented on the server or always enforced on the server.
* Increased Attack Surface
A second challenge related to complexity involves protecting the increased attack surface. Ajax certainly increases the complexity of all systems. During the Ajax implementation, designers may write code with a significant number of client-side pages, each performing a few small functions (in a large application). These small pages will become additional targets for attackers, thus introducing another point that needs to be secured to prevent new vulnerabilities from being introduced. This is similar to the known security concepts regarding the entrances of a house: the difficulty here lies in securing a house with one door compared to one with ten doors.
* Bridging Gaps Between Users and Services
Ajax provides users with friendlier interfaces through its direct service structure. The push to separate a pair of server-based structures is a promising idea with many benefits, especially in business environments. As more of these “endpoints” are developed, and as Ajax introduces the capability to push more sophisticated processing to users, the prospect of shifting away from the three-tier model will occur.
Overall, many web services within business systems (which contrast with the entire Internet) are designed for B2B (Business to Business), which is why designers and developers often do not anticipate real user interaction. This lack of foresight leads to a series of poor security assumptions throughout the design process. For instance, the initial designers assumed that awareness, empowerment, and input validity would be enforced at the middleware systems. Allowing “outsiders” to directly call these services via Ajax introduces an unwanted agent into the picture. A real-life example of such a scenario is a suitable link from Microsoft to use Atlas hand-in-hand with web services. Now, designers can write JavaScript to create XML input and correctly call web services from within the client’s browser. In the past, this was done through service delegation at the server.
(To be continued)
Pham Van Linh
Email: [email protected]
