Perché le variabili $ _POST vengono scappate in PHP?

Question

Quando lo script PHP riceve i dati da una richiesta POST AJAX, le variabili $_POST sono sottoposte a escape. La cosa davvero strana è che questo accade solo sul mio server di produzione (con PHP 5.2.12 su Linux) e non sul mio server locale (con PHP 5.3.1 su Windows). ci

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); 

è un qualsiasi motivo questo sta accadendo:

Ecco il codice AJAX? E come devo risolvere questo in modo che funzioni su entrambi i server?

Edit: Ho le seguenti impostazioni per magic_quotes:

     Local Master 

magic_quotes_gpc  On  On 
magic_quotes_runtime Off  Off 
magic_quotes_sybase Off  Off 

Answer 1

Probabilmente hanno magic quotes abilitato sul server Linux: magic_quotes

Quando magic_quotes sono, all '(single-citazione), "(virgolette), \ (barra rovesciata) e NUL sono scappati automaticamente con una barra rovesciata.

Sono una buona cosa da disabilitare, in quanto saranno comunque rimossi da PHP 6 in poi. Dovresti anche essere in grado di disabilitarli all'interno dello script: set-magic-quotes-runtime Non è possibile disattivare la parte di magic_quotes responsabile dell'esclusione dei dati POST durante il runtime. Se puoi, disabilitalo in php.ini. Se non è possibile farlo, fare un controllo se i magic_quotes sono abilitati, e fare uno stripslashes() su qualsiasi contenuto essere prelevati dal POST:

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

Answer 2

Forse php.ini del server Linux ha magic quotes abilitati.

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

Questo è un male, naturalmente, come la funzionalità è deprecato e sarà rimosso nel prossimo PHP 6.

È possibile disattivare in php.ini in questo modo

magic_quotes_gpc = Off 

è possibile verificare e disattivarla in fase di esecuzione se non è possibile accedere al file 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); 
} 
?> 

Dal PHP Manual

Answer 3

Questo è un PHP "caratteristica" nota come Magic Quotes, che è stato deprecato in PHP 5.3 e rimosso in PHP 5.4.

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

Answer 4

probabilmente hai magic quotes attivati ​​nell'ambiente di produzione. Ispezionare l'output phpinfo().

È possibile eseguire tutti i tuoi ingressi attraverso qualcosa di simile per mettere a nudo le virgolette:

 /* 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

non credo che questo vale nel tuo caso, ma ero solo avere un problema simile. Stavo caricando un'installazione di Wordpress insieme a un sito in modo da poter mostrare i post recenti su tutte le pagine.Si scopre che Wordpress sfugge a tutti i $ _POST vars, non importa a quale magic_quotes sia impostato.

Ne ho parlato perché era frustrante capirlo, e cercare su Google una risposta mi ha portato qui.

Ecco come ho riparato nel mio caso:

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

Answer 6

così ho fatto parlare con un dev wordpress (https://core.trac.wordpress.org/ticket/40476#ticket) e disse:

"Back in the day, molte molte lune fa, WordPress ha seguito ciecamente PHP nell'accettare che tutti i valori superglobali dovrebbero essere tagliati .. PHP in seguito ha fatto un'inversione sull'idea di qualcosa di più sensato che si vede oggi, ma il danno è stato fatto, WordPress come un'applicazione esisteva da abbastanza tempo, e c'erano abbastanza plugin e temi esistenti che si basavano su WordPress creando un singolo enviro sano che WordPress, anche cambiando, causerebbe danni irreparabili a tali siti: introdurre vulnerabilità della sicurezza, manipolare i contenuti e un sacco di altre cose divertenti. https://core.trac.wordpress.org/ticket/18322 è il nostro biglietto per tracciare questo e arrivare a qualcosa di più sano - a breve (ea lungo termine) ti chiederemo se stai accedendo alle variabili $ _POST lo fai come tale: $ myvar = wp_unslash ($ _POST [ 'variabile']); in modo che un giorno, saremo in grado di avere $ _POST come array non sincronizzato.

concernente la risposta qui dato:

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

Si prega di non farlo. Stai solo aprendo te stesso ai problemi di sicurezza, e cose inaspettate accadono ai tuoi contenuti dove WordPress si aspetta che i valori vengano tagliati. Invece, è sufficiente utilizzare wp_unslash() e, se è veramente necessaria una copia di $ _POST per operare su se stessi, procedere come segue: $my_POST = wp_unslash($_POST);.

Devo anche aggiungere - Prevedo che lo stai facendo perché stai provando a utilizzare un endpoint API per qualcosa, ti consiglio vivamente di passare all'utilizzo dell'API REST introdotta con WordPress 4.7, in quanto ci consente offrire un'esperienza molto più coerente agli sviluppatori. "