You've Been Framed. A survey of iframes and the sandbox attribute(debug.is)
debug.is
You've Been Framed. A survey of iframes and the sandbox attribute
http://www.debug.is/2015/04/15/youve-been-framed/
5 comments
This is why I think per-site security settings in the browser are a good thing. Regardless of whether it's in an iframe or not, if I haven't allowed some site to run scripts/use cookies/etc., it won't.
What are you using to get this granular control?
Opera (before they switched to WebKit/Blink) has per-site settings. IE has security zones (not per-site, but only a trusted/untrusted grouping.) Firefox can do it with extensions like NoScript, and I'm not familiar enough with Chrome or anything WebKit/Blink-based to know whether it can be done.
The µMatrix plugin for Chrome provides fairly granular control over content requests and javascript execution.
Would it be possible to constantly scan the DOM for new iframes and add the attribute with JS? Seems like there might be a small window of opportunity though for bad things to happen, if it would even work.
here is a link to better docs site the article doesnt provide them:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
What are people thoughts on allowing (or how best to allow) users to embed iframes in rendered markdown text fields?
Assuming you're talking about `sandbox`, I'd be wary about that.
If nothing else, what happens if someone visits the site without support for `sandbox`? You best option (not displaying it if the browser doesn't support it) breaks the site for users without JS, or that don't have support `sandbox`.
If nothing else, what happens if someone visits the site without support for `sandbox`? You best option (not displaying it if the browser doesn't support it) breaks the site for users without JS, or that don't have support `sandbox`.
If you apply the sandbox attribute to the iframes it should be ok. It allows fine grained control of what the iframe is allowed to do. Scripts, navigation, popups, etc. are forbidden except explicitly allowed.
Also, please don't enable JS within the "sandbox".
JS is nowhere near as secure as it is often toted as being. You don't want to find yourself being host to a zero-day attack.
JS is nowhere near as secure as it is often toted as being. You don't want to find yourself being host to a zero-day attack.
I'd be wary about that.
If nothing else, what happens if someone visits the site without support for `sandbox`? You best option (not displaying it if the browser doesn't support it) breaks the site for users without JS, or that don't have support `sandbox`.
If nothing else, what happens if someone visits the site without support for `sandbox`? You best option (not displaying it if the browser doesn't support it) breaks the site for users without JS, or that don't have support `sandbox`.
Good point. But the sandbox attribute is around 90% [1] of browsers. The number of browsers which don't support it and don't run javascript may be too low to make supporting them practical, but YMMV.
[1] http://caniuse.com/#feat=iframe-sandbox
[1] http://caniuse.com/#feat=iframe-sandbox
It's IE 8 and 9 that I'd be most worried about in terms of malice.
And I'd be one of those users who would be cut out by JS requirements. Just so you know, that number is not zero.
And I'd be one of those users who would be cut out by JS requirements. Just so you know, that number is not zero.
Userify just removed all third party inclusions except CDN from the app itself. I wish more companies would do this.
What's the point of strong TLS if you're potentially leaking every click and keystroke to a third party?
Use Privacy Badger where you can: https://www.eff.org/privacybadger