tryretool / retool-embed

MIT License
3 stars 3 forks source link

Missing IFRAME sandbox attributes? #7

Open roncito opened 2 hours ago

roncito commented 2 hours ago

Hi All 👋

The Retool app we are trying to embed requires that allow-popups' and 'allow-forms' be set on the iframesandbox` attribute.

I see the sandbox attributes are set here: https://github.com/tryretool/retool-embed/blob/5b0741ddf77efee5748f5d9f69961507b49da9cb/src/RetoolEmbed.ts#L107

Is there a reason security-wise to not add these two sandbox attributes?

Thanks!

jasonrichelson commented 1 hour ago

Adding allow-popups and allow-forms to the sandbox attribute of an iframe introduces specific security considerations. It’s important to understand what each of these attributes does and why they might be restricted in certain contexts.

Explanation of Sandbox Attributes

1.  allow-scripts:
•   Allows the iframe to execute JavaScript. This is often necessary for embedded Retool apps to function but carries inherent risks if the iframe content is not trusted.
2.  allow-same-origin:
•   Grants the iframe access to the same-origin policy, meaning it can make requests to the parent domain. This is critical for Retool apps that interact with APIs or require user authentication.
3.  allow-popups:
•   Allows the iframe to open new browser windows or tabs via window.open(). Without this attribute, such actions are blocked.
4.  allow-forms:
•   Allows form submissions within the iframe. Without this, users cannot interact with forms inside the iframe.

Security Implications

Adding allow-popups

•   Potential Risk: Malicious or poorly coded scripts inside the iframe could open an excessive number of popups or redirect users to phishing websites.
•   Mitigation: Ensure the iframe content (Retool app) is trusted and does not include unvetted external scripts.

Adding allow-forms

•   Potential Risk: Enables potentially malicious forms to be submitted within the iframe, including hidden forms or forms targeting third-party APIs.
•   Mitigation: Verify that all forms within the Retool app are secure and validated. Consider user consent mechanisms for sensitive actions.

Why These Might Be Excluded by Default

The current sandbox attributes (allow-scripts and allow-same-origin) are likely set to balance functionality with security: • allow-scripts is essential for JavaScript-based functionality. • allow-same-origin is needed for the Retool app to interact with APIs.

Adding allow-popups and allow-forms can weaken the sandbox restrictions, which might expose the embedding application to: • Popup spam or phishing. • Unauthorized form submissions.

Considerations Before Adding allow-popups and allow-forms

1.  Trust Level of the Retool App:
•   Is the app fully controlled and reviewed by your team? If yes, the risks are lower.
2.  User Interaction:
•   Does the app genuinely require popups or form submissions? Avoid adding attributes unless absolutely necessary.
3.  Browser-Specific Behavior:
•   Test across browsers to ensure the app behaves as intended with and without these attributes.

Recommendations

If the Retool app absolutely requires these attributes:

  1. Add allow-popups and allow-forms to the sandbox attribute but ensure: • The Retool app is well-audited and contains no third-party scripts. • Any popups or form submissions are user-initiated and cannot be abused.
  2. Document this change with a clear justification and communicate it to stakeholders for transparency.
  3. Consider monitoring the iframe behavior (e.g., logging form submissions or popups) to detect potential misuse.

Suggested Code Change

Update the sandbox configuration as follows:

this.iframe.sandbox.add("allow-scripts", "allow-same-origin", "allow-popups", "allow-forms");

Document in Code Comments

Explain why these attributes are necessary:

// Adding 'allow-popups' and 'allow-forms' to support Retool app functionality. // Ensure the embedded app is trusted and well-audited to mitigate potential risks.

Final Note

While it’s not inherently unsafe to add these attributes in a trusted environment, always err on the side of caution. If possible, work with your security team to review the risks before making the change.