Support

Hey guys, does the "no formatting" option fix this?

I'm having the same issue with & nbsp ; - HTML formatting displays as a question mark diamond in Firefox because it's converting it beforehand, and no formatting converts the ampersand, so it literally says the nbsp text, rather than having a space.

Nope, still seems to be happening. Have looked through the source again - there's actually two separate issues.

Firstly, anything displayed in a textarea in the backend isn't being escaped. So if you enter &copy;, and save, you see the actual copyright icon in the textarea, because the source code just has &copy; rather than &amp;copy;. More importantly, if you enter something like </textarea>hello, the HTML breaks. Anything displayed in a textarea needs to be run through esc_textarea or something equivalent.

Secondly, back to the &copy; issue - if you enter that, then save, the database field contains &copy; correctly. However, the output on the front end gets run through html_entity_decode($value). If you run the php statement html_entity_decode('&copy;'), it outputs the non-UTF8 character for a copyright directly in the source - so it would display if you're not using the standard UTF-8 character set. It should just print out &copy; directly - html_entity_decode should only really be run on something that has already been processed with htmlentities, not the raw input.

Hi Elliot,

Due to the lack of response I think you must have misunderstood the importance of what I said above. This is no longer a minor issue - the lack of escaping in a textarea is a major security issue that must be fixed immediately.

Try creating a textarea custom field, and filling the following into it:

</textarea><script>document.location='http://www.google.com';</script>

You'll now be locked out of that page entirely, unless you disable javascript or edit the database directly. Allowing things like this (and this is a basic example) to be injected into the admin page by anyone who can access custom fields is a serious problem.

Line 40 of textarea.php needs to become:

echo '<textarea id="' . $field['name'] . '" rows="4" class="' . $field['class'] . '" name="' . $field['name'] . '" >' . esc_textarea($field['value']) . '</textarea>';

As for the other issue - there is no logical reason to use html_entity_decode when grabbing the value for inputs and textareas; this is simply a mistake and should be removed. It does not do anything in terms of necessary escaping; all it does it convert some correct characters to incorrect ones. It can be safely removed without affecting anyone's site negatively.

No, esc_textarea is just for when the content is displaying inside a textarea somewhere and ensures what you enter gets saved exactly as typed. If you're using a field with the HTML formatting chosen and want it to display on the frontend, you want it to display exactly as entered - no escaping should be necessary at that stage.

Hi @TripleM

I would love to get your help on this. You seem to know exactly what to do.

Can you post the code fixes necessary for better textarea / content escaping?

Thanks

I already have.

http://support.advancedcustomfields.com/discussion/comment/7496#Comment_7496 contains the code for the textarea / security hole fix.

http://support.advancedcustomfields.com/discussion/comment/5147#Comment_5147 says all you need to do for the other bug is remove the html_entity_decode function. That's in both textarea.php and text.php, get_field_for_api functions, when format is 'html'.

Great work @TripleM

I've made both your changes to the next version!

Thanks for your patience and support.

Cheers
Elliot