Ajax innovation continues to spur use of Web browsers as ubiquitous clients, but progress is also limited by the security issues that lurk behind such application types. Cross Site Request Forgery and Cross Site Scripting exploits remain among concerns, according to Joe Walker, developer at Mozilla Labs and creator of Direct Web Remoting.
"Two years ago, security was changing rapidly whereas nowadays it's slowed down a bit. But the point is not to think that we're not at risk," said Walker, who appeared at The Ajax Experience 2009 conference.
Cross Site Request Forgery (CSRF) is a common type of exploit in which a user executes unwanted actions in a Web application where they are currently authenticated. This can result in stolen cookies, headers and Kerberos tokens.
Walker said CSRF attacks usually target Web 1.0 applications where a form must be submitted. A few ways to safeguard against this are to routinely force users to log off, and to have the applicat...
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
ion check the header on referring sites. For safeguarding CSRF attacks in XML HTTP Request (XHR) environments, Walker recommended using random value cookies called "domain tokens" that must match up with an identical header in XHR requests.
"Merely setting a header will take care of 90 percent of the cases," Walker said. "Then the question is, how far do you want to go with generating random numbers. You could use Math.random, but that's a bit too predictable for, say, a bank."
There is also a type of CSRF that occurs at login, which can be guarded against by using referrer checking.
Cross Site Scripting (XSS) is yet another issue facing application developers today. This is where a malicious user injects code into pages in a Web application that are then viewed by users. Often there is no indication anything is happening. But behind the scenes, user information is manipulated and stolen.
Fighting XSS is a challenge; application developers commonly counter it by limiting what may be entered into input fields.
"The problem is, we are lazy," said Walker. "Actually getting it right is hard. There's a semantic associated with where you're putting your content and unless you absolutely understand that semantic, you'll run into trouble."
Walker said developers should generally not allow HTML in input fields. Moreover, inputs should be filtered based on what values are "safe" and outputs should be filtered by the destination environment.
"CSRF is the most prevalent threat in my opinion," said Ben Lisbakken, a software engineer at Google. "That's everywhere. It's easy to fix but really easy to exploit. Lots of people have logins on their site but not everyone knows the login can be exploited."
Lisbakken said as a new engineer at Google he even discovered one such security risk in an application he had written that he'd thought was secure enough.
A set of exploits called combination attacks also present a significant though less common risk. Web worms, for example, can use properties of XSS and CSRF to jump through social networks infecting users at exponential rates. Web applications must be safe against both types of attacks to protect against such worms.
Click jacking also hits users from time to time. This is where one page is overlaid as an invisible iframe on another page, enticing users to click on unknown buttons. To avoid this, Walker recommended configuring your application to disallow being displayed in iframes if possible.
