Monday, 10 September 2007
Layered Ajax Security
Ajax is sometimes criticized for introducing security holes. This is a valid concern, but the situation is complex: Ajax techniques can be applied in many different ways; some lead to secure applications and some do not. to understand, we need to look at the security characteristics of current practices.
First, lets look at some of the more blatant problems. One of the greatest dangers is presented by moving data and business logic into the browser. JavaScript obfuscation is merely an inconvenience to hackers. Sensitive information that finds its way into the browser cache may persist for some time and, once on the filesystem, can potentially expose data or business processes to exploitation by worms or viruses.
To further compound the problem, mashups mix sensitive data and processes from multiple sources together in one page. Any component of the mashup can impersonate any other and, acting with the user's credentials, cause significant loss or damage. Is that JavaScript map component just displaying a map, or is it mining your customer database? You have no further guarantee than trust in the component's authors and the integrity of their servers.
Finally, the nondeterminism of dynamically loaded scripts make the complete Ajax system difficult to analyze from a security perspective (what cannot be analyzed is potentially a security risk). When data is passed to the browser as JSON rather than XML, even the data is dynamically executed; this further complicates the analysis because any source of data into the application then becomes suspect.
But that's the bad news. The good news is that there are ways to use Ajax techniques and retain the security characteristics of traditional web applications: fundamentally, Ajax still makes use of a web browser communicating with the server over HTTP/HTTPS. With ICEfaces we have approached the problem by using layers of security, each of which preserves the benefits of the layers below it:
- The application is implemented entirely in Java and resides on the server. No business logic or application database is stored in the browser. By using commonly available persistence technologies, such as Hibernate, input into the SQL interpreter is automatically escaped, preventing SQL-injection attacks.
- XMLHttpRequest sends HTML form data, just like traditional web applications . No security holes are opened through application-level remote procedure call interfaces. This limits the attack surface to the application user interface, matching what is exposed to what developers expect is exposed.
- The JavaScript implementation is fixed size and function, restricted essentially to the funcation of exchanging events with the server and applying incremental updates, sent as XML, to the page. This makes it security auditable and testable.
- The application filters all output through JSF, automatically escaping it, and preventing injection of malicious JavaScript used for cross site scripting attacks.
- Existing Java access-control techniques can be applied, and component-level access control is provided by the ICEfaces components.
- SSL can be used to secure the connection since all XMLHttpRequest traffic goes over the same connections as the originating page resources.
Steve's whitepaper, Enterprise Ajax Security with ICEfaces goes into the topic in more detail. As you can see, the Ajax security problem really is solvable, it just has to be approached in the right way.
In the future, perhaps we'll see a browser security model that can efficiently isolate different mashup components, but for the time being, the safest approach is to aggregate content from different web pages and web services on the server, and then provide the data obtained through your application. (It could even be argued that this more careful form of aggregation ultimately will lead to the best user experience.)
Posted by at 12:22 PM in Entries by Ted Goddard