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.)
