Steemit security check - iframe tricks
Iframes are tricky..
- Security vulnerbility
- Test on steemit.com
- More details
I noticed that some banking websites (eg. First Direct [HSBC UK], Lloyds homepage, Mediolanum, Poste Italiane, Deutsche Bank, ..) do not fully stop third party sites to embed their website in an iframe.
This means that an attacker could exploit a compromised website (eg. XSS) with a similar name or name that resembles one of a financial institution to load in a full page iframe the (eg. banking) website and overlap the credentials fields with fake input boxes to steal users' credentials.
In this example I simply edited the HTML code of Facebook on the client side (Chrome developer tools -> Edit as html) for the sake of argument. On a compromised site (eg. XSS) the attacker could simply inject a full screen iframe and the overlapping input fields.
if (window.top !== window.self) window.top.location.replace(window.self.location.href);
The problem with this is that simply using an iframe with "sandbox" attribute stops their redirecting script.
HOW TO FIX THE ISSUE:
You can just use the header X-FRAME-OPTIONS set to DENY or SAMEORIGIN to stop browsers from rendering your website inside an iframe.
WHAT ABOUT STEEMIT:
It seems like the guys at Steemit know what they are doing (I had no doubt :) ). The portal is not rendered in iframes. As you can see the header is set to "SAMEORIGIN":
Furthermore the use of iframe in posts is not allowed:
Let's now take a step back and take an insight into iframes..
Iframes are still around, and every indication shows they're here to stay.
They are a quick and safe way to embed content from other sites into your website.
There is thought a right way and a wrong way to use them.
Keep in mind though that cross-domain iframes still have the ability to trigger alerts, run plugins (malicious or otherwise), autoplay videos, and present submittable forms in an attempt to phish users' information.
Thankfully, the ability to restrict iframes is supported by all major browsers. It's called the sandbox attribute. With this attribute set on the iframe, the document inside the iframe cannot do any of the following even if it's from the same origin:
- Change the parent's URL
- Automatically triggered features (play a video, focus a form control, open pop-ups, new windows, or new tabs)
- Submit forms
- Run plug-ins (through embed, object, applet, ..)
- Use pointer lock
- Navigate its top-level browsing context
- Read cookies or local storage from the parent
As you determine what things your sandboxed iframe needs to perform you can enable just single features using: allow-same-origin, allow-top-navigation, allow-forms, allow-scripts, allow-popups and allow-pointer-lock.
One more piece of advice: do not use the iframe attribute "seamless" unless you know what you're doing. This attribute does way more than remove borders as you would think it does.
A seamless iframe has access to the parent document, even if it's cross origin. In essence, a seamless iframe acts as if it's just part of the parent document!
To just remove borders you can simply add to your iframe element:
Back to the vulnerability explored at the beginning of this article.. the best thing you can do to protect yourself is to prevent your site from being embedded as an iframe.
Nowadays every browser since IE8 supports the X-FRAME-OPTIONS response header. Send this header with its value set to DENY when the page is requested and browsers will refuse to render your website in an iframe. The other supported option is SAMEORIGIN, which allows the page to be embedded in an iframe only if the parent document is from the same domain (which presumably is also your code).
Special thanks to tinfoilsecurity
( If you liked this topic see also this post where I performed some security testing / reverse tabnabbing phishing attacks on Steemit and other social media platforms -- spoiler: interesting results! :D )