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

There are a lot of metaphors for security, which may mean we are in a technical field or it may mean that security folk often struggle to explain their point of view.  One I have been thinking about recently is the health of a human body being a metaphor for the security of a business.  I am not the first to use this analogy, see this paper (the section "Cyber Wellness") or this blog entry.

The part of the metaphor that I want to highlight is that you are responsible for the health of your own body i.e. you are responsible for a business or part of it, then you get to decide how to look after your body. Now there are a lot of people out there trying to tell you the best way to look after yourself, whether it be a product to buy or a lifestyle to adopt.  Some of this will be good advice and some of it will be bad.  Likely if you go to a doctor you will believe the doctor's advice, and they are likely to give you good advice on how to be healthy, or just become healthier.

But not everyone follows their doctor's advice all the time.  Often there are circumstances that don't allow you to put your health first, whether you want to or not - sitting all day in front of a computer for years on end is a risk to your health, but if it's part of your job then you do it; flying in a plane is a risk that most people are prepared to take; driving a car is the same.  Sometimes you simple choose the unhealthy option because the opportunity cost of not doing it is much greater - flying to space is very risky but try convincing an astronaut to stop wanting to do it.  And there are of course all the small unhealthy things we do out of necessity (e.g. crossing the street), convenience (e.g. fast food) or laziness (e.g. not brushing your teeth 3 times a day).

A life lived without doing some unhealthy things, without taking some risk, is a life not lived at all.

Similarly in business, as a business that takes no risk is a very risky business.  In this sense, all businesses are in the business of taking risk.

So the job of the security professional is to help the business understand the risk it is taking and help the business to minimise that risk, if that is what the business wants to do.  Of course the key concern here is getting the business to understand the risk (using security metaphors for instance!), and ensure the business is not taking risks it doesn't understand.  Doing so is not a technical skill but a business and communication skill, which should go to reminding security people that technical abilities alone are not the Holy Grail in being effective at our jobs.