function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
vbadhwarvbadhwar 

Securely Allowing Customers to Upload/Create Arbitrary Javascript and HTML

 

If your web-application allows users to upload custom HTML and Javascript content (email templates, custom sites, attachments, etc.), you must ensure that adequate protections are in place to prevent users from launching XSS attacks (privilege escalation, data-leakage, cookie theft, etc.) against other users of the application. Additionally, if your application is vulnerable to CSRF, the attacks can be carried out by malicious (unauthenticated) users. 


There's a number of different approaches that be taken to address this security concern:


1) Alternate domain (Recommended)
Let’s say cookies are scoped to
https://app.site.com.  Even if customers can upload arbitrary content, you can always serve the content from an alternate domain that is outside of the scoping of any trusted cookies (session cookies and other sensitive information).  As an example, pages on https://app.site.com would reference customer-uploaded HTML templates as IFRAMES using a link to https://content.site.com/cust1/templates?templId=13&auth=someRandomAuthenticationToken

The authentication token would substitute for the session cookie since sessions scoped to app.site.com would not be sent to content.site.com.  This is exactly the method that salesforce.com uses for our content product.

2) Alternate syntax
Some products, like wiki’s, have an alternate syntax that can be used by clients to indicate particular markup and formatting.  This allows clients to format content without directly using HTML.  Server-side rendering is done to translate the non-HTML markup into safe HTML.  Many WYSIWYG editors support such alternate markup syntax.

3) Whitelisting
The last option that I’m aware of is to “sanitize” HTML input from users.  Basically, you maintain a whitelist of allowed tags, the allowed attributes for each tag, and validation/transform routines for each attribute and each tag.  HTML sanitization can be very complicated and this technique becomes heavily browser dependent.   You also have other practical problems like the handling of invalid and unparsable HTML.

The best example of this technique in the wild is Gmail.  I’d suggest sending an HTML email containing every possible HTML tag, each with every possible HTML attribute, to a Gmail account and reviewing the changes that Gmail makes on the HTML delivered to the user.   You’ll see that there is a significant amount of logic that goes into sanitizing HTML.  It is a hard problem to fix correctly.


 

Best Answer chosen by Admin (Salesforce Developers) 
Brian SobyBrian Soby

Hi Laurent,

 

I'll break out your questions individually:

 

- How to display user's field keeping their formatting without breaking the security rules?

 

It sounds like you want to use the rich text field type for the description.  On save, rich text fields will be sanitized automatically and only the minimal set of HTML tags and attributes necessary for rich text formatting will be saved to the data store.  It's extremely difficult to do this sanitization safely with regular text fields that are output using escape=false.

 

- Is it really a security problem if the field can only be edited in the back office by logged-in users?

 

Yes.  The ability to create arbitrary HTML that will be rendered by another user's browser effectively gives authoring users the ability to impersonate other users.  This is commonly referred to as stored cross site scripting.

All Answers

LaurentDelcLaurentDelc

Hi,

 

I read your solutions and although they seem more appropriate for general Web application than for Saleforce specifically I learnt a lot.

 

Now I have a problem that seems simple at first:

- We want our customer to enter an object description. we are using richText attribute of VF (like this:  

<apex:inputTextarea id="et" richText="true" value="{!rejectionMessage.Message__c}"/>

 

)

 

- we want to display this on Site keeping the formatting.

- we are using escape="false". I read that it opens XSS breach, and they are indeed spotted each time by the Force.com security scanner. Now, every solution I read on security documents don't seem to fit. I tried HTMLENCODE, JSENCODE and JSINHTMLENCODE but it just removes the formatting.

 

So I have two questions:

- How to display user's field keeping their formatting without breaking the security rules?

- Is it really a security problem if the field can only be edited in the back office by logged-in users? In the example they only give obvious examples like:

 

<apex:outputText escape="false" value="{!$CurrentPage.parameters.userInput}" />

 

 

But what about data that comes from back office database?

 

Cheers,

 

Laurent, learning a lot about security right now

Brian SobyBrian Soby

Hi Laurent,

 

I'll break out your questions individually:

 

- How to display user's field keeping their formatting without breaking the security rules?

 

It sounds like you want to use the rich text field type for the description.  On save, rich text fields will be sanitized automatically and only the minimal set of HTML tags and attributes necessary for rich text formatting will be saved to the data store.  It's extremely difficult to do this sanitization safely with regular text fields that are output using escape=false.

 

- Is it really a security problem if the field can only be edited in the back office by logged-in users?

 

Yes.  The ability to create arbitrary HTML that will be rendered by another user's browser effectively gives authoring users the ability to impersonate other users.  This is commonly referred to as stored cross site scripting.

This was selected as the best answer
LaurentDelcLaurentDelc

Thanks for your answer.

 

We will probably go with Rich Text, but this solution has 3 major holes if I followed right:

- you cannot change a field from text to Rich text. Wich means we  will have to duplicate each field and migrate our Customers' data from the old to the new Rich text field. Quite a task!

- Rich Text are in Beta mode, which probably means it is still risky to use in production.

- They are still not supported by Eclipse which only supports up to version 16 of the API.

 

Thanks anyway.

 

Laurent