2

We're building an app that requires the user to be able to input raw HTML (for a design template) and then be able to display that within SFDC. The challenge we've found in a security process is that we need to find a way to ensure that the HTML is stripped of any "unsafe" constructs.

While it's been recommended we utilize the ESAPI Validator getValidSafeHTML method...

http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Validator.html#getValidSafeHTML(java.lang.String, java.lang.String, int, boolean)

...that doesn't seem to be included in the ESAI SFDC suite...

http://code.google.com/p/force-dot-com-esapi

Any recommendations as to how we could leverage the ESAPI Validator getValidSafeHTML method within our app, or potentially another way to scrub our HTML to ensure safe constructs?

I wonder how SFDC does this, as it allows you to input raw HTML when creating email templates.

4
  • I started down this route a while back, even started porting some open source java model, but it was OTT for the situation and the force.com XML support didn't have enough manipulation methods to make it viable. Ended up just using rich text!
    – Matt Lacey
    Aug 17, 2012 at 0:06
  • 1
    Do the client-side HTML editors out there (FCKEditor, TinyMCE, etc) not offer this functionality? This seems like one area where you definitely do NOT want to reinvent the wheel. Please let us know how you end up tackling the issue, we're going to run into the same issue during our review.
    – jkraybill
    Aug 17, 2012 at 3:43
  • Seems that while some tools like FCKEditor do include this functionality, the code still needs to be scrubbed on the server-side as well. We're still on the hunt. Would be nice if someone just packaged this as a paid-for web service we could just ping: htmlpurifier.org.
    – user284
    Aug 17, 2012 at 12:26
  • Client side HTML editors might work, but are vulnerable to security concerns in that a malicious user could bypass them and submit directly to the server.
    – Ryan Guest
    Oct 23, 2012 at 22:18

1 Answer 1

2

Instead of stripping out the unsafe, have you thought about only including the safe constructs/tags instead? Sort of like a whitelist of what's OK. Reject everything else.

That way if something new and bad comes along you aren't vunerable. If something new and good comes along you can plan for it and update appropriately.

2
  • That's an good option, and a greate idea. We want users to be able to input essentially any HTML tags that would be good enough for, say, Gmail (they're known for doing a good job locking this down) in these HTML templates. We figured if SFDC allows you to put raw HTML in the Email Templates, we could do that too and leverage some stripping tool they would have. Not so much.Building a whitelist sounds like quite an endeavor though, any suggestions on where to get started if we were to go down that route?
    – user284
    Aug 17, 2012 at 0:04
  • @user284 - Obviously you can build a pretty exhaustive, lengthy list of html elements and attributes if you want, but I'd suggest doing some market research into what others are offering in this space. First google hit for me: support.onswipe.com/customer/portal/articles/…. Aug 17, 2012 at 1:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .