Add new RENDER_CONTENT_IFRAME_SANDBOX for the iframe sandbox when load html, Add RENDER_CONTENT_EXTERNAL_CSP for the external render Content-Security-Policy header

[lunny]

When render with RENDER_CONTENT_MODE with iframe, it in fact cannot render correct because the url of iframe is the same origin of parent window url. This PR adds new RENDER_CONTENT_IFRAME_SANDBOX for the iframe sandbox when load html, Add RENDER_CONTENT_EXTERNAL_CSP for the external render Content-Security-Policy header

[wxiaoguang]

My thought is: there could be two options (one RENDER_CONTENT_IFRAME_SANDBOX for the iframe sandbox, one RENDER_CONTENT_EXTERNAL_CSP for the external render Content-Security-Policy header).

Then users can customize everything if they want, they pay attention for their security and risks.

[lunny]

My thought is: there could be two options (one RENDER_CONTENT_IFRAME_SANDBOX for the iframe sandbox, one RENDER_CONTENT_EXTERNAL_CSP for the external render Content-Security-Policy header).

Then users can customize everything if they want, they pay attention for their security and risks.

Is that really necessary to have so many options for users?

[wxiaoguang]

Because there are even more options for sandbox and Content-Security-Policy. I do not think it's possible to enumerate all possibilities by introducing fixed options on Gitea side.

[lunny]

Because there are even more options for sandbox and Content-Security-Policy. I do not think it's possible to enumerate all possibilities by introducing fixed options on Gitea side.

Done.

[wxiaoguang]

This issue seems more complex than it looks like. More information here:

By default, the allow-same-origin should not be used, otherwise the attacker can render a malicious JS to do web requests as current user.

Since there is no allow-same-origin, then the parent iframe can not read the embedded document height directly, then there should be some JS code using postMessage to pass the height to parent to do the resize.

And there is no direct access to templates, so it's not easy to render the HTML and JS code by tmpl files, at the moment the HTML and JS code are embedded in Go code directly, which makes the code look hacky.

According to lunny, this PR could be set to WIP

[lunny]

@wxiaoguang Do you have further questions?

[wxiaoguang]

I didn't have any question. You suggested to put it in WIP.

[lunny]

I didn't have any question. You suggested to put it in WIP.

Yes, in that time. But now I think maybe we could consider to merge it.

[andrepearce]

What happen to this change? Is there any reason why it seems things have gone stale? As I think we are running into this exact issue currently.

[wxiaoguang]

I think the reason is:

• No real requirement before, no motivation, and I was told to put it in WIP after I made some tries, so I didn't spent more time on it.
• No 100% perfect solution for resizing external iframe, it needs to append JS code after the external </html>, so it would cause arguments and have obstacles, although I think it is fine.