Ajax application security issue can be address by take care in desiging of application architechture.Here I will going to introduce that thing which can resolve the Ajax application security problem.
SQL Injection : In these attacks, hackers first research common SQL error messages to find vulnerable pages and then modify Select statements to, for example, use a simple TextBox to gain access to a database. Ajax complicates matters because it makes it possible to write SQL expressions on the client side.
Tips to prevent this kind of attacke are:
1. Use CustomErrors pages in the WebConfig file to prevent attackers from identifying an application's particular vulnerability.
2. Use Stored procedures or parameterized SQL queries instead of dynamically created SQL queries.
4. Use the Least Privileges account for your database and do not allow access to system data. This builds on the notion that security should be implemented in single layers, Software Engineering stated: "You don't want them to be able to thwart one and then get to the data."
To Protect against Cross-site-scripting I would urge you to do your own validation to make sure you're not allowing this type of input." To best accomplish this, he recommended the use of a white list, which specifically states only the characters that a user is allowed to type in the TextBox. Make sure this list does not include script tags or HTML code.
Cross-Site Request Forging: These attacks use malicious image tags in emails and leverage browser cookies. The image acts as a placeholder for what is really a query string to make that aforementioned money transfer. Once that page loads, the image request triggers an HTTP GET action, and cookies are passed along with it. "The variables coming in from the query string look exactly the same as a post. It's using that cookie that's stored on your computer, and your information, to make that query work,"
Protecting against cross-site request forging involves three best practices, he continued. The first is to use HTTP POST data as opposed to HTTP GET data; the latter can be used for retrieving data, but it should not be used for performing any sort of action using that data. The second is to use one-time, per-token requests. The third is to stand up to nagging end users and stop using persistent cookies for authentication -- especially if sensitive data sits behind a log-in screen.
Lombardo offered two tidbits of advice that were not covered in his discussions of the five common Ajax security vulnerabilities.
First, he recommended removing the WSDL from Web services, as this only gives hackers information about an application that they otherwise would not be able to determine.