Basic security in Ajax

Ajax technology has appeared on websites many years ago thanks to its interactive properties. Google Suggest and Google Maps are two applications of this technology early. Today, companies are thinking about how to make use of it, web designers try to learn it, security experts try to secure it, and inspectors About anti-penetration is thinking how to hack it. At any rate, any new technology that can improve server throughput, provide more flexible transitions and create web applications that are richer for users is ultimately dead. it is to find a standing position in the industry.

Ajax is seen as the next step of the 'web 2.0' generation. The purpose of this article is to introduce some basic security issues in modern Ajax web technology. With Ajax, applications can be difficult to test so security experts have prepared suitable methods and other necessary tools. We will discuss whether to say goodbye to old web applications instead of using Ajax, which means we welcome some new security holes. We will now discuss briefly the inner techniques of Ajax and consider how Ajax applications affect security.

The core of Ajax

Web applications typically work on a synchronous model, which means that when someone requests a web request, it is accompanied by a response to perform some actions in the presentation layer. For example, clicking a link or clicking the submit button will create a request to the web server with the relevant parameters. This habit of 'click and wait' has limited the interaction of applications. This problem is reduced by using Ajax (Asychronous Javascript and XML) technology. For the purpose of this article, I only see Ajax as an asynchronous method of calling it to the web server without having to refresh the entire web page. This type of interaction can be done by three components: client scripting language, XmlHttpRequest (XHR) object, and XML.

Here we briefly discuss these components:

The client scripting language is used to initiate call commands to the server and is then used to access the program and update the DOM within the client browser. The most popular choice on the client is Javascript because its display with browsers is quite good. The second part is the XHR object, this is really the heart of this technique. Languages ​​like Javascript use the XHR object to send requests to the hidden web server under the script and use HTTP as a transport medium. XML will format data for messages that can be changed.

Many sites use JSON (Javascript Object Notation) in the XML section because its syntax is easier. When using Javascript to parse JSON, it is much simpler. On the other hand, someone can use XPath to analyze and return XML syntax. There are also many Ajax sites that do not use XML or JSON, instead sending only dynamically inserted pieces of HTML into the web page.

As pointed out above, Ajax is not a brand-new technology, but rather a combination of pre-existing technologies together to develop highly interactive web applications. In fact, all of these components have come first and have been used extensively with IE 5.0. Design experts have released cases using Ajax such as 'Suggestive' textboxes, and automatic data refresh lists. All XHR requests are still handled by typical server side frameworks such as J2EE, .Net and PHP standards. The asynchrony of Ajax applications is shown in the image below.

Ajax security.

We have reviewed Ajax, now let's discuss securing it. Ajax has no new security holes in the field of web applications. Instead, applications face security issues like classic web applications. Unfortunately, Ajax's most common actions were not developed, leaving many areas with wrong issues. This includes proper awareness, licensing, access control and input validation. Some potential areas related to Ajax use are as follows:

* Client security controls

Some people may argue that client dependence on programming causes the possibility of bringing some directional problems. Such capability involves the security of inefficient design professionals through client controls. As we discussed in the previous case of Ajax use, it is quite small for client scripting code. However, designers are now writing both code on the server and the client. Therefore, it is possible to attract design professionals towards security control on the client. Obviously on the client is not safe because attackers can change any code running on their client computer. Therefore, security controls need to be added on the server or must always be executed on the server.

* Increased attack surface

A second challenge related to difficulty is protecting the attack surface. Ajax certainly increases the complexity of all systems. In the course of Ajax succession, design experts can write code with a large number of server pages, each performing a few small functions (in large applications). These small pages will be an additional target for vandals and thus a further point needs to be ensured to protect the new vulnerability from being introduced. This is similar to the known security concepts in a house's entrance: the difficulty here is to secure a one-door home compared to one with 10 doors.

* Loopholes bridge between users and services.

Ajax is a method that gives users more user-friendly interfaces by its direct service structure. The push to make a couple of server-based structures leave is a promising idea with many benefits especially in the business environment. As more of these 'endpoints' are developed and when Ajax introduces the ability to push more sophisticated processing to users, the prospect of leaving the three-layer model will happen.

In general, many web services within the business system (which is in contrast to the entire Internet) are designed for B2B (Business to Business), and therefore designers and developers are often undesirable. interaction with real users. This distress leads to a series of bad security assumptions throughout the design process. For example, designers initially acknowledged that awareness and power and the effect at the input will be implemented in middle-tier systems. Someone allows 'outsiders' to call these services directly via Ajax, an unwanted agent introduced in the image. A real example of such a life is an appropriate link from Microsoft to using Atlas hand-in-hand with web services. Designers can now write Javascript to create XML input and call the correct web service from within the client browser. In the past, this was done through service credentials at the server.

( Also )

Pham Van Linh
Email: vanlinh@quantrimang.com