Eric Pascarello parsing Ajax Security

ajax| Safety | safety Introduction "In this article, one of the Ajax in Action writers, Eric Pascarello, talked about issues related to Ajax security.


Eric Pascarello is one of the authors of Ajax in Action. Pascarello, a 2002 graduate of Penn State University, received a degree in mechanical engineering. He is also a famous figure on the javaranch.com. In this interview, he talked about issues related to Ajax security.

Ajax is widely praised as a technology that conveys the user's richer experience. But does the use of XMLHttpRequest really ensure security?

Eric Pascare: When it comes to Ajax, people tend to see something called XMLHttpRequest that performs magic on a Web page, and they think it perfectly compensates for some of the leaks in security. When we do a simple visual field on the page, we see the page we call to send the parameters. Anyone using JavaScript can easily write on each page and change the data as long as they have the most basic knowledge. Therefore, it is possible to attack, but it does not need to be feared.

One might say how terrible it would be if someone could take over a request so easily. But these people need to understand that XMLHttpRequest is no easier to destroy than the common technology. You can imagine a form that it is called in another frame. It behaves like a label on the page and a hidden field of this article. With a normal HTML format, we can grab the element name and see the parameters that are passed to the server. We can see the properties of the action and see where we're calling the data. As with how we know XMLHttpRequest, we can see it all on any Web page.

Why is it important to confirm on the server?

Pascarello: We can use local properties to change the content on the page relative to the browser. Incomplete, read-only, hidden. But it may appear to the client that this may be simply a joke. Enter Javascript:document. Formname.elementname.disabled= "false"; void (0) to see if the areas that are likely to be changed are protected. That's why any experienced developer will tell you why you need to confirm on the server. You can't be sure where the data you receive comes from. I can write a form on my desktop and make it conform to the page you see. This could be a computer hacker trying to inject SQL instructions to erase your data. Or add unwanted code to JavaScript. The data is unsafe, and it has to be kept on guard at all times.

Are there any other threats to Ajax that are different from those of the past?

Some of the security threats encountered by Pascarello:ajax may not be understood by a developer. If they simply design and implement AJAX based controls, they can easily cause their server to crash. Imagine a Web page with 1,000 users at the same time. Their servers are able to handle the data entered in the normal form under such loads. Together they do not store on the client or the server and go directly to the database to get control of the data. Now 1,000 of us have repeated this request 10 times. That server will be 10 times times the size of the previous operation. If the server is not able to handle it, they may be missing or simply stopping at all.

You notice the attack that takes advantage of JavaScript to request across domains. Can you explain it accordingly?

Pascarello: What really surprises me about security issues is that developers want to be able to run Cross-domain requests with JavaScript. There are some good reasons to do this, like Web services, but most of them can only be used locally as server-side code. A generic user-defined JavaScript is not able to manipulate or access data from another domain. Developers want to be able to do this, they have to be clear about the purpose of not needing to work outside the field. This security setting gives us a lot of protection from the attack we get through another framework, or the use of XMLHttpRequest to grab our emails, bank data, card data, EBay accounts, and more. I'm sure these people are really not going to do that. Call data in an unfamiliar place and exchange code, but do you really trust the security of the data being invoked? Say hello to an ad for a canned ham new breed?

Look at the Ajax worms written by Samy on MySpace.com [October 2005, a Teen "Samy" released a self propagating Ajax worm in MySpace]. This is a big security threat for Web sites that use Ajax technology primarily. You have to understand. The worm's author injects the virus into a Web page with server-side security checks. Now he may be able to easily change the password and crawl user data on the page. XMLHttpRequest is not more susceptible to attack than the others, and what you need to worry about is still some routine problem.

Pascarello the rule of thumb for Ajax security:

If you use authentication, make sure you check on the request page!
Check for SQL injection.
Check for JavaScript injection.
Keep business logic on the server!
Don't assume that every request is real!
Confirm Check Data!
Review the requested data and make sure it is correct.
<