Escape output in content template

This thread is resolved. Here is a description of the problem and solution.

Problem: I would like to apply Cross-Site Scripting prevention filters on the front-end of the site to
filter script tags out of custom field values. My posts were created by Gravity Forms.

Solution: Toolset's XSS filtering is applied at the time of data-entry, so we do not provide any front-end filtering of the content submitted by other systems. You could write your own custom filters in PHP, or you could try to set up your forms so that no malicious code can be added. Gravity Forms support may be able to provide some additional information about sanitizing their form inputs. I found this security whitepaper in their documentation - see below.

Relevant Documentation: https://docs.gravityforms.com/security-whitepaper/#a3-cross-site-scripting-xss-

This support ticket is created 6 years, 11 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun	Mon	Tue	Wed	Thu	Fri	Sat
8:00 – 12:00	8:00 – 12:00	8:00 – 12:00	8:00 – 12:00	8:00 – 12:00	-	-
13:00 – 17:00	13:00 – 17:00	13:00 – 17:00	13:00 – 17:00	13:00 – 17:00	-	-

Supporter timezone: America/New_York (GMT-04:00)

Tagged: Content Templates, Views, Views plugin

This topic contains 3 replies, has 2 voices.

Last updated by Christian Cox 6 years, 10 months ago.

Assisted by: Christian Cox.

Author

Posts

December 30, 2017 at 7:04 am #602250

cortJ

In case a script is injected into a types custom field which is a textarea, it gets executed in the page which uses the content template which displays the textarea as:

[types field="my-textarea"][/types]

How do we escape the output to prevent such attacks? We will have validation to strip the tag in the custom fields input area, but escaping the output is necessary. Shouldn't htmlspecialchars be applied by default when we use the above shortcode? Or is there an attribute for it?

Also, what do these unfiltered HTML options actually filter if disallowed?

Custom fields - unfiltered HTML
Allow saving unfiltered HTML in Types custom fields for users with higher roles
Disallow saving unfiltered HTML in Types custom fields for all users

We had it on 'Allow saving..'. I tried it on Disallow.. but it didn't make a difference. Should there be a difference?

Thanks.

December 31, 2017 at 9:01 pm #602378

Christian Cox

Hi, I'll be glad to assist.

In case a script is injected into a types custom field which is a textarea, it gets executed in the page which uses the content template
Are you referring to a field that is populated using a CRED form? We apply Cross-Site Scripting (XSS) attack prevention measures to all WYSIWYG fields in all CRED forms. If anyone attempts to submit script tags in a custom field here, those tags will be stripped out. Malicious scripts will not be saved with the post, and therefore will not be executed upon page load.

If you're referring to adding script tags directly to a custom field in the post editor screen, then yes - it's possible to insert script tags here that will be executed on page load if you choose "Allow..." in settings. With this setting, the custom field behaves like the standard post body editor - if you insert script tags, they will be saved. If you include those script tags in the output of your page, they will be executed. This is the standard behavior in the WordPress post body.

If you change "Allow..." to "Disallow..." in Toolset > Settings > Custom Content, then not even an administrator can save script tags in a custom field in wp-admin. Those script tags will be stripped out. However, neither of these settings will change the behavior of the standard post body editor. You can still insert script tags here, so it's very important that you restrict access to the wp-admin area effectively.

January 1, 2018 at 11:00 am #602423

cortJ

Thanks Christian.

No, we're not using CRED. Our front end form is currently based on Gravity Forms which saves the data into custom post fields from Types.

I was hoping to find a shortcode attribute or recommended function which would escape the output when displaying the custom fields in a content template or a view. Looks like there is no other way for this except for using htmlspecialchars() or WP's esc_html() manually?

January 2, 2018 at 9:54 pm #602801

Christian Cox

That's correct, we don't offer a built-in way to escape field content like this. You could write your own custom filters in PHP, or you could try to set up your forms so that no malicious code can be added. Gravity Forms support may be able to provide some additional information about sanitizing their form inputs. I found this security whitepaper in their documentation:
hidden link