4 ms·

It seems like this class of attacks is based on embedding content that is not designed to be embedded in the first place. Wouldn't it in theory be possible to

by molf 12y ago

It seems like this class of attacks is based on embedding content that is not designed to be embedded in the first place. Wouldn't it in theory be possible to require browsers to send an "Embedded-On" HTTP header that contains the domain of the embedding page? Then it's trivial for a website (Facebook/Google in this case) to block all requests from unrecognised domains with HTTP 403 Forbidden – regardless of your login state. It only requires that website owners know which domains they themselves use.

xmodem 12y ago
This would appear to me to be the simplest way to allow this sort of attack to be blocked. Whether or not it opens up other avenues for attack is another question.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
zemnmez 12y ago
This isn't the case. Embedding a non-image as an image is only used to trip the CSP. If the X-Frame-Options header is not set to DENY or SAMEORIGIN, you can equally iframe the contents. CSP restrictions are capable of controlling almost any kind of content on a page. Here I used images for my own convenience because it makes the requests more simple; you can write similar rules for frames, scripts and other content and come up with similar category exploits with those rules. When it comes to Embedded-On, that is what the Origin header that is used in most modern browsers is for. It supersedes the privacy impinging Referer header. What you are describing is essentially 'hotlink' protection for generic resources.
- kretor 12y ago
  What does "This isn't the case." refer to?
  - zemnmez 12y ago
    > It seems like this class of attacks is based on embedding content that is not designed to be embedded in the first place. It's not the case that this type of attack hinges on the use of images.
- abritishguy 12y ago
  " If the X-Frame-Options header is not set to DENY or SAMEORIGIN", I see no reason why that header shouldn't be set.

by molf 12y ago

xmodem 12y ago

This would appear to me to be the simplest way to allow this sort of attack to be blocked. Whether or not it opens up other avenues for attack is another question.

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

zemnmez 12y ago

This isn't the case. Embedding a non-image as an image is only used to trip the CSP. If the X-Frame-Options header is not set to DENY or SAMEORIGIN, you can equally iframe the contents. CSP restrictions are capable of controlling almost any kind of content on a page. Here I used images for my own convenience because it makes the requests more simple; you can write similar rules for frames, scripts and other content and come up with similar category exploits with those rules. When it comes to Embedded-On, that is what the Origin header that is used in most modern browsers is for. It supersedes the privacy impinging Referer header. What you are describing is essentially 'hotlink' protection for generic resources.

kretor 12y ago
What does "This isn't the case." refer to?
- zemnmez 12y ago
  > It seems like this class of attacks is based on embedding content that is not designed to be embedded in the first place. It's not the case that this type of attack hinges on the use of images.
abritishguy 12y ago
" If the X-Frame-Options header is not set to DENY or SAMEORIGIN", I see no reason why that header shouldn't be set.