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...
