Five common Ajax security challenges and how to address them |
 |
By Brian Eastwood, Site Editor
25 Oct 2007 | SearchVB.com |
|
|
Ajax is not an application vulnerability per se. However, the programming model does make existing vulnerabilities more porous, and JavaScript-powered client-server interactions do enlarge the attack surface.
That said, Ajax application security can be addressed through a series of simple steps. Tony Lombardo, head of the Worldwide Evangelism Group at Infragistics, offered tips for addressing five common Ajax security challenges in a session at the recent ReMIX07 Boston. Additional security best practices emerged as well.
SQL Injections: 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.
Lombardo offered several tips for preventing SQL injections in Ajax applications:
- Use CustomErrors pages in the WebConfig file to prevent attackers from identifying an application's particular vulnerability.
- Use Stored procedures or parameterized SQL queries instead of dynamically created SQL queries.
- Perform input validation on the server side, not through JavaScript.
- 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, Lombardo stated: "You don't want them to be able to thwart one and then get to the data."
Information Leakage: If the JavaScript APIs that power an Ajax application are not properly secured, hackers can use application workflow data exposed on the client side to piece together server-side services. The best way to protect against this, not surprisingly, is to keep security validation on the server side. The only validation that should occur on the client side is that which defines the user experience, Lombardo said.
Cross-Site Scripting: In these attacks, hackers foist malicious JavaScript onto unsuspecting users. This tends to happen on Web sites featuring a simple TextBox and a button click that encapsulates text. Instead of, say, posting a comment in a forum, hackers will use this TextBox to put in a script tag to transfer large sums of money from your bank account to theirs. Ajax, as you might expect, leaves more APIs open than does a traditional Web application.
To protect against cross-site scripting, Lombardo said, "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," Lombardo said.
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.
JavaScript Hijacking: This variation of cross-site request forging, which thanks to ASP.NET and IIS authentication does not occur in Internet Explorer, sets script tags to a particular URL that, when HTTP GET is passed, will return a JSON-formatted string. From there, the hacker modifies the object prototype to peer into JSON values when they are created. In addition to using the HTTP POST protocol, Lombardo said the best way to protect against JavaScript hijacking is to encode JSON strings on the server side, not the client side.
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.
Second, he said it is a good idea to place WebMethods and WebServices in separate classes.
|
|
|
|
