Eric Pascarello parsing Ajax Security

Eric Pascarello is one of the writers of Ajax in Action. Pascarello Penn State University Graduated from 2002 and obtained a mechanical engineering degree. He is also a famous character on JavaRanch.com. In this interview, he talked about Ajax security issues.

Ajax is widely praised as a technology that conveys more user experience. But does XMLHttpRequest ensure security?

Eric Pascare: In the face of Ajax, people often see something called XMLHttpRequest that performs magic on webpages, and they think it can perfectly make up for some security flaws. When we make a simple field of view source on the page, we see that we call the page to transfer parameters. Anyone who uses JavaScript can easily write and change data on each page with the most basic knowledge. Therefore, attacks are very likely, but they do not need to be afraid.

People may say how terrible it is if someone can take over a request so easily. However, these people need to understand that XMLHttpRequest is not more vulnerable than common technologies. You can imagine a form of calling it in another framework. It is like a tag formed on the page and a hidden field in this article. Through a normal HTML format, we can capture the element name and see the parameters sent to the server. We can see the action property and the location where we are calling the data. Just like how we get to know XMLHttpRequest, we can see it on any web page.

Why is confirmation on the server very important?

Pascarello: We can use the local property to change the content on the browser relative to the page. Incomplete, read-only, and hidden. But it may seem like a joke on the client. Enter javascript: document. FormName. ElementName. disabled = "false"; after void (0), you can see whether the fields that are likely to be changed are protected. This is why any experienced developer tells you that you need to confirm on the server. You cannot determine where the data you receive comes from. I can write a form on my desktop and make it follow the page you see. This may be because a computer hacker attempts to inject SQL commands to erase your data. Or add harmful code to JavaScript. Data is insecure, so you must be vigilant at any time.

Is Ajax a different threat from the past?

Pascarello: some security threats encountered by Ajax may be unknown to developers. If they simply design and implement Ajax-based control, they may easily cause their server to crash. Imagine a web page has 1,000 users at the same time. Their servers can process incoming data normally under such loads. They did not store data on the client or server, but directly entered the database to get data control. Now, 1,000 of us have repeated such requests ten times. This server will be 10 times more than the previous operations. If the server cannot process it, they may miss it or simply stop it completely.

You have noticed the attacks against cross-domain requests using JavaScript. Can you explain this?

Pascarello: What really surprised me about security is that developers want to be able to run cross-domain requests with JavaScript. There are some good reasons to do this, such as Web services, but most of them can only serve as server-side code locally. Generally, JavaScript set by users cannot manipulate or access data from another field. To be able to do this, developers must be clear about the purpose of not working in the field. This security setting provides us with great protection against attacks against other frameworks, or the use of XMLHttpRequest to capture our emails and store bank data and card data, eBay account and others. I'm sure these people really don't want. Call data and exchange code in an unfamiliar place. However, do you really trust the security of calling data? Hello?

Look at the Ajax worm that Samy wrote on MySpace.com [IN October 2005, a teenager "Samy" published a self-breeding Ajax worm on MySpace]. This is a big security threat for websites that mainly use Ajax technology. You need to know that the author of the worm injects viruses into a web page through server-side security checks. Now he can easily change the password and capture user data on the page. XMLHttpRequest is not more vulnerable to attacks than others, but you still need to worry about some common problems.

Pascarello's empirical rule for Ajax security:

1. If you use identity verification, make sure you check on the request page!
2. SQL Injection check.
3. Checks JavaScript injection.
4. Keep the business logic on the server!
5. Do not assume that each request is real!
6. Check the data!
7. Review the requested data and make sure it is correct.

(