The Ajax security basics of combined application technology introduction

Ajax| Security

1. Introduce

Ajax has been noticeable in the last year because of its good interactivity. Google suggest and Google Maps [ref 1] are some of the earliest known applications of Ajax. Now, companies are considering how they can also use Ajax,web developers to learn it, and security experts are thinking about how to make it safe, and hackers are thinking about how to invade. All the technologies that improve server throughput, generate more dynamic page transfers, and provide richer Web applications to end users are bound to occur in this area.

The next step of Ajax is called "Web 2.0". The purpose of this article is to introduce some security recommendations about modern AJAX web technologies. Although the application of Ajax is difficult to test, security experts already have most of the relevant methods and tools needed. The authors will discuss whether today's trends require a farewell to full network updates, and that using Ajax also means that we will face some new security issues. We'll start with a brief introduction to Ajax technology and then discuss the security impact of using AJAX technology applications.

2. First knowledge of Ajax

A normal web application works in synchronous mode, and after a Web request, a response causes some action in the presentation layer. For example, click the link or submit button to produce a request with the corresponding parameter to the Web server. The traditional "Click and wait" approach limits the interactivity of the application. The use of Ajax (asychronous Javascript and XML) technology alleviates this problem. In this article, we define AJAX as a way to generate an asynchronous call to a Web server without causing the Web page to be fully updated. This interactivity is implemented through three different components: client-side scripting languages, XMLHttpRequest (XHR) objects, and XML.

Let me briefly describe these components separately. In the request response, the client script language is used to initialize server calls and access to programs, and to update the DOM of the client's browser. JavaScript is commonly used by clients because it is commonly used by well-known browsers. The second component is the XHR object, which is the most important part. Languages such as JavaScript use the XHR object to send requests to the Web server after the scene, using HTTP as a transport intermediary. Then there is the third component, which is necessary to use: XML is the data format of the exchanged information.

Many sites use JSON (JavaScript Object notation) instead of XML because it's easier to parse costs that don't require so much management. Using JavaScript to parse JSON, simply pass it to the eval () function. On the other hand, one might use XPath to parse the returned XML. Similarly, there are many "Ajax sites" out there that neither use XML nor JSON, but simply send unformatted HTML fragments that are dynamically inserted into the Web page.

As a result, Ajax is not a new technology brand, but a federated application of existing technologies, driving the development of highly interactive Web applications. In fact, all of these components have been on the rise for years, notably with the release of Internet Explorer 5.0. Developers have created many AJAX applications, such as the "Hint" text box (like Google suggest) and the automatic updating of data lists. All XHR requests are still performed by typical server-side frameworks, such as standard selections like Java EE. NET and PHP. The following figure 1. is an asynchronous feature legend for AJAX applications:

Figure 1. Ajax Asynchronous order

3. Ajax Security Applications

Now that we've reviewed the basics of Ajax, let's discuss its security implications. In the realm of Web applications, Ajax itself does not introduce new security vulnerabilities. These applications face the same problems as classic Web applications. Unfortunately, the best implementations of Ajax have not yet developed, leaving a lot of leeway to make mistakes. It includes security verification, authorization, access control, and input checking. [Ref 2]. Some of the potential areas involved in AJAX use include:

• Client-side security control

Some people think that the dependency of client programs may lead to some already well-known problems. [Ref 2]. One possibility is for developers to compromise security through client control. As mentioned earlier, the use of Ajax requires quite a few scripting languages. Today, Web developers write both server and client code, which may appeal to developers who implement client-side security controls. This approach is highly unreliable, as attackers can modify any code that runs on their client computers when testing the application's vulnerabilities. Security controls should be performed entirely on the server or upgraded frequently on the server.

• Increasing attack surface

The second challenge is to protect the ever-increasing attack surface. Ajax inevitably increases the overall complexity of the system. In the process of using AJAX, developers may want to write a large number of server-side pages, each of which performs some small functions throughout the program (like to automatically complete a user's city and state domain, search the ZIP code). These small pages will each become an additional attack target for hackers, and an additional point needs to be protected in order to ensure that no new security vulnerabilities are introduced. This can be likened to a well-known, more focused view of security as if entering a house: the difficulty of protecting a house with only one door is compared to the protection of a house with 10 doors.

• Connect the gap between user and server

Ajax is a way for developers to shorten the distance between end users and service-oriented architecture interfaces. [Ref 3] Increasing the loosely connected service based architecture has many advantages in the enterprise environment and is a promising approach. As more service-based endpoints evolve, the likelihood of moving away from the three-tier standard model increases as Ajax introduces the possibility of providing more flexible processing to end users.

In general, many Web services within an enterprise (as opposed to all services on the Internet) are designed to be business-to-business, so designers and developers often do not consider the interactivity of the actual user. This lack of foresight has led to some bad design process security assumptions. For example, the original designer might assume that security certification, authorization, and input checks would be performed by other mid-level systems. Once someone has allowed the "outsider" to invoke these services directly through Ajax use, a proxy is introduced that is not considered. A real example of this type of use is the consistency check that Microsoft's Atlas[ref 4] and Web services use at the same time. Developers can now write JavaScript to generate XML input and correctly invoke Web services from the client browser. In the past this was done by the agent and the server.

• New Hope for cross-site scripting (XSS)

Another unfortunate fact is that attackers can be more creative (in other words, more dangerous) by leveraging the vulnerabilities of Cross-site scripting (XSS). [Ref 5] The hacker used to use an XSS vulnerability in a "single-threaded" environment where the user's browser was waiting while the attack was executing. This wait state provides a clue to the user who may be executing the program incorrectly. With the introduction of Ajax, an attacker could exploit a cross-site scripting vulnerability in a more covert way. When you use an AJAX-enabled program to check your email, malicious code may send emails to all your friends and your browser will not leave any visible traces.

To solve this problem, there must be a sufficient number of targeted security tests to be performed before placing the program in the product. Even if AJAX programs are Web applications, a well organized, existing security testing method may not be sufficient due to the highly interactive nature of these applications.

4. How Ajax

When testing a normal Web application, an intrusion tester starts with the footprint application. The purpose of the footprint phase is to capture the request and the response so that the tester knows how the application communicates with the server and the response it receives. This information is logged by a local agent such as Burp[ref 6] or Paros[ref 7]. The footprint phase must be as comprehensive as possible, so the tester's day-ambition application uses all pages to issue a request.

The tester then starts the system's error-injection process, either manually or by using an automated tool to test incoming arguments from the Web server.

·“ Status "problem

In the general Web application World, the state of the application is clearly defined. Everything that exists in the DOM of a page can be considered the current state of the page. If the state needs to change, a request is sent to the server, and the response details how the state changes.

• Initialization requests via timer events

This involves updating the user interface through timer-based events without requiring any user interaction. The application may periodically send requests to the server to update the information on the Web page. For example, a financial application might use the XHR object to update part of a page that displays current stock market information. Testers may not notice background processes, if they do not capture the request at the right time, because there may not be any visible links or buttons to remind the tester that a request has been made in the background.

• Dynamic DOM Update

Ajax responses can contain javescript fragments, which can be evaluated by Web applications and can appear in the user interface. This may include new links, storage of new documents on the server, and so on. One way to achieve this is by using the eval () declaration. [The ref 2,ref 8]eval () declaration accepts a single variable, a string, and executes the string as if it were part of a program.

Google suggest is a good example where the application receives a JavaScript fragment that is evaluated and may be recommended as a complete input query. This behavior is problematic for both manual testers and testers who use automated tools. Both will have to understand how JavaScript is used in the context of a Web application. Extra care is required when an input parameter is sent back after the client has been evaluated. This sounds like a typical XSS and it is, but it has become very easy to exploit. Applications that use blacklist acknowledgement are more susceptible because attackers do not need to inject many tags. Some methods can be used to use XSS without scripting tags like in the past.

· XML fuzzing

Ajax can be used to send requests to receive responses in XML format. Simple automated tools do understand get and post methods but may not know how to handle information that is encapsulated using XML format.

Testers must ensure that the developer does not deviate from a secure architecture. In a security system, security controls are implemented in an environment other than end-user control. When performing reviews, you must thoroughly review the client code to determine whether the state can be modified before submitting the variable (cookies, form parameters, get parameters) to the server. Once this happens, you need to analyze JavaScript to determine why.

As with a typical Web application, all AJAX requests need to be tested for authorization issues. Developers believe that because a page is invoked after a client script engine and does not require authorization, it can be a victim. This is not actually the case.

5. Conclusions

Ajax applications offer new possibilities through its highly interactive nature. Developers may be tired of the new insecurity introduced by these features. Security testers must increase their test methods and toolset to cope with Ajax applications.

In this article, the author introduces some of the security applications in AJAX technology. Intrusion testers are seeing that they already have the knowledge and tools to evaluate AJAX applications, but they are still a little hard to test. Later articles will focus on more aspects of the problem, such as helpful tools that can be used in AJAX security tests.

6. Reference

[Ref 1] Google suggest and Google Maps, two early Ajax applications.

[Ref 2] Stewart Twynham, "AJAX security", Feb 16th, 2006.

[Ref 3] Andrew van der Stock, "AJAX security", OWASP presentation given on February 7, 2006. A Direct descendent of this presentation are also available from Andrew van der stock at http://www.greebo.net/owasp/ajax_s Ecurity.pdf.

[Ref 4] Microsoft ' s Altas framework tries to integrate as a middle-tier.

[Ref 5] Post by "Samy," on a "technical explanation of the MySpace worm".

[Ref 6] Burp Web application proxy for penetration testing.

[Ref 7] Paros Web application proxy for penetration testing.

[ref 8] post by Rogan Dawes, author of WebScarab, on the WEBAPPSEC mailing list.

7. Further reading materials

· Jesse James Garrett, "ajax:a New approach to Web applications", Feb. 18, 2005.

· Ryan Asleson and Nathaniel T. Schutta, "Foundations of Ajax", APress Publications, Oct 2005.

· Nicholas C. Zakas, Jeremy Mcpeakandjoe Fawcett, "Wrox Professional Ajax", Feb 2006.

· Eric Pascarello, "Eric Pascarello dissects Ajax security Vulnerabilities", Feb. 07, 2006.

· Andrew van der Stock, "Ajax and Other ' Rich ' Interface technologies".

8. About the author

Jaswinder S. Hayre, CISSP, and Jayasankar Kelath, CISSP, are senior security engineers at Ernst & Young ' S Advanced in New York.

(t116)

================================

Original link: http://www.iis-resources.com/modules/AMS/article.php?storyid=576

Original Author: Jaswinder S. Hayre, CISSP, and Jayasankar Kelath, CISSP