¿Por qué se escapan las variables $ _POST en PHP?

Question

Cuando mi script PHP recibe datos de una solicitud AJAX POST, se escapan las variables $_POST. Lo realmente extraño es que esto solo ocurre en mi servidor de producción (ejecutando PHP 5.2.12 en Linux) y no en mi servidor local (ejecutando PHP 5.3.1 en Windows). no

var pageRequest = false; 
if(window.XMLHttpRequest)  pageRequest = new XMLHttpRequest(); 
else if(window.ActiveXObject) pageRequest = new ActiveXObject("Microsoft.XMLHTTP"); 

pageRequest.onreadystatechange = function() { } 

var q_str = 'data=' + " ' "; 

pageRequest.open('POST','unnamed_page.php',true); 

pageRequest.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); 
pageRequest.setRequestHeader("Content-length", q_str.length); 
pageRequest.setRequestHeader("Connection", "close"); 

pageRequest.send(q_str); 

alguna razón esto está sucediendo:

Aquí está el código AJAX? ¿Y cómo debería solucionar esto para que funcione en ambos servidores?

Editar: Tengo la siguiente configuración para magic_quotes:

     Local Master 

magic_quotes_gpc  On  On 
magic_quotes_runtime Off  Off 
magic_quotes_sybase Off  Off 

Answer 1

es probable que tenga comillas mágicas habilitado en el servidor Linux: magic_quotes

Cuando magic_quotes están encendidas, todo '(comilla simple), "(comillas dobles), \ (barra invertida) y NUL se escapan con una barra invertida automáticamente.

Son una buena cosa para deshabilitar, ya que se eliminarán de PHP 6 en adelante de todos modos. También debería poder deshabilitarlos dentro de su secuencia de comandos: set-magic-quotes-runtime No puede desactivar la parte de magic_quotes responsable de escapar los datos POST durante el tiempo de ejecución. Si puede, desactívelo en php.ini. Si no puede hacer eso, hacer una comprobación de si los magic_quotes están habilitados, y hacer un stripslashes() en cualquier contenido que trae desde la POST:

if (get_magic_quotes_gpc()) 
$my_post_var = stripslashes($_POST["my_post_var"]); 

Answer 2

Tal php.ini de su servidor Linux ha permitido comillas mágicas.

http://php.net/manual/en/security.magicquotes.php

Esto es malo, por supuesto, ya que la funcionalidad es obsoleto y se eliminará en la próxima PHP 6.

Se puede desactivar en php.ini al igual que

magic_quotes_gpc = Off 

Puede probar y deshabilitarlo en tiempo de ejecución si no puede acceder a su php.ini

<?php 
if (get_magic_quotes_gpc()) { 
    $process = array(&$_GET, &$_POST, &$_COOKIE, &$_REQUEST); 
    while (list($key, $val) = each($process)) { 
     foreach ($val as $k => $v) { 
      unset($process[$key][$k]); 
      if (is_array($v)) { 
       $process[$key][stripslashes($k)] = $v; 
       $process[] = &$process[$key][stripslashes($k)]; 
      } else { 
       $process[$key][stripslashes($k)] = stripslashes($v); 
      } 
     } 
    } 
    unset($process); 
} 
?> 

Desde el PHP Manual

Answer 3

Ésta es una "característica" de PHP conocida como Magic Quotes, que ahora ha quedado obsoleto en PHP 5.3 y eliminado en PHP 5.4.

It is easy to disable the silly nuisance in php.ini.

Answer 4

Es posible que tenga comillas mágicas activadas en su entorno de producción. Inspeccione la salida phpinfo().

Puede ejecutar todas sus entradas a través de algo como esto para quitar las comillas:

 /* strip slashes from the string if magic quotes are on */ 
    static function strip_magic_slashes($str) 
    { 
      return get_magic_quotes_gpc() ? stripslashes($str) : $str; 
    } 

Answer 5

no creo que esto se aplica en su caso, pero yo estaba teniendo un problema similar. Estaba cargando una instalación de Wordpress junto con un sitio para poder mostrar las publicaciones recientes en todas las páginas.Resulta que Wordpress escapa de todos los $ _POST vars, sin importar en qué magic_quotes estén configurados.

Lo menciono porque era frustrante descubrirlo, y buscar una respuesta en Google me trajo hasta aquí.

Así es como me fijo en mi caso:

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

Answer 6

Así que habló con un desarrollador de WordPress (https://core.trac.wordpress.org/ticket/40476#ticket) y dijo:

"vuelta en el día, hace muchos muchas lunas, WordPress siguió ciegamente PHP aceptando que todos los valores superglobales deberían reducirse. PHP hizo una inversión posterior en la idea de algo más sano que ves hoy, pero el daño ya estaba hecho, WordPress como una aplicación había existido por el tiempo suficiente, y había suficientes complementos y temas existentes que dependían de WordPress creando un entorno único y sensato El hecho de que WordPress también cambie podría causar un daño irreparable a esos sitios: introduce vulnerabilidades de seguridad, destruye el contenido y un montón de otras cosas divertidas. https://core.trac.wordpress.org/ticket/18322 es nuestro boleto para rastrear esto y llegar a algo más sensato - a corto plazo (y a más largo plazo) le solicitamos que si está accediendo a las variables $ _POST lo haga como tal: $ myvar = wp_unslash ($ _POST [ 'variable']); para que un día, podamos tener $ _POST como una matriz no cortada.

relativa a la respuesta dada aquí:

$temp_POST = $_POST; 
require '../www/wp_dir/wp-load.php'; 
$_POST = $temp_POST; 

favor, no hagas eso. Simplemente te estás abriendo a problemas de seguridad y a cosas inesperadas que suceden en tu contenido donde WordPress espera que los valores sean recortados. En su lugar, simplemente use wp_unslash(), y si realmente necesita una copia de $ _POST para operar en usted mismo, hágalo como tal: $my_POST = wp_unslash($_POST);.

Debo agregar que espero que lo haga porque está tratando de usar un punto final API para algo, le sugiero que cambie al uso de la API REST presentada con WordPress 4.7, ya que nos permite para ofrecer una experiencia mucho más consistente a los desarrolladores. "