Is sanitization required for front end form?

• Baptiste

• May 20, 2020 at 7:46 am

I’m sorry, I realise i’m reviving an old topic but it seems quite important, and i’m a bit confused now : since wp_kses_post is now used by default on $_POST, i’m not sure what is the point of what @sododesign suggests (on December 8 2015) ?

What am i missing here ? Does it mean the default wp_kses_post doesnt deal with repeater fields correctly ?

Do we still need to worry about ACF front-end forms input sanitization or is it fully and reliably taken care of with thanks to the kses parameter ?

• ManxStef

• June 18, 2020 at 3:43 am

@baptistelegrand: Do we still need to worry about ACF front-end forms input sanitization or is it fully and reliably taken care of with thanks to the kses parameter ?

As far as I’m aware, the advice by the WordPress VIP team still applies. In particular, they recommend that you always escape as late as possible, ideally as data is being outputted, for the following reasons (amongst others):

• Something could inadvertently change the variable between when it was firstly cast and when it’s outputted, introducing a potential vulnerability.
• Future changes could refactor the code significantly. We review code under the assumption that everything is being output escaped/cast – if it’s not and some changes go through that make it no longer safe to output, we may incorrectly allow the code through, since we’re assuming it’s being properly handled on output.
• Escaping/casting on output simply removes any ambiguity and adds clarity (always develop for the maintainer).

So generally it’s an excellent idea to always escape/typecast things right at output in your templates. The code might not look quite as clean, but the reassurance that it’s guaranteed safe is worth it and goes a long way to ensuring durable, reliable code.

Personally, I’d also always be as specific as possible when it comes to escaping. If it’s always going to be output as an integer? Cast it as an integer. Outputting a URL? Use esc_url. There’s more info at Validating Sanitizing and Escaping User Data.

If you’d like to see how things can be exploited if things aren’t escaped correctly, I’d recommend reading through some of RIPSTech’s vulnerability reports, such as from their 2018 WordPress Exploits advent calendar and their blog’s wordpress-specific exploit posts. (Hopefully these links won’t all die now they’ve been bought by SonarSource, but if so they should still be on the WayBack Machine.)

In particular, this article is an excellent examination of how they exploited weaknesses in the wp_filter_post_kses function to leverage a CSRF to Remote Code Execution in the WordPress 5.1 Core. It’s impressive stuff:

The difference between wp_filter_post_kses() and wp_filter_kses() lies in their strictness. Both functions take in the unsanitized comment and leave only a selected list of HTML tags and attributes in the string. Usually, comments are sanitized with wp_filter_kses() which only allows very basic HTML tags and attributes, such as the tag in combination with the href attribute.

This allows an attacker to create comments that can contain much more HTML tags and attributes than comments should usually be allowed to contain. However, although wp_filter_post_kses() is much more permissive, it still removes any HTML tags and attributes that could lead to Cross-Site-Scripting vulnerabilities.

The fact that we can inject additional HTML tags and attributes still leads to a stored XSS vulnerability in the WordPress core. This is because some attributes that usually can’t be set in comments are parsed and manipulated in a faulty way that leads to an arbitrary attribute injection.

– https://blog.ripstech.com/2019/wordpress-csrf-to-rce/

So, do you really want to rely on wp_kses_post for all your validation? That’s perhaps not such a great idea. Be specific as possible if you can.