WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#40476 closed defect (bug) (duplicate)

$_POST values ' and \ for sure are getting escaped with a slash

Reported by: Jossnaz Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Bootstrap/Load Keywords:
Focuses: Cc:

Description

this is not a feature! it cannot be that wordpress just dumps his own shit into whatever it feels like, in this case, $_POST

full thread:

http://stackoverflow.com/a/2512993/533426

quote:

I don't think this applies in your case, but I was just having a similar problem. I was loading a Wordpress install along with a site so I could show recent posts on all pages. It turns out Wordpress escapes all $_POST vars, no matter what magic_quotes are set to.

I mention it because it was frustrating to figure out, and googling for an answer brought me here.

Here's how I fixed it in my case:

<?php
$temp_POST = $_POST;
require '../www/wp_dir/wp-load.php'; // loading wordpress
$_POST = $temp_POST;

==

please fix this or at least make it configurable to make it backwards compatible

Change History (3)

#1 @dd32
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Hi @Jossnaz,

Unfortunately this is a "feature", even though all of us - including all of the core developers I'm aware of, would prefer it wasn't.

Back in the day, many many moons ago, WordPress blindly followed PHP in accepting that all of the superglobal values should be slashed.
PHP later did a reversal on the idea to something more sane which you see today, but the damage was done, WordPress as an application had existed for long enough, and there were enough existing plugins and themes relying upon WordPress creating a sane single environment that WordPress also changing would cause irreparable damage to those sites - introduce security vulnerabilities, mangle content, and a bunch of other fun things.

#18322 is our ticket for tracking this and getting to something more sane - in the shortterm (and longer term) we'd request that if you're accessing $_POST variables you do it as such: $myvar = wp_unslash( $_POST['variable'] ); so that one day, we'll be able to have $_POST as an unslashed array.

Here's how I fixed it in my case:
<?php
$temp_POST = $_POST;
require '../www/wp_dir/wp-load.php'; loading wordpress
$_POST = $temp_POST;

Please don't do that. You're just opening yourself to security issues, and unexpected things happening to your content where WordPress does expect the values to be slashed.

Instead, simply use wp_unslash(), and if you really need a copy of $_POST to operate on yourself, do it as such: $my_POST = wp_unslash( $_POST );.

I'm marking this as a duplicate of #18322 - there's lots of discussion there over the years for sanity.

#2 @dd32
3 years ago

I should also add - I expect you're doing this because you're trying to use an API endpoint for something, I'd highly suggest switching to using the REST API introduced with WordPress 4.7 instead, as it allows us to offer much more consistent experience to developers.

#3 @Jossnaz
3 years ago

is there an php lib to talk to the wordpress API endpoints?

btw something as simple as

<?php
apply_filter('the_content', $post->content);

how would you do that via rest api?

Note: See TracTickets for help on using tickets.