Skip to main content
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
Source Link

You said you are going to load the third-party content in an iframe, but will the third-party content be hosted from the same domain as your main content, or will it be served from a separate domain?

If the third-party content is hosted on the same domain as your main page, then no, your approach is totally insecure. Content in an iframe has full scripting access to the main page, if it is served from the same origin (roughly, the same domain). Read about the same-origin policy.

A more reasonable approach is to host the third-party extension content on a different domain than your main page. If you do this, then yes, your approach gives reasonable security. The extension content will be sandboxed and will be unable to mess with the main page (for the most part). There are some remaining risks, noted below:

  • The third-party content in the iframe can navigate the main page (e.g., by setting window.location or top.location). Thus, the third-party content replace the entire page with content of the third party's choosing. This might allow for phishing or spoofing attacks. An alert user might notice such attacks, because the URL in the browser's address bar will change, but some users might not notice.

  • The third-party extension can still load unsavory content in its own iframe (e.g., porn, ads, etc.).

  • The third-party extension can still try to mount drive-by download attacks on your users. If your users have a vulnerable browser, they might get infected by the attack (of course, this may be true if they visit any malicious site; there is nothing about iframes that increases the risk -- it just doesn't make it go away, either).

  • The third-party content can play movies or sound, possibly annoying users.

  • The third-party extension may be able to mount click-jacking attacks on the main page. (You mention that the iframe will be invisible, but I'm not sure exactly what are the specific methods needed to ensure that this is a robust defense against click-jacking. There are a lot of browser quirks out there.)

  • It is important that your site use strong CSRF defenses. Otherwise, the third-party content will be in a perfect position to mount CSRF attacks.

Many of these risks are relatively minor and may be acceptable in most cases, but I wanted to outline them for you and for others.

An alternate approach is to use a system for Javascript sandboxingJavascript sandboxing (these can also be thought of as a way to build a "virtual iframe"). See, e.g., Caja, SES, ADsafe, FBJS, and Microsoft's Web Sandbox.

You could also look at sandboxed iframes, but I don't think they're supported on all browsers, so you can't rely upon this mechanism for security yet (sadly).

See also What risks should I be aware of before allowing advertisements being placed on my website?What risks should I be aware of before allowing advertisements being placed on my website?, Security issues using iframesSecurity issues using iframes, How to scan Javascript for malicious code?How to scan Javascript for malicious code?.

Also, for details about browser quirks relating to the same-origin policy and that sort of topic, I highly recommend the Browser Security Handbook.

You said you are going to load the third-party content in an iframe, but will the third-party content be hosted from the same domain as your main content, or will it be served from a separate domain?

If the third-party content is hosted on the same domain as your main page, then no, your approach is totally insecure. Content in an iframe has full scripting access to the main page, if it is served from the same origin (roughly, the same domain). Read about the same-origin policy.

A more reasonable approach is to host the third-party extension content on a different domain than your main page. If you do this, then yes, your approach gives reasonable security. The extension content will be sandboxed and will be unable to mess with the main page (for the most part). There are some remaining risks, noted below:

  • The third-party content in the iframe can navigate the main page (e.g., by setting window.location or top.location). Thus, the third-party content replace the entire page with content of the third party's choosing. This might allow for phishing or spoofing attacks. An alert user might notice such attacks, because the URL in the browser's address bar will change, but some users might not notice.

  • The third-party extension can still load unsavory content in its own iframe (e.g., porn, ads, etc.).

  • The third-party extension can still try to mount drive-by download attacks on your users. If your users have a vulnerable browser, they might get infected by the attack (of course, this may be true if they visit any malicious site; there is nothing about iframes that increases the risk -- it just doesn't make it go away, either).

  • The third-party content can play movies or sound, possibly annoying users.

  • The third-party extension may be able to mount click-jacking attacks on the main page. (You mention that the iframe will be invisible, but I'm not sure exactly what are the specific methods needed to ensure that this is a robust defense against click-jacking. There are a lot of browser quirks out there.)

  • It is important that your site use strong CSRF defenses. Otherwise, the third-party content will be in a perfect position to mount CSRF attacks.

Many of these risks are relatively minor and may be acceptable in most cases, but I wanted to outline them for you and for others.

An alternate approach is to use a system for Javascript sandboxing (these can also be thought of as a way to build a "virtual iframe"). See, e.g., Caja, SES, ADsafe, FBJS, and Microsoft's Web Sandbox.

You could also look at sandboxed iframes, but I don't think they're supported on all browsers, so you can't rely upon this mechanism for security yet (sadly).

See also What risks should I be aware of before allowing advertisements being placed on my website?, Security issues using iframes, How to scan Javascript for malicious code?.

Also, for details about browser quirks relating to the same-origin policy and that sort of topic, I highly recommend the Browser Security Handbook.

You said you are going to load the third-party content in an iframe, but will the third-party content be hosted from the same domain as your main content, or will it be served from a separate domain?

If the third-party content is hosted on the same domain as your main page, then no, your approach is totally insecure. Content in an iframe has full scripting access to the main page, if it is served from the same origin (roughly, the same domain). Read about the same-origin policy.

A more reasonable approach is to host the third-party extension content on a different domain than your main page. If you do this, then yes, your approach gives reasonable security. The extension content will be sandboxed and will be unable to mess with the main page (for the most part). There are some remaining risks, noted below:

  • The third-party content in the iframe can navigate the main page (e.g., by setting window.location or top.location). Thus, the third-party content replace the entire page with content of the third party's choosing. This might allow for phishing or spoofing attacks. An alert user might notice such attacks, because the URL in the browser's address bar will change, but some users might not notice.

  • The third-party extension can still load unsavory content in its own iframe (e.g., porn, ads, etc.).

  • The third-party extension can still try to mount drive-by download attacks on your users. If your users have a vulnerable browser, they might get infected by the attack (of course, this may be true if they visit any malicious site; there is nothing about iframes that increases the risk -- it just doesn't make it go away, either).

  • The third-party content can play movies or sound, possibly annoying users.

  • The third-party extension may be able to mount click-jacking attacks on the main page. (You mention that the iframe will be invisible, but I'm not sure exactly what are the specific methods needed to ensure that this is a robust defense against click-jacking. There are a lot of browser quirks out there.)

  • It is important that your site use strong CSRF defenses. Otherwise, the third-party content will be in a perfect position to mount CSRF attacks.

Many of these risks are relatively minor and may be acceptable in most cases, but I wanted to outline them for you and for others.

An alternate approach is to use a system for Javascript sandboxing (these can also be thought of as a way to build a "virtual iframe"). See, e.g., Caja, SES, ADsafe, FBJS, and Microsoft's Web Sandbox.

You could also look at sandboxed iframes, but I don't think they're supported on all browsers, so you can't rely upon this mechanism for security yet (sadly).

See also What risks should I be aware of before allowing advertisements being placed on my website?, Security issues using iframes, How to scan Javascript for malicious code?.

Also, for details about browser quirks relating to the same-origin policy and that sort of topic, I highly recommend the Browser Security Handbook.

added 936 characters in body; added 250 characters in body
Source Link
D.W.
  • 100.6k
  • 34
  • 282
  • 617

You said you are going to load the third-party content in an IFRAMEiframe, but will the third-party content be hosted from the same domain as your main content, or will it be served from a separate domain?

If the third-party content is hosted on the same domain as your main page, then no, your approach is totally insecure. Content in an IFRAMEiframe has full scripting access to the main page, if it is served from the same origin (roughly, the same domain). Read about the same-origin policy.

A more reasonable approach is to host the third-party extension content on a different domain than your main page. If you do this, then yes, your approach gives reasonable security. The extension content will be sandboxed and will be unable to mess with the main page (for the most part). There are some remaining risks, noted below:

  • The third-party content in the IFRAMEiframe can navigate the main page (e.g., by setting window.location or top.location). Thus, the third-party content replace the entire page with content of the third party's choosing. This might allow for phishing or spoofing attacks. An alert user might notice such attacks, because the URL in the browser's address bar will change, but some users might not notice.

  • The third-party extension can still load unsavory content in its own IFRAMEiframe (e.g., porn, ads, etc.).

  • The third-party extension can still try to mount drive-by download attacks on your users. If your users have a vulnerable browser, they might get infected by the attack (of course, this may be true if they visit any malicious site; there is nothing about IFRAMEsiframes that increases the risk -- it just doesn't make it go away, either).

  • The third-party extensioncontent can play movies or sound, possibly annoying users.

  • The third-party extension may be able to mount click-jacking attacks on the main page. (You mention that the IFRAMEiframe will be invisible, but I'm not sure exactly what are the specific methods needed to ensure that this is a robust defense against click-jacking. There are a lot of browser quirks out there.)

  • It is important that your site use strong CSRF defenses. Otherwise, the third-party content will be in a perfect position to mount CSRF attacks.

Many of these risks are relatively minor and may be acceptable in most cases, but I wanted to outline them for you and for others.

An alternate approach is to use a system for Javascript sandboxing (these can also be thought of as a way to build a "virtual iframe"). See, e.g., Caja, SES, ADsafe, FBJS, and Microsoft's Web Sandbox.

You could also look at sandboxed iframes, but I don't think they're supported on all browsers, so you can't rely upon this mechanism for security yet (sadly).

See also What risks should I be aware of before allowing advertisements being placed on my website?, Security issues using iframes, How to scan Javascript for malicious code?.

Also, for details about browser quirks relating to the same-origin policy and that sort of topic, I highly recommend the Browser Security Handbook.

You said you are going to load the third-party content in an IFRAME, but will the third-party content be hosted from the same domain as your main content, or will it be served from a separate domain?

If the third-party content is hosted on the same domain as your main page, then no, your approach is totally insecure. Content in an IFRAME has full scripting access to the main page, if it is served from the same origin (roughly, the same domain). Read about the same-origin policy.

A more reasonable approach is to host the third-party extension content on a different domain than your main page. If you do this, then yes, your approach gives reasonable security. The extension content will be sandboxed and will be unable to mess with the main page (for the most part). There are some remaining risks, noted below:

  • The third-party content in the IFRAME can navigate the main page (e.g., by setting window.location or top.location). Thus, the third-party content replace the entire page with content of the third party's choosing. This might allow for phishing or spoofing attacks. An alert user might notice such attacks, because the URL in the browser's address bar will change, but some users might not notice.

  • The third-party extension can still load unsavory content in its own IFRAME (e.g., porn, ads, etc.).

  • The third-party extension can still try to mount drive-by download attacks on your users. If your users have a vulnerable browser, they might get infected by the attack (of course, this may be true if they visit any malicious site; there is nothing about IFRAMEs that increases the risk -- it just doesn't make it go away, either).

  • The third-party extension can play movies or sound, possibly annoying users.

  • The third-party extension may be able to mount click-jacking attacks on the main page. (You mention that the IFRAME will be invisible, but I'm not sure exactly what are the specific methods needed to ensure that this is a robust defense against click-jacking. There are a lot of browser quirks out there.)

  • It is important that your site use strong CSRF defenses. Otherwise, the third-party content will be in a perfect position to mount CSRF attacks.

Many of these risks are relatively minor and may be acceptable in most cases, but I wanted to outline them for you and for others.

You said you are going to load the third-party content in an iframe, but will the third-party content be hosted from the same domain as your main content, or will it be served from a separate domain?

If the third-party content is hosted on the same domain as your main page, then no, your approach is totally insecure. Content in an iframe has full scripting access to the main page, if it is served from the same origin (roughly, the same domain). Read about the same-origin policy.

A more reasonable approach is to host the third-party extension content on a different domain than your main page. If you do this, then yes, your approach gives reasonable security. The extension content will be sandboxed and will be unable to mess with the main page (for the most part). There are some remaining risks, noted below:

  • The third-party content in the iframe can navigate the main page (e.g., by setting window.location or top.location). Thus, the third-party content replace the entire page with content of the third party's choosing. This might allow for phishing or spoofing attacks. An alert user might notice such attacks, because the URL in the browser's address bar will change, but some users might not notice.

  • The third-party extension can still load unsavory content in its own iframe (e.g., porn, ads, etc.).

  • The third-party extension can still try to mount drive-by download attacks on your users. If your users have a vulnerable browser, they might get infected by the attack (of course, this may be true if they visit any malicious site; there is nothing about iframes that increases the risk -- it just doesn't make it go away, either).

  • The third-party content can play movies or sound, possibly annoying users.

  • The third-party extension may be able to mount click-jacking attacks on the main page. (You mention that the iframe will be invisible, but I'm not sure exactly what are the specific methods needed to ensure that this is a robust defense against click-jacking. There are a lot of browser quirks out there.)

  • It is important that your site use strong CSRF defenses. Otherwise, the third-party content will be in a perfect position to mount CSRF attacks.

Many of these risks are relatively minor and may be acceptable in most cases, but I wanted to outline them for you and for others.

An alternate approach is to use a system for Javascript sandboxing (these can also be thought of as a way to build a "virtual iframe"). See, e.g., Caja, SES, ADsafe, FBJS, and Microsoft's Web Sandbox.

You could also look at sandboxed iframes, but I don't think they're supported on all browsers, so you can't rely upon this mechanism for security yet (sadly).

See also What risks should I be aware of before allowing advertisements being placed on my website?, Security issues using iframes, How to scan Javascript for malicious code?.

Also, for details about browser quirks relating to the same-origin policy and that sort of topic, I highly recommend the Browser Security Handbook.

Source Link
D.W.
  • 100.6k
  • 34
  • 282
  • 617

You said you are going to load the third-party content in an IFRAME, but will the third-party content be hosted from the same domain as your main content, or will it be served from a separate domain?

If the third-party content is hosted on the same domain as your main page, then no, your approach is totally insecure. Content in an IFRAME has full scripting access to the main page, if it is served from the same origin (roughly, the same domain). Read about the same-origin policy.

A more reasonable approach is to host the third-party extension content on a different domain than your main page. If you do this, then yes, your approach gives reasonable security. The extension content will be sandboxed and will be unable to mess with the main page (for the most part). There are some remaining risks, noted below:

  • The third-party content in the IFRAME can navigate the main page (e.g., by setting window.location or top.location). Thus, the third-party content replace the entire page with content of the third party's choosing. This might allow for phishing or spoofing attacks. An alert user might notice such attacks, because the URL in the browser's address bar will change, but some users might not notice.

  • The third-party extension can still load unsavory content in its own IFRAME (e.g., porn, ads, etc.).

  • The third-party extension can still try to mount drive-by download attacks on your users. If your users have a vulnerable browser, they might get infected by the attack (of course, this may be true if they visit any malicious site; there is nothing about IFRAMEs that increases the risk -- it just doesn't make it go away, either).

  • The third-party extension can play movies or sound, possibly annoying users.

  • The third-party extension may be able to mount click-jacking attacks on the main page. (You mention that the IFRAME will be invisible, but I'm not sure exactly what are the specific methods needed to ensure that this is a robust defense against click-jacking. There are a lot of browser quirks out there.)

  • It is important that your site use strong CSRF defenses. Otherwise, the third-party content will be in a perfect position to mount CSRF attacks.

Many of these risks are relatively minor and may be acceptable in most cases, but I wanted to outline them for you and for others.