Hot answers tagged

4

This bypasses the same origin policy, since the base-url is website.com, and script from evil.com is executed in website.com/iframeinjection. This is not correct. The open redirect vulnerability means that website.com redirects to evil.com. That means that the origin changes. The script is hosted on evil.com, and that is also the origin it will run in. So ...


3

Loading javascript in an iframe "automatically" protects the parent from unwanted changes with respect to some flavour of the Same Origin Policy that browsers adopt. So they limit the damage that a third party library can do when attempting to change your original web content; for example, they may modify an legitimate link to some other same-looking place ...


3

Imagine that the superSecretToken token was something retrieved from your service's server and was specific to the authenticated user. Or imagine that it was the user's bank balance. Then any random webpage on the internet could embed your page in an iframe, and whenever someone visited the attacker's page and happened to be logged into your service, the ...


2

Question 1: Are in this case WooCommerce, my website’s host, third party security, backup and other plugin providers considered as service providers in case I use URL redirection method or iFrame for payments? Meaning that they should be PCI DSS validated? Or does that apply only to the payment processor/gateway as others are not involved in ...


2

You allow the advertising partner’s code in the context of your page, giving it full access to the DOM and everything on the page. If the script is compromised and you load it there isn’t much you can do. There is however, a way to detect if the script you are including has been altered from a previously known state. This is called Subresource Integrity. ...


2

Use 2 separate hosts. On the IDE host deploy you services that provide IDE functionality: Editing of JavaScript, saving, comparing, etc. When user want to see how his code works, deploy it to another host, say USER host. Browser should load users code from this USER host and execute it. If you need to call some services on USER host from your IDE script, ...


2

Phishing isn't actually the main reason, although the scenario you describe doesn't work if you're trying to trick the user into thinking they're signed into a site and don't know what the site looks like for that user. Phishing isn't just used to steal credentials; it can also be used to trick a user into taking some action within their authenticated ...


1

Their best best is to turn on the X-Frame-Options header, as you mentioned. While pointing this out won't help your cause, the reality is that if they haven't had that header on then they have been vulnerable to various iframe-related attacks this entire time anyway. You trying to load their site in an iframe doesn't make them anymore vulnerable - it just ...


1

TL;DR: If the cookie you use can be used to authorize any action on site B, then that site becomes vulnerable to a CSRF attack. As @Sjoerd has already pointed out in his comment, you need to set the SameSite attribute of the cookie to None, otherwise the cookie won't be sent to site B when the image is retrieved. This could very well be a vulnerability, ...


Only top voted, non community-wiki answers of a minimum length are eligible