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.
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.
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?
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
