This post describes how OWASP Top 10 - A6: Security Miconfiguration affects javascript applications. This is a wide category which covers a lot more than this blog post. I'll try to focus on the aspects that often occur in applications that rely heavily on JavaScript.
This is the risk rating from OWASP:
| Threat Agents | Attack Vectors | Security Weakness | Technical Impacts | Business Impacts | |
|---|---|---|---|---|---|
| ______ | Exploitability EASY |
Prevalence COMMON |
Detectability EASY |
Impact MODERATE |
______ |
| Consider anonymous external attackers as well as users with their own accounts that may attempt to compromise the system. Also consider insiders wanting to disguise their actions. | Attacker accesses default accounts, unused pages, unpatched flaws, unprotected files and directories, etc. to gain unauthorized access to or knowledge of the system. | Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, framework, and custom code. Developers and network administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc. | Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise. | The system could be completely compromised without you knowing it. All your data could be stolen or modified slowly over time. Recovery costs could be expensive. |
|
Running outdated software
Security vulnerabilites are discovered and fixed from time to time. This even happens in mature libraries like jQuery, but more often in plugins from less security focused developers. Whatever frameworks and libraries you decide to use, you need to make sure you review and maintain them over time.
Insecure default credentials
Some libraries use signatures to allow the server to validate that it was the origin of a given set of data. If the library comes with a default encryption key, it's of course highly insecure to use this value as it's available to everyone else as well. Default password yields similar problems.
Insecure use of APIs
A few years ago Adobe made it possible for a flash/flex application to read data from other websites given the websites. So a flash coming from website A canread data B. The prerequisite is that site B has a configuration file called crossdomain.xml. This file contains a list over domains which B trusts to read its data. Unfortunately this was very often misunderstood. And loads of sites deployed a crossdomain.xml file which was completely open, allowing a flash on a rogue site, to read authenticated data from a trusted site using the user's credentials. This was the topic of many blog posts, including some from yours truly.
Why is this relevant in the world of JavaScript? Well, modern browsers recently opened up for a similar communication pattern with cross domain XHR requests. JavaScript running on example.com can read authenticated data from anothersite.com, if anothersite.com returns the following headers:
X-Access-Controll-Allow-Origin: http://example.com X-Accss-Control-Allow-Credentials: trueThe first headers tell the browser that if the current site is
http://example.com, it is allowed to return the contents of the request to the javascript that made the request. The second header says example.com is allowed to include credentials like cookies, basic authentication headers or other credentials in the request.
Unfortunately several sites have already started using this in an insecure way. They use the following headers:
X-Access-Controll-Allow-Origin: * X-Accss-Control-Allow-Credentials: trueThis is exactly the same problems as with insecure crossdomain.xml. The site would now allows any javascript on any page to read authenticated data from the site using the user's credentials. So if I'm logged in to site
example.com which has these insecure headers, and I'm somehow tricked into visiting site evil.com (by visiting a shortened URL or similar), evil.com would now read data from example.com using my authenticated session. Not good. Fortunately for the sites having this config, Access-Control-Allow-Credentials: true cannot be combined with Access-Control-Allow-Origin set to *. The browser's will simply refuse to comply with this combination.
Similar things happen when using the new postMessage API. When using this API it's important to specify both the intended receiver and origin of the message being transmitted.
Mitigation
- Keep frameworks up to date
- Review and update libraries - even small plugins
- Replace default credentials with strong credentials - do not expose them to the client side
- Do not apply overly permissive security settings like the X-Access-Control-"death star"
