Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why “Secure iframes” on HTTP Sites Are Bad for Security

DZone's Guide to

Why “Secure iframes” on HTTP Sites Are Bad for Security

Using HTTPS for your web apps has never been more critical. But what happens when you're serving that content in an iframe? Does it really matter? Read on for more.

· Security Zone
Free Resource

Discover an in-depth knowledge about the different kinds of iOS hacking tools and techniques with the free iOS Hacking Guide from Security Innovation.

Earlier this year it was reported that half of the web is now served over SSL (Wired.com). Still, quite a number of sites are trying to keep things in HTTP and to serve secure content in embedded parts of the site. There are two approaches to this:

  • A form embedded in an iframe served over https (not terrible but still a bad idea).
  • A form that loads over HTTP and submits over HTTPS (this is terrible).

The form loading on the HTTP site and submitting to an HTTPS site is, security-wise, meaningless, because an attacker can read the data entered into the form on the web page. This means the security added by HTTPS is lost because a Man-in-the-Middle attacker on the HTTP site can snoop on the data in the form directly.

ssl_safecontrols

Users are slowly but surely being trained to look for this padlock symbol and the “https” protocol when interacting with web pages and applications. 

The “secure iframe” is slightly better because the form is served over HTTPS and a Man-in-the-Middle cannot easily read the contents of the form. This is aided by iframe sandboxing in modern browsers (see some info about this in Chrome here), although old ones may not be as secure because the sandboxing function was not included. Client-side restrictions can, however, be manipulated.

One of the big problems with security is a lack of awareness about security risks. To counter this, browsers today indicate that login forms, payment forms, etc. on HTTP sites are insecure. If you load your iframe over HTTPS on an HTTP site, the browser will still warn the user (although the actual content is not submitted insecurely). This counteracts the learned (positive) behavior of looking for a green padlock symbol and the HTTPSprotocol. Two potentially bad effects of this are:

  • Users start to ignore the unison cry of “only submit data when you see the green padlock” – which will be great for phishing agents and other scammers. This may be “good for business” in the short run, but it certainly is bad for society as a whole, and for your business in the long run.
  • Users will not trust your login form because it looks insecure and they choose not to trust your site – which is good for the internet and bad for your business.

Takeaways from this:

  • Serve all pages that interact with users in any form over HTTPS.
  • Do not use mixed content on the same page. Just don’t do it.
  • While you are at it: don’t support weak ciphers and vulnerable crypto. That is also bad for karma and good for criminals.

Learn about the importance of a strong culture of cybersecurity, and examine key activities for building – or improving – that culture within your organization.

Topics:
security ,http ,https ,iframes ,web application security

Published at DZone with permission of Hakon Olsen, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}