# Security considerations with displaying uploaded HTML

**URL:** <https://www.ruby-forum.com/t/security-considerations-with-displaying-uploaded-html/58140>\
**Category:** Rails\
**Created:** [April 18, 2006, 9:56pm UTC](https://www.ruby-forum.com/t/security-considerations-with-displaying-uploaded-html/58140 "2006-04-18T21:56:42Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\
**Post date:** [April 18, 2006, 9:56pm UTC](https://www.ruby-forum.com/t/security-considerations-with-displaying-uploaded-html/58140/1 "2006-04-18T21:56:42Z")

</div>

I have an application where I am allowing users to upload (or refer the  
app. to) arbritrary HTML that I am (currently) displaying in an IFRAME  
on a page. The users will be authenticated so it’s not open to the  
entire universe.

I was always uneasy with this, but after reading the security chapter of  
AWDWR, I am even more concerned.

What kinds of applications do people have out there that provide  
snippets of HTML that could be user provided?

I saw something in AWDWR about sanitize() - any comments/advice on that?

One thing I’m considering is rendering it on the server side and  
providing an image of the rendered to the user - then I only have to  
worry about being compromised on my server instead of worrying about XSS  
attacks. Does that make sense?

Any thoughts or advice is appreciated.

Wes

---

<div class="post-metadata">

**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\
**Post date:** [April 18, 2006, 10:51pm UTC](https://www.ruby-forum.com/t/security-considerations-with-displaying-uploaded-html/58140/2 "2006-04-18T22:51:42Z")

</div>

2006/4/18, Wes G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> One thing I’m considering is rendering it on the server side and  
> providing an image of the rendered to the user - then I only have to  
> worry about being compromised on my server instead of worrying about XSS  
> attacks. Does that make sense?

Personally I’d be more worried about the server being compromised than  
XSS, so I wouldn’t consider that an option.

> I have an application where I am allowing users to upload (or refer the  
> app. to) arbritrary HTML that I am (currently) displaying in an IFRAME  
> on a page. The users will be authenticated so it’s not open to the  
> entire universe.

Most HTML and CSS shouldn’t be able to affect you outside the IFRAME.  
I’d remove all meta, link and script tags. The main worry would be  
JavaScript, so also get rid of on\*=“” attributes, and probably filter  
hyperlinks which start with the javascript: protocall too… which  
come to think of it is what sanitize() does (except for the meta tags,  
I’d try and protect against a stupid meta-refresh too).

If you serve the content of the IFRAME from a different domain that  
should trigger more security from the browser, which should block most  
things.

hth,  
Douglas

---

<div class="post-metadata">

**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\
**Post date:** [April 19, 2006, 12:16am UTC](https://www.ruby-forum.com/t/security-considerations-with-displaying-uploaded-html/58140/3 "2006-04-19T00:16:10Z")

</div>

Douglas,

Thanks for this. The thing is that I need to be able to “preview” this  
HTML and show it to the user the way that it would look in a browser.

The problem is there are lots of pages now that do things like specify  
image tags and their contents via Javascript which means that stripping

 tags and/or on\* event handlers could potentially hobble the page. Wes Douglas L. wrote: \> 2006/4/18, Wes G. : \>\> \>\> One thing I'm considering is rendering it on the server side and \>\> providing an image of the rendered to the user - then I only have to \>\> worry about being compromised on my server instead of worrying about XSS \>\> attacks. Does that make sense? \>\> \> \> Personally I'd be more worried about the server being compromised than \> XSS, so I wouldn't consider that an option. \> \>\> I have an application where I am allowing users to upload (or refer the \>\> app. to) arbritrary HTML that I am (currently) displaying in an IFRAME \>\> on a page. The users will be authenticated so it's not open to the \>\> entire universe. \> \> Most HTML and CSS shouldn't be able to affect you outside the IFRAME. \> I'd remove all meta, link and script tags. The main worry would be \> JavaScript, so also get rid of on\*="" attributes, and probably filter \> hyperlinks which start with the javascript: protocall too... which \> come to think of it is what sanitize() does (except for the meta tags, \> I'd try and protect against a stupid meta-refresh too). \> \> If you serve the content of the IFRAME from a different domain that \> should trigger more security from the browser, which should block most \> things. \> \> hth, \> Douglas

---

<div class="post-metadata">

**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\
**Post date:** [April 19, 2006, 4:10am UTC](https://www.ruby-forum.com/t/security-considerations-with-displaying-uploaded-html/58140/4 "2006-04-19T04:10:18Z")

</div>

2006/4/19, Wes G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> The problem is there are lots of pages now that do things like specify  
> image tags and their contents via Javascript which means that stripping
> 
> tags and/or on\* event handlers could potentially hobble the page.

At least for IE, this might hep then:

[http://www.microsoft.com/technet/prodtechnol/ie/reskit/6/part2/c04ie6rk.mspx?mfr=true](http://www.microsoft.com/technet/prodtechnol/ie/reskit/6/part2/c04ie6rk.mspx?mfr=true)

“A content author can create a frame or IFRAME with the  
“security=restricted” attribute. This attribute puts the contents of  
the frame or IFRAME, as well as any child frames (initiated by parent  
frames) that it might contain, in the Restricted sites zone. For  
example, if the [http://a.com/](http://a.com/) Web page contains and the  
[http://b.com/](http://b.com/) Web page contains , both [http://b.com/](http://b.com/) and  
[http://www.microsoft.com/](http://www.microsoft.com/) will run in the Restricted sites zone. The  
frame cannot run scripting or ActiveX controls, unless the user  
changes the default settings for the Restricted sites zone or you used  
the Internet Explorer Customization Wizard to override the Restricted  
sites zone settings for the Internet Explorer installation. Also,  
support for Meta-refresh (a mechanism that allows a Web page to  
redirect to another Web page on a timer without using script) is  
disabled in the Restricted sites zone.”

I’m not sure how much security that gives you, and it will only be for  
IE, which isn’t exactly known for security, but that might be a help.  
Try and hack it and see! And hey, it turns off the meta-refresh too  
🙂

Douglas

---

<div class="post-metadata">

**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\
**Post date:** [April 19, 2006, 6:24am UTC](https://www.ruby-forum.com/t/security-considerations-with-displaying-uploaded-html/58140/5 "2006-04-19T06:24:20Z")

</div>

Douglas,

Again thanks! I found that right after your last post. I’ll do my  
best.

I’ll try and post any other stuff that I find out.

Wes

Douglas L. wrote:

> 2006/4/19, Wes G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):
> 
> > The problem is there are lots of pages now that do things like specify  
> > image tags and their contents via Javascript which means that stripping
> > 
> > tags and/or on\* event handlers could potentially hobble the page.
> 
> At least for IE, this might hep then:
> 
> [http://www.microsoft.com/technet/prodtechnol/ie/reskit/6/part2/c04ie6rk.mspx?mfr=true](http://www.microsoft.com/technet/prodtechnol/ie/reskit/6/part2/c04ie6rk.mspx?mfr=true)
> 
> “A content author can create a frame or IFRAME with the  
> “security=restricted” attribute. This attribute puts the contents of  
> the frame or IFRAME, as well as any child frames (initiated by parent  
> frames) that it might contain, in the Restricted sites zone. For  
> example, if the [http://a.com/](http://a.com/) Web page contains and the  
> [http://b.com/](http://b.com/) Web page contains , both [http://b.com/](http://b.com/) and  
> [http://www.microsoft.com/](http://www.microsoft.com/) will run in the Restricted sites zone. The  
> frame cannot run scripting or ActiveX controls, unless the user  
> changes the default settings for the Restricted sites zone or you used  
> the Internet Explorer Customization Wizard to override the Restricted  
> sites zone settings for the Internet Explorer installation. Also,  
> support for Meta-refresh (a mechanism that allows a Web page to  
> redirect to another Web page on a timer without using script) is  
> disabled in the Restricted sites zone.”
> 
> I’m not sure how much security that gives you, and it will only be for  
> IE, which isn’t exactly known for security, but that might be a help.  
> Try and hack it and see! And hey, it turns off the meta-refresh too  
> 🙂
> 
> Douglas
