5 ms·
For 3rd party widgets, I actually prefer iframe for security. The same domain policy makes it more difficult for xss in the iframe to compromise the parent page
by davekt 13y ago
For 3rd party widgets, I actually prefer iframe for security. The same domain policy makes it more difficult for xss in the iframe to compromise the parent page. For HTML5 sandbox iframes, the security boundaries are even more strict and tunable.
There are some disadvantages to current iframes that Moot addresses like the lack of CSS cascading from parent page to iframe. The seamless iframe spec addresses this issue, but it's not widely adopted yet.
- tipiirai 13y agoMoot uses IFRAME for the authentication since that's the on that needs security.
- davekt 13y agoAn example attack iframes would make more difficult is XSS in the comment fields, e.g. an attacker bypasses sanitization and injects js into a page. With a sandbox iframe, the comments section could be restricted from compromising the top level page, e.g. stealing cookies, redirecting, etc.
- tipiirai 13y agoYou mean someone could put JS into the comment box and inject it into the page somehow?
- davekt 13y agoCorrect. If the 3rd party js properly sanitizes user input, this xss attack is moot. However, browsers love to eval stuff (http://html5sec.org/ http://html5sec.org/), and sandbox iframes provide good defense in depth. Secure programs like qmail have been using separate, sandboxed processes forever, but this secure design model has only recently been possible in the browser thanks to iframes and postMessage (http://www.cs.berkeley.edu/~devdatta/papers/LeastPrivileges.pdf http://www.cs.berkeley.edu/~devdatta/papers/LeastPrivileges....).
- tipiirai 13y agoThe client obviously strips out any SCRIPT/HTML tags from the input but I guess your're talking about something more clever here. Can you provide an example attack that could potentially pass our security?
- courtneycouch0 13y agoSanitization and protection from attacks is handled by the API itself instead of the client. We feel it's inherently risky to rely on the client at all for any security.
- davekt 13y agoThanks for responding. I would argue the opposite, that the browser is the safest place to sanitize because it better understands the context where user generated strings will be inserted. An example where the server may not understand the correct context occurs in this utf7 attack (http://html5sec.org/#charset http://html5sec.org/#charset). The server sanitizes the user input as utf8 where it passes. The client forces the browser to interpret the input as utf7 instead, and the string that was harmless as utf8 now becomes active js.
- tipiirai 13y agoThank you for this good example. We'll study this one more closely.
- bentlegen 13y agoIframes are easily spoofable. I can generate an iframe, style it exactly like your authentication page, and trick users into entering their username/password into my phony form. This is why mature platforms use dedicated windows for logging in (Facebook, Twitter, Disqus). I'd recommend you consider making this change.