Ajax|request|web|xml|xmlhttprequest
First, the introduction
While XMLHttpRequest objects and Ajax bring great benefits to users and developers, there may be some problems you don't consider-but it's time to get everyone's attention.
Even the most annoying people like XMLHttpRequest, because it gives programmers the ability to really dream. It is also because of this new technology, Web applications began to become like desktop applications similar to the behavior of the software. Today, the problem is always as simple as "suppose ...", which puts the naïve end user from needing to know the server, customer, mail back and submit button-"Submit"? Submit to what? "-a series of problems in the abyss of relief.
Recently, countless scary cases have exploded on the web, and they fully explain why remote scripting (or "AJAX", if you like) is the greatest thing ever since the single pixel point GIF technology. In fact, a string of cool, useful apps are growing, as advertised by the site Flickr,google maps,the weborb presentation server.
These sites and many other places advertise the capabilities of Ajax. To be fair, this technology does have considerable potential to improve the quality of online operations. However, although it has many advantages, this sacred Web communication still smells a strange smell in the great cup, and there is still an evil aspect of the beer and chocolate that swings in front of us-how pure and naïve it may seem.
This potential evil lies in the important functional gap behind the familiar interface of the user. Many of you may have been using the Internet for nearly 10 years, and you know how it works: you click around the mouse, fill out the form, modify your input, and when you're done, you can hit the Submit button. You are all aware of these elite experiences-they are passed from the Internet generation to the new generation, such as: "Do not click the Submit button two times-otherwise, the form may have to submit two times" or "Wait a little longer, it is processing" or "After you submit the form, do not click the ' Back ' button", and so on.
But now that Ajax has come in, you can throw the basics out of the window. It's "Everything's OK"-suddenly a new traceable data can be sent out at any time without any knowledge of the user, and even the user is not aware that it could happen. Every keystroke, every mouse move, every click of the mouse, every pause, can be captured and sent to the Web server, and you do nothing about it.
Second, XMLHttpRequest: Advantages and disadvantages
Just as many technologies have advantages and disadvantages, the purpose of this technology is to take advantage of it. Until now, XMLHttpRequest has given people so many advantages, such as input checksums that do not need to be rolled back, spell checking in text areas, and Gmail and so on, which are almost sacred to people. Interfaces created based on Ajax technology are fun to use and even more interesting to encode. It's hard to believe that such a magical technology can do the wrong thing.
But even if there are no significant security vulnerabilities, the XMLHttpRequest may fail because of its outward elegance. It is likely to fail in the application of "user profile"-For better description purposes. Currently, user profiles help the Web site master detective trends, track web browsing habits, and help eliminate usability issues. But until now, developers have only been able to analyze the data sent back-the user decides to let the server get the data and be happy with the submission.
But by means of a microsecond, this energy balance can be translocation. By using AJAX technology, a user's behavior can be monitored continuously and carefully. Because it can be done, so it will be done; This gives people a rather troubling problem than wasting bandwidth, mega-spam, and slower loading times.
Imagine, this is just an example of a problem, and you dropped a new ipod on the floor and it stopped working. Hoping for a free replacement, you sent ane-mail to Apple's service department, saying: "I just bought a new brand of ipod." I accidentally dropped it on the stairs and it suddenly stopped working. After that, you decide to delete the second sentence to support your reasons. Too late! If the site uses AJAX technology, your response could have been killed in front of your complaining desk!
Or-a more malicious and destructive example-consider this: most people have one or two username/password combinations for their "unimportant" sites, such as news sites, blogs, forums, and so on. They may also have several reserved combinations for more sensitive websites-banking, web mail, and job accounts. Entering incorrect login details on a given page is a very common and very easy mistake to make. Although the effects of their previously formed habits are primarily responsible, they are often aware of what they are doing before they click on the Submit button.
Unfortunately, an Ajax keystroke logger is quite cumbersome to implement. With such a keystroke logger, you can use code to collect incorrect login attempts and then experiment with a series of "important" sites-and, of course, you can use the XMLHttpRequest object.
Third, "malicious" hint
To be fair, most of the "malicious" applications cited above can be handled reasonably, even before the advent of XMLHttpRequest technology. Indeed, the request object is a more elegant method of successfully submitting the form data than the previous IFRAME technique. However, XMLHttpRequest works in a more natural way, which can simply make the interaction between the client and server side fade away.
Ironically, until recently, with the popularity of Firefox web browsers, more users were really aware of the depth and breadth of information that could be stored and controlled by Web clients. As tools such as Greasemonkey,web Developer Extensions and cookie editors are widely used, people are more convinced than ever that, if the problem occurs on the client side, responsibility should generally be attributed to that user.
But now, even the arrogant people like us are no longer just right click the mouse, look at the source code, and then can be sure what is happening. Consider the following onreadystatechange JavaScript statement, which is run to respond to a xmlhttprequest:
Xmlreq.onreadystatechange =
{if (xmlreq.readystate = 4) {
eval (xmlreq.responsetext);}
} |
The code above executes the JavaScript code contained in the response from the XMLHttpRequest. In other words, this can happen: even if a page is loaded, it is possible to add or modify JavaScript functions and code in the background! So even if you look at the source code for the page-it might send a keystroke or mouse-moving event to a Web server, you can't be sure that the code you see is the only code currently executing. By combining these features with some daunting puzzles, you can see how the malicious intent, combined with the XMLHttpRequest object, does not achieve Web customer information theft!
four, still not sure?
Don't you feel scared and angry about it? Aren't you ready to get angry and delete the XMLHttpRequest code from your browser? So, well, maybe the strong wording of this article demonstration frighten you; then in the game "Fonzie Treasure Hunt" (the search for ' s treasure. You can definitely find this online text game by typing these keywords into google, and I haven't tried it in depth. Is this little thing so lovely under the face of such a beautiful ambush is so terrible ... )-Can you save Fonzie?
Find the lost Arthur ' Fonzie ' Fonzarelli treasure by using a very artistic command line interface, through the text-filled hallway. I wish you luck, but please remember ... Although it looks like a harmless customer interaction-every four times you move, the game sends a request to the server via the XMLHttpRequest object and saves your move. Always remember: Don't be a printer (Don t make a typo); Don't try something stupid like "eat jukebox"; don't enter a username and password in the game;
