Thursday, 27 February 2014

Java by numbers

A lot has been written about how bad Java is from a security perspective.  Specifically, if you have Java enabled in your browser, well, you're going to get pwned (unless you have some compensating controls). Assuming your business requires Java be enabled in browsers for certain applications to work, then whilst it's not the only compensating control that should be used, having the latest version installed is a good start.

I've been looking at Java recently and wanted to know more precisely how much risk it posed.  So I pulled together the number of vulnerabilities related to applets and web start applications (i.e. Rich Internet Applications) that have been discovered over the last couple years.  You can see the numbers on my page Java Vulnerabilities.  It makes for scary reading.

Friday, 21 February 2014

Is contextual output escaping too hard?

So whilst writing my post on Unobtrusive Javascript and JSON Data Islands I got to thinking about how successful contextual output escaping (or encoding) is as a tactic to mitigate XSS vulnerabilities.

I think there is an argument that it hasn't been very successful, and I don't think it is too hard to imagine the reasons for this:
  • As a mitigation to XSS it involves a task that is essentially difficult.  Knowing the context (either HTML, HTML attribute, JavaScript, CSS, etc.) where you are binding data into a template, either involves writing an HTML parser (to do it properly), or have developers manually specify the context for each binding site.  That is not a solution as much as it is a whole new problem.
  • There is a reason why there is no "contextual SQL escaping" mitigation promoted by the security community, and why parameterised queries is the mandated mitigation to SQL injection.  It's because history has shown us that people are terrible at combining data and code and that the best option is to let the component that executes the code (and hence has the best code parser) do the combining for us.  XSS is the same problem, combining data with code (HTML), which suggests that the browser should be combining the data and code(1) and we shouldn't be suggesting people do this themselves.
Of course it's all very well saying that people should architect their web applications to have the browser combine code and data, but developing web applications is a complex problem and there are lots of considerations to take into account when architecting the application, not just security.  My impression is that the main considerations are performance and convenience.

Performance is tough to comment on, and depends on many things, but potentially moving more work to the client-side could improve server performance (you could argue that client-side performance might suffer, and thus user experience, but JavaScript performance only improves).  Though there is no doubt that some businesses are very sensitive to page load times.

Convenience isn't a good reason in my opinion.  It might not be convenient but that doesn't mean it can't be convenient.  If a web application framework was designed from the ground up to let the browser combine code and data then likely they would (eventually) do it in a way that was convenient.  Of course relying on frameworks means getting popular frameworks(2) to change, and I think the security community has a role to play there.

I will say that I've spent a good deal of time telling businesses to use contextual output escaping, and it is always difficult to challenge a long held belief, but there is evidence and reasoning to suggest that parameterising HTML is the better mitigation.  The jury is still out in my mind, but I would be keen to hear other points of view?

(1) See also "Insane in the IFRAME - The case for client-side HTML sanitisation" (video - slides) from OWASP AppSecEU 2013.
(2) That's not to say there aren't some web application frameworks that have contextual output escaping built-in or support data binding on the client i.e. JavaScript templating engines (although I'm not sure the browser does the escaping), but I think (but am not an expert) that most don't.  There are a lot of web application frameworks out there.

Thursday, 20 February 2014

Unobtrusive JavaScript and JSON Data Islands

I saw a tweet the other day from Jim Manico
That link is to

The advice is basically to have more or less static HTML and JavaScript and all dynamic data should come from a JSON request.  Not bad advice.

Reading the article reminded me of a similar approach that I once proposed, using Unobtrusive JavaScript. Unobtrusive JavaScript is an approach to developing a web application that clearly separates HTML from JavaScript from CSS.  Now if you are a developer then rest assured this is not an approach created by a security guy who prioritises security above all else, this is an approach suggested by people who actually know what they are talking about.  The Wikipedia page has the details, and interestingly is doesn't even mention the word 'security'.

So why is Unobtrusive JavaScript good for security?  Well the best approach to preventing XSS is to use contextual output encoding, however that hard part of that is the 'contextual' bit.   It seems that figuring out on the server side how the data being bound to a template is going to be interpreted by the browser, as either HTMl, JS or CSS, is often quite difficult.  But if all the HTML, JS and CSS reside in different files, then the context couldn't be easier to determine, which makes output encoding a much simpler task.  Additionally, this separation can be enforced by using the Content Security Policy (CSP) so you don't get any naughty developers slipping in JS where they shouldn't.

Of course if you are going to be suggesting Unobtrusive JavaScript then I wouldn't even mention security, there are so many other benefits that make it a good idea that you probably don't want any security related ulterior motives to be an issue ;)

So there are obvious similarities to what Adam Barth suggested, but a difference that I proposed was an alternative to using AJAX requests.  So instead of making a separate network request for the JSON data another option is to put the JSON data inside the the HTML, in a 'JSON data island' (sadly it seems someone else beat me to coining this phrase).  The comes from XML Data Islands, but obviously if the data is going to be used by JS it makes more sense for it to be JSON than XML.

The JSON data island could be implemented as a hidden <div> element or a <script> element with type="application/json".

The basic advantage is that it saves a network request.  Admittedly this makes more sense for HTML pages that wouldn't be cached, so its appropriateness does depend on how the web application is architected (in terms of caching optimisations made).  The data island would also need its own output encoding as the appropriate encoding for the server to do is to JS encode the data going into the JSON and then HTML encode the entire data island contents.

Sadly my proposal represented too much of a change to the web application I suggested it for, so if you like the idea, I hope you have better luck than me.

Sunday, 2 February 2014

Risky Business





