The year 2014 has been a year of insecurity. There have been some pretty serious breaches and some really nasty security vulnerabilities that have put a substantial number of user credentials at risk.

In April there was the Heartbleed Bug, which left a substantial chunk of all Internet sites vulnerable to exposing not only usernames and passwords, but all data exchanged with vulnerable sites.

In May, attackers “compromised a small number of employee log-in credentials” at eBay. The attackers then leveraged these employee credentials to access a database containing “eBay customers’ name, encrypted password, email address, physical address, phone number and date of birth.” All eBay users were asked to change their password, indicating a potential compromise of all of eBay’s 145 million active users.

Most recently, in August, Hold Security has revealed the largest breach of user credentials of all time. Hold Security claims that a cybergang, they have dubbed CyberVor, was able to collect over 4.5 billion records – “1.2 billion of these credentials appear to be unique, belonging to over half a billion e-mail addresses”!

With all that has happened this year, it is time to change your passwords. And this is a good time to talk about password best practices:

• You should use a unique password for each login.
• Passwords should consist of uppercase, lowercase, numbers and special characters.
• They also should be at least 8 characters long.

“Surely, you’re joking,”, you say, “isn’t there a Dilbert comic about this?” Actually, the Dilbert comic is LESS restrictive. Unfortunately, this isn’t a joke. As computing power has gotten stronger, it has become easier to crack passwords requiring more and more complex passwords.

However, there is a solution! Use a password management tool such as LastPass or 1Password. Password management tools allow you to use a single password to access the tool. From there, the tool will generate passwords and store them securely. Both of these tools can be used for free in your browser of choice. However, if you want to use them on your phone, you will have to buy a premium license of $12 or $9.99 respectively.

Recently, I’ve run across some applications using Cross Origin Resource Sharing (CORS). I needed to study up on the topic and realized this is a feature that needs to be implemented with care. Below I’ve document what I learned in hopes that it will help others.

What is Cross Origin Resource Sharing?

Cross Origin Resource Sharing is a method of sharing data between two domains using JavaScript with HTTP headers under the hood. This normally would not be allowed due to the Same Origin Policy. However, developers often need the ability to share data between two domains(websites) and thus Cross Origin Resource Sharing was added with the release of HTML 5.

How Do I use Cross Origin Resource Sharing?

A very good explanation of the details of using CORS is explained here: https://www.html5rocks.com/en/tutorials/cors/. At a high level, you use JavaScript to make a request to another domain. The second domain responds with special headers that specify the authorization policy. If the request is authorized, the resource requested is returned to the page with the headers. Then JavaScript event handlers are triggered to handle the processing of the data.

Security Concerns

When setting your CORS policy, you must configure a policy that makes sense for the data and functionality that is specific to your website and the needs of the business. The key concerns are:

1. Don’t enable CORS on resources you don’t want to share across domains.
2. Only grant access to domains that need access.
3. If the data is sensitive, use appropriate supporting controls:
   1. Use authentication and the “withCredentials” property.
   2. Use a secure (HTTPS) connection.

By following the principle of least privilege and using the correct level of authorization for the data that is being returned these risks can be avoided.

Security Solutions

Use the following features of CORS to avoid security concerns (2) and (3A).

Access-Control-Allow-Origin

Access-Control-Allow-Origin: *

This policy states that any other website can pull information from the responding website. Instead you should specify a specific domain with which you explicitly want to share data. Example:

Access-Control-Allow-Origin: https://securio.us

Additionally, the server should be configured to only respond to CORS requests for specific resources that you want to share. So, rather than setting up CORS requests for an entire domain (ex: https://securio.us), only setup Cross Origin Resource Sharing on a specific page (ex: https://securio.us/public). There isn’t really a “one size fits all” approach because different sites will need to share their data differently. If the site has no private data/functionality an open policy might actually make sense, though this is generally a bad idea as it is not future proof.

For example, today your site might consist of only public resources. However, if you decide to add a part of the site that . Its a best practice to explicitly state what data is allowed to have access and prevent some data that is public from getting out, than saying everything is open and allowing a lot of private data to leak out. Just keep in mind the security principle of least privilege and only allow access where it is needed.

withCredentials

What about when you have data or functionality that is sensitive, but you still want to make it accessible across domains? The “withCredentials” property can be used for just such a scenario.

xhr.withCredentials = true;

This will instruct the browser to send cookies with the request. Then, the server can verify that the request is authorized.

Summary

CORS can be used to solve a common problem in security. However, keep in mind that the Same Origin Policy was put in place to protect users. Cross Origin Resource Sharring should be used as a seasoning for your websites not the main course. Try not to get carried away in using it everywhere.

References

• Cross-Domain AJAX with Cross-Origin Resource Sharing
• Using CORS Tutorial

You may notice a drastic change in the look and feel of the site. We have recently migrated to Octopress. Octopress is a blog-aware platform that generates static websites based on the Markdown language. This makes editing posts on any text editor very easy. A static website is a site that consists of only HTML, CSS and some JavaScript. The only dynamic aspects of this site are comments and search. However, search is performed by Google and comments are done in a separate iFrame by Disqus. This dramatically reduces the security footprint of the website – a welcome architecture feature for a security blog.

More to come soon. Big thanks to @coryfoo for the recommendation to use Octopress.

Securio.us is a small consulting shop that specializes in web application security testing. Our testing methodology identifies vulnerabilities covered by the OWASP Top 10 and the WASC Threat Classification. Our consultants are GSEC certified. We test running applications and attempt to subvert security controls by manipulating application inputs. We gather the resulting vulnerabilities that we identify into a final report and walk through this document to be sure you understand the issues. Verification of findings may be added at an additional cost. We operate on a wide variety of languages, platforms and technologies. We can test web applications, web services, and mobile apps on iOS and Android.

We are located in the San Francisco Bay Area in California. If you would like to reach us, please contact us by phone at: 415.889.8815