7 ms·
The circumstances under which a clickjacking attack could be introduced to an otherwise secure site are quite narrow: 1. Attacked site use Javascript anti-fr
by A1kmm 14y ago
The circumstances under which a clickjacking attack could be introduced to an otherwise secure site are quite narrow:
1. Attacked site use Javascript anti-framing protection
(otherwise there is no benefit to the attacker in
disabling Javascript).
2. Attacked site doesn't use X-Frame-Options to prevent
framing (probably rare for the bigger sites these
days).
3. Attacked site allows the functionality under attack to
work even when Javascript is turned off. Many common
clickjack targets (e.g. Facebook Like buttons) don't
work at all with Javascript disabled.
4. Attacked form has effective CSRF protection tokens
placed in it server-side (otherwise it would be easier
to do a CSRF attack rather than CJ and get the same
result).
I think that the circumstances under which the attack would be possible might be quite rare compared to those in which the sandbox feature would be a benefit.
One protocol fix that might get the best of both worlds would be to add a new X-Frame-Options token that indicates that the sender of content 'consents' to it being framed in a no-script sandbox provided it is consistent with the other X-Frame-Options. If the embedding frame requests a sandbox, and the embedded content doesn't have the appropriate X-Frame-Options header allowing no-script embedding, the frame just displays a browser error.
- homakov 14y ago> One protocol fix that might get the best of both worlds it would be good unless following fact - many developers DONT follow HTML5 tricks, and vk.com is an example. They rely on framebreakers because it worked once and they DONT expect it to get broken someday.
- A1kmm 14y agoA protocol fix that meant that the server serving the content needed to opt in to no-script through a new X-Frame-Options header would mean that legacy content like vk.com wouldn't send a X-Frame-Options header, and so wouldn't be able to be framed in a no-script iframe.
- homakov 14y agoand nobody will use it. because in fact NOBODY wants to run their pages w/o JS. And this is why sandbox is a bad idea.
- tptacek 14y agoThe parent comment raises a very good point. Does the supposed VK.com CJ vector work at all with Javascript disabled? Disabling JS stops the framebreaker; does the site UI still work when you do that?
- homakov 14y agoyes it does. VK migrates "gracefully" and Like/friend/comment buttons work w/o JS. I'm sure you know that most of the Rails forms will work w/o JS as well.
- acdha 14y agoWhy is the answer not “HTML5 sandbox cannot compensate for non-security-minded developers”? After reading this and the discussion, the only thing which seems certain is that the vk.com developers need to set XFO.
- homakov 14y ago> HTML5 sandbox cannot compensate for non-security-minded developers framebreaker worked well until it sandbox was invented. If we should blame someone - it is rather W3C, not VK.