Thursday 26 December 2013

Mixed HTTPS content – Browser security blind spot?

HTTPS is based on trust. Most users of secure sites are aware that they should check their browser for a padlock, a green bar or some other visual indicator to show that their connection is secure and the identity of the site has been verified. If a site shows a security warning then many people would refuse to interact with it particularly if they planned to enter sensitive personal or financial information.

Self-signed certificates are sometimes used to avoid the cost and complexity of obtaining and setting up a certificate from a CA or for other reasons. To accommodate the use of self-signed and otherwise invalid certificates (expired, wrong domain etc) browsers allow the user to add an exception, either a temporary exception for the lifetime of the session or a permanent exception. Chrome stores the exception for the lifetime of the session (i.e until the last browser window is closed), Firefox shows a dialogue that suggests you may wish to make a permanent exception. Once the exception is added the page may be viewed but the https indicator has a red line through to remind the user that this isn't a 'safe' connection and might be subject to a man in the middle attack or other tampering.

Some users may decide that viewing a page over HTTPS is preferable to plain HTTP even when the browser indicates that the connection is unsafe/untrusted as the connection is at least encrypted and safe from simple eavesdropping as would be possible with HTTP. If they don't plan to exchange sensitive information with the site what harm could it do??

Herein lies a security issue.. Many modern webpages are more than simply a collection of resources from a single domain rendered together. Frequently the look, feel and functionality of a page comes courtesy of a number of resources (i.e CSS and javascript) that are fetched from domains other than the one you appear to be interacting with. If those resources are fetched from a domain where a security exception exists this simply isn't communicated to the user.

Example:

- The page at https://www.example.com is secured with strong encryption and it's identity is assured by an extended validation certificate from a reputable CA.

- The page at https://www.example.com includes javascript resources from https://assets.someotherdomain.com , CSS from https://cdn.anotherexample.com etc.

- We are able to control the victims DNS resolution (rogue wifi access point, layer 2 attack etc).

- The victim can be persuaded by social engineering to visit a fake https://assets.someotherdomain.com secured with a self-signed certificate and add a security exception. 

- When the victim visits https://www.example.com their browser will request the javascript from https://assets.someotherdomain.com at which point we can send any arbitrary script that exfiltrates data (HTML of page, cookies, tokens etc) or adds or changes content on the existing page. The browser will show all the window dressing to indicate that the connection is secure (green padlock etc).

I believe this is a security issue for several reasons:

- in order to determine the exact domains involved in the page load the source code of the page must be carefully inspected or 'developer tools' must be used to view the network resources, neither method is straightforward for an average user or foolproof.

- Many major websites (banking, commerce, financial services, online shops) include javascript from places that the average user won't have heard of (advertising networks, analytics companies, CDNs) making a social engineering attack that misrepresents the role of these third party domains more likely to succeed.

- A lot of users will not make the connection between an exception they added for some reason such as downloading a file or viewing some content and their later visit to their banks website or other place where they know to check for visual indicators that everything is secure.

- Although https://www.example.com is secured with a certificate that demonstrates the highest level of trust the other domains that are serving content for the page are not – Surely the browser should indicate the LEAST trusted content on the page??


 - When visiting a site secured with a self-signed certificate we are shown that the connection is non-secure (red line through https) but this isn't the case when including scripts from one?!? This is misleading.

This also leads to the related question of how secure these third party sites are.. Is an analytics company or an advertising network putting as much effort into security as your bank would?? Is your bank right to include javascript from these types of pages on an online banking login page?? Many of them do... 

No comments:

Post a Comment