XSS and XSRF are the most pervasive security flaws in Web applications today. Yet these problems are not inherent to application platforms overall. For example, we do not see these vulnerabilities affecting mobile apps to the same extent as they are known to affect traditional web apps.
One reason web apps are uniquely vulnerable to XSS / XSRF is simply because the design of the web platform enables malicious web content to reference a web application and pass data via an HTTP GET / POST. In many cases this is through entry points that were never meant to be exposed external to the application.
While it is possible for apps to lock down their entry points, it is uncommon in practice. This is likely because the required validation is tedious to implement across an application and provides little immediate reward. There are also some unintended consequences of server-side approaches, such as breakage related to bookmarked pages in the browser.
Nevertheless, it is clear that the porous boundaries between web applications are a continual cause of security problems.
Entry Point Regulation (EPR)
One way to change things is to provide a browser-enforced mechanism for validating an entry point policy supplied with a web application. External references and navigations to non-entry points can then be restricted based on this policy.
Entry point regulation may be considered an implementation of concepts introduced by Charlie Reis et al. in App Isolation: Get the Security of Multiple Browsers with Just One.
Today I’m excited to release a prototype implementation of EPR as a Chrome extension. Code is available on GitHub.
Using EPR
As a web developer, implementing EPR on your site is reasonably straightforward. It involves three steps:
- Serve the following HTTP response header from your site:
X-EPR: 1 - Install the EPR prototype at the client to enable policy enforcement.
Sounds easy, eh? Well, there are a few details I’ve glossed over, so make sure to check out the EPR Prototype README for more information.
EPR Manifests
Manifests primarily contain a list of entry points as specified either by a regular expression or full string comparison of the URL path. Each entry point lists acceptable external reference types (navigation, image resource, script resource, xhr, etc.) as well as an allowData flag to permit data in the querystring, hash, or POST body.
Currently manifests apply for an entire fully qualified domain name, though in the future they may apply more granularly. Domains without manifests are not affected by EPR. However if an EPR manifest is present for a domain, externally initiated navigations and resource requests are subject to the manifest policy. Exceptions exist to allow free navigation to bookmarks or URLs typed in manually.
Manifests are cached at the client for a period of time specified in the manifest itself.
Where is EPR going?
There are various opportunities to pursue with EPR, and releasing the Chrome extension prototype is only the first step. Here are some ideas for future work:
- EPR seems like it would fit in well as a core feature in web browsers. Does it make sense to pursue the standardization of EPR in the web platform? As it stands, Installing a separate extension is a bit clunky.
- Is it possible to author tools that would enable the automatic creation of manifests? Annotations in web frameworks could facilitate automatic creation of EPR manifests.
- Use of EPR within Chrome apps to regulate access to highly sensitive web interfaces.
- Can EPR fit into the evolving security model of new web-based platforms?
While EPR surely isn’t a panacea for XSRF and reflected XSS, data we’ve collected indicates that it can make an impact for a decent portion of real-world web app vulnerabilities. I hope to share more research on the efficacy of EPR in a future blog post. In the meantime, play around with the Chrome extension and let me know what you think. Or even better, contribute to the code on GitHub and adapt it to fit your needs.
