We Can't Rely on the Browser for Protection

A large part of doing security consulting is providing proper mitigations and recommendations to our clients.  Sure, the testing is the exciting part, but it is the recommendations that are going to have the greatest impact on our client’s security.  It is our goal to help make the security posture better, not set a record in the number of vulnerabilities found.  When thinking about recommendations there are a lot of factors that are weighed in.  We have to look at the technologies that are used, including programming frameworks and systems, as well as system configurations.  What is going to be the best solution to help effectively reduce your risk.  That is the goal…Right.

Often times, when we are dealing with browser issues, we sometimes get a response that includes the built-in features of the browser as a mitigation.  For example, many current browsers will attempt to provide reflective XSS protection.  They do this by looking at the URL and parameters and if there is any HTML tags and they exist in the page, they modify the value so it won’t execute.  While I think it is nice that the browsers are trying to help protect against these types of vulnerabilities, it isn’t enough (and that isn’t anything against the browsers).

It is the responsibility of the application creator to ensure they are doing proper development.  Trying to say that the browser will stop that is a bad idea, for a few reasons.   First, many of the XSS protections in the browsers have been known to have some bypasses.  Second, each browser acts differently to supporting these defenses.  Unless you can control the browser that the users of your application use, this can be very difficult.  It really opens the application up to potential exploitation.

We should be working to make sure we are handling these issues internally.  For XSS, that means doing strong input validation as well as output encoding of the data.  These are basic steps that are used for many vulnerabilities and should be done automatically.  Fortunately, there are more frameworks coming out that handle the output encoding for us, or at least some of it.   As an example, Razor does a good job at output encoding protecting against many forms of XSS.  This points out that it is very important for the developers to understand their technologies to know what is protected automatically and what they need to take extra steps to protect.

There are other examples of protections that the browsers are starting to provide, but again, it is very browser specific.  We need to take the browser out of the equation and code as though the browser does nothing to help protect us.  Don’t mislead yourself by thinking that the browser will save you from common flaws.

James Jardine is a Principal Security Consultant at Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at james@secureideas.com or visit the Secure Ideas – Professionally Evil site for services provided.  You can follow James on twitter @jardinesoftware.