Which is more secure - iframe or CORS - for creating a widget intended for embedding on 3rd party sites?

前端 未结 1 1529
名媛妹妹
名媛妹妹 2021-01-05 06:55

When building a widget that is designed to be embedded on 3rd party websites, there appear to be two schools of thought as to how to do it:

  • Use iframe
相关标签:
1条回答
  • 2021-01-05 07:21

    You might find this post interesting - How to protect widgets from forged requests:

    You don't want this [widget] to be vulnerable to CSRF so you write an iframe to the page. Based on the origin inheritance rules the parent site won't be able to read the CSRF token. However what about clickjacking (or likejacking )? Because of CSRF you must be within an iframe and there for the x-frame-options cannot help, and the same holds true for frame-busters

    Negatives of IFrame approach

    • Vulnerable to Clickjacking / Likejacking

    Negatives of DOM approach

    • Vulnerable to CSRF.
    • CORS headers on your server will be allowing access to either the whole world, or whole sites that are pre-registered with you. While this doesn't in itself present a vulnerability, care must be taken to make sure no sensitive information is made available (such as user data). There is no way to limit access to your widget only - you would be giving access to the whole Origin (i.e. protocol, domain and port).
    • As you are manipulating the DOM these objects would be accessible from the remainder of the page outside of your widget.

    Summary

    In the end it depends on the functionality of your widget. What is the consequence of the parent site automatically submitting the form or clicking a button on your widget under the context of the user? If there is a like or +1 button, the hosting page could be fraudulently promoting their site by making the like/+1 be registered with you without the user's knowledge or consent. This would apply to both approaches, only the attack method would differ (i.e. CSRF or Clickjacking).

    The accepted answer on the above post has a solution for CSRF vs Clickjacking:

    Clicking on the widget needs to open a pop-up window containing a new page -- an iframe is not good enough, it must be a new window -- which is entirely under the control of your web application. Confirm the action, whatever it is, on that page.

    Yes, this is somewhat inelegant, but the present Web security architecture doesn't give you any better options.

    In summary, the IFrame approach appears to have overall more security and implementing the popup window upon interaction mitigates the Clickjacking risk.

    0 讨论(0)
提交回复
热议问题