This site is an exploration of using a non-HTML-centric approach to the security issues that faced shortcodes in WordPress prior to version 4.2.3.
The goal is to explain (to myself at least) why the HTML-centric approach was adopted by core.
The non-HTML solution proposed here is almost certainly insecure. I have zero knowledge or experience in vulnerabilities and am only basing the code on the incomplete publicly available exploits that I’ve found – two, to be precise. There are presumably more.
The site is running a minimally patched WordPress 4.3.1, using a minimal child theme of the default TwentyFifteen theme. The files patched are “wp-includes/shortcodes.php” and “wp-includes/formatting.php” – the latter just having a useful enhancement to “esc_attr()”. All the changes are basically in “shortcodes.php”.
- Add filters (note this was originally capabilities, and then flags, but on implementation both seemed over-complicated and unnecessary) to shortcodes so that specially hardened shortcodes are available to contributors/authors (specifically users without ‘unfiltered_html’ capability), subject to KSES-like checks on post save. All other shortcodes are by default unavailable to such users and are escaped on post save.
- Replace shortcodes with placeholders as early as possible when processing/displaying content, so that the rest of the content-parsing filters don’t have to deal with their messy attributes.
- (Not implemented here). Make available an elective database update to fix sites with existing, compromised content. (This may have been the deal-breaker for core?)
The default core shortcodes are presumed to be hardened enough to be used by contributors/authors. (Note this only happened in 4.3.1 in the case of [caption].)
If you’d like to contact me to point out flaws, or to request an author login to test for vulnerabilities, please use the form below.