Cosa c'è di sbagliato nell'usare $ _REQUEST []?

Ho visto un numero di post qui che dicevano di non usare la $_REQUESTvariabile. Di solito non lo faccio, ma a volte è conveniente. Che cosa c'è che non va?

Non c'è assolutamente niente di sbagliato nel ricevere input da entrambi $_GETe $_POSTin modo combinato. In effetti è quello che vuoi quasi sempre fare:

• per una semplice richiesta idempotente solitamente inviata tramite GET, c'è la possibilità che la quantità di dati che desideri non si adatti a un URL, quindi è stata modificata in una richiesta POST invece come questione pratica.

• per una richiesta che ha un effetto reale, devi controllare che sia inviata con il metodo POST. Ma il modo per farlo è controllare $_SERVER['REQUEST_METHOD']esplicitamente, non fare affidamento $_POSTsull'essere vuoto per un GET. E comunque, se il metodo lo è POST, potresti comunque voler rimuovere alcuni parametri di query dall'URL.

No, il problema $_REQUESTnon ha nulla a che fare con la fusione dei parametri GET e POST. E 'che anche, per impostazione predefinita, include $_COOKIE. E i cookie in realtà non sono affatto come i parametri di invio dei moduli: non vuoi quasi mai trattarli come la stessa cosa.

Se ricevi accidentalmente un cookie impostato sul tuo sito con lo stesso nome di uno dei parametri del tuo modulo, i moduli che si basano su quel parametro smetteranno misteriosamente di funzionare correttamente a causa dei valori dei cookie che sovrascrivono i parametri previsti. Questo è molto facile da fare se hai più app sullo stesso sito e può essere molto difficile eseguire il debug quando hai solo un paio di utenti con vecchi cookie che non usi più in giro e rompono i moduli in modi no -un altro può riprodursi.

Puoi modificare questo comportamento in un ordine molto più sensato GP(no C) con la configurazione request_order in PHP 5.3. Dove ciò non è possibile, personalmente lo eviterei $_REQUESTe, se avessi bisogno di un array combinato GET + POST, lo creerei manualmente.

Ho esaminato alcuni post di newsgroup su PHP Internals e ho trovato un'interessante discussione sull'argomento. Il thread iniziale riguardava qualcos'altro, ma un'osservazione di Stefan Esser, un (se non l' esperto) di sicurezza nel mondo PHP, ha rivolto la discussione alle implicazioni sulla sicurezza dell'uso di $ _REQUEST per alcuni post.

Citando Stefan Esser su PHP Internals

$ _REQUEST è uno dei maggiori punti deboli del design in PHP. Ogni applicazione che utilizza $ _REQUEST è molto probabilmente vulnerabile a problemi di falsificazione di richieste cross-site ritardate. (Questo in pratica significa che se ad es. Un cookie denominato (età) esiste, sovrascriverà sempre il contenuto GET / POST e quindi verranno eseguite richieste indesiderate)

e in una successiva risposta allo stesso thread

Non si tratta del fatto che qualcuno possa falsificare GET, POST; Variabili COOKIE. Riguarda il fatto che i COOKIE sovrascriveranno i dati GET e POST in REQUEST.

Pertanto potrei infettare il tuo browser con un cookie che dice ad esempio action = logout e da quel giorno non potrai più utilizzare l'applicazione perché REQUEST [action] sarà disconnesso per sempre (fino a quando non cancellerai manualmente il cookie).

E infettarti con un COOKIE è così semplice ...
a) Potrei usare un vuln XSS in qualsiasi applicazione su un sottodominio
b) Hai mai provato a impostare un cookie per * .co.uk o * .co.kr quando possiedi un singolo dominio lì?
c) Altri cross domain in qualunque modo ...

E se credi che questo non sia un problema, posso dirti che esiste una semplice possibilità di impostare fe un cookie * .co.kr che si traduce in diverse versioni di PHP che restituiscono solo pagine bianche. Immagina: un solo cookie per eliminare tutte le pagine PHP in * .co.kr

E impostando un ID di sessione illegale in un cookie valido per * .co.kr in una variabile chiamata + PHPSESSID = illegale puoi ancora eseguire il DOS su tutte le applicazioni PHP in Corea usando sessioni PHP ...

La discussione continua per qualche altro post ed è interessante da leggere.

Come puoi vedere, il problema principale con $ _REQUEST non è tanto che ha dati da $ _GET e $ _POST, ma anche da $ _COOKIE. Alcuni altri ragazzi nell'elenco hanno suggerito di cambiare l'ordine in cui $ _REQUEST viene riempito, ad esempio riempendolo con $ _COOKIE prima, ma questo potrebbe portare a numerosi altri potenziali problemi, ad esempio con la gestione della sessione .

Tuttavia, potresti omettere completamente $ _COOKIES dalla $ _REQUEST globale, in modo che non venga sovrascritto da nessuno degli altri array (in effetti, puoi limitarlo a qualsiasi combinazione dei suoi contenuti standard, come il manuale PHP sull'impostazione variable_order ini ci dice:

variabile_ordine Imposta l'ordine di analisi delle variabili EGPCS (Environment, Get, Post, Cookie e Server). Ad esempio, se variable_order è impostato su "SP", PHP creerà i superglobali $ _SERVER e $ _POST, ma non $ _ENV, $ _GET e $ _COOKIE. L'impostazione su "" significa che non verrà impostata alcuna superglobale.

Ma poi di nuovo, potresti anche considerare di non utilizzare $ _REQUEST del tutto, semplicemente perché in PHP puoi accedere a Environment, Get, Post, Cookie e Server nei loro globali e avere un vettore di attacco in meno. Devi ancora disinfettare questi dati, ma è una cosa in meno di cui preoccuparti.

Ora potresti chiederti, perché dopo tutto $ _REQUEST esiste e perché non è stato rimosso. Questo è stato chiesto anche su PHP Internals. Citando Rasmus Lerdorf su Perché esiste $ _REQUEST? su PHP Internals

Più cose come questa rimuoviamo, più difficile diventa per le persone passare rapidamente a versioni più nuove, più veloci e più sicure di PHP. Ciò causa molta più frustrazione per tutti rispetto a poche "brutte" funzionalità legacy. Se c'è una ragione tecnica, prestazioni o sicurezza decente, allora dobbiamo esaminarla attentamente. In questo caso, la cosa che dovremmo guardare non è se dobbiamo rimuovere $ _REQUEST ma se dobbiamo rimuovere i dati dei cookie da esso. Molte configurazioni lo fanno già, comprese tutte le mie, e c'è un motivo di sicurezza valido e valido per non includere i cookie in $ _REQUEST. La maggior parte delle persone usa $ _REQUEST per indicare GET o POST, non rendendosi conto che potrebbe contenere anche cookie e come tali i malintenzionati potrebbero potenzialmente fare alcuni trucchi di iniezione di cookie e rompere le applicazioni ingenue.

Ad ogni modo, spero che faccia luce.

$_REQUESTsi riferisce a tutti i tipi di richieste (GET, POST ecc ..). Questo a volte è utile, ma di solito è meglio specificare il metodo esatto ($ _GET, $ _POST ecc.).

$_REQUEST è generalmente considerato dannoso per lo stesso motivo per cui le trasformazioni di dati di complessità da semplice a media vengono spesso eseguite nel codice dell'applicazione anziché dichiarate in SQL: alcuni programmatori fanno schifo.

In quanto tale, se si tende a usare $_REQUESTovunque, posso fare qualsiasi cosa tramite GET che potrei tramite POST, il che significa impostare <img>tag sul mio sito (dannoso) che inducono gli utenti a accedere al tuo modulo di e-commerce per acquistare prodotti in silenzio, oppure io può indurli a fare clic su collegamenti che comporteranno azioni pericolose o la rivelazione di informazioni sensibili (probabilmente per me).

Tuttavia, questo è dovuto a un programmatore PHP inesperto, o almeno inesperto, che commette semplici errori. Prima di tutto, sapere quando i dati di quale tipo è appropriato. Ad esempio, ho un servizio web che può restituire risposte in URLEncoding, XML o JSON. L'applicazione decide come formattare la risposta controllando l'intestazione HTTP_ACCEPT, ma può essere forzata in una specifica inviando il formatparametro.

Quando si controlla il contenuto del parametro di formato, potrebbe essere inviato tramite querystring o un postdata, a seconda di una moltitudine di fattori, non ultimo dei quali è se le applicazioni chiamanti vogliono o meno "& format = json" mescolato con la sua richiesta. In questo caso, $_REQUESTè molto comodo perché mi evita di dover digitare qualcosa del genere:

$format = isset($_POST['format']) ? $_POST['format'] 
    : (isset($_GET['format']) ? $_GET['format'] : null);

Non mi dilungherò molto oltre, ma è sufficiente dire che l' $_REQUESTuso non è sconsigliato perché è intrinsecamente pericoloso - è solo un altro strumento che fa esattamente ciò che gli viene chiesto, che tu comprenda o meno tali implicazioni - è il decisione povera, pigra o disinformata di un programmatore povero, pigro o inesperto che causa questo problema.

Come usare in $_REQUESTsicurezza

1. Conosci i tuoi dati : dovresti avere qualche aspettativa sul tipo di dati che otterrai, quindi disinfettali di conseguenza. Dati per un database? addslashes()o *_escape_string(). Vuoi mostrarlo di nuovo all'utente? htmlentities()o htmlspecialchars(). Prevedi dati numerici? is_numeric()o ctype_digit(). In effetti, filter_input()e le sue funzioni correlate sono progettate per non fare altro che controllare e disinfettare i dati. Usa questi strumenti, sempre.
2. Non accedere direttamente ai dati superglobali forniti dall'utente . Prendi l'abitudine di disinfettare i tuoi dati, ogni volta, e sposta i tuoi dati per pulire le variabili, anche se è solo $post_clean. In alternativa, puoi semplicemente pulire direttamente nelle superglobali, ma il motivo per cui sostengo l'utilizzo di una variabile separata è perché così facendo è facile individuare le vulnerabilità nel codice, poiché qualsiasi cosa che punti direttamente a una superglobale e non il suo equivalente disinfettato è considerato un errore pericoloso .
3. Sapere da dove dovrebbero provenire i dati. Facendo riferimento al mio esempio dall'alto, è perfettamente ragionevole consentire l'invio della variabile del formato della risposta tramite GET o POST. Consento anche l'invio della variabile "action" tramite entrambi i metodi. Tuttavia, le azioni stesse hanno requisiti molto specifici su quale verbo HTTP è accettabile . Le funzioni, ad esempio, che apportano modifiche ai dati utilizzati dal servizio possono essere inviate solo tramite POST. Le richieste di determinati tipi di dati con privilegi bassi o senza privilegi (come immagini di mappe generate dinamicamente) possono essere fornite in risposta a richieste da entrambi i metodi.

In conclusione, ricorda questa semplice regola:

LA SICUREZZA È QUELLO CHE LO FACCIA, PERSONE!

MODIFICARE:

Consiglio vivamente il consiglio di bobince: se puoi, imposta il request_orderparametro in php.ini su "GP"; ovvero, nessun componente cookie. Non c'è quasi alcun ragionamento razionale per questo nel 98% + dei casi, poiché i dati dei cookie non dovrebbero quasi mai essere considerati comparabili alla stringa di query o ai dati post.

PS, aneddoto!

Conoscevo un programmatore che pensava a $_REQUESTun luogo in cui archiviare semplicemente i dati che fosse accessibile in modo superglobale. Nomi utente e password importanti, percorsi dei file, il nome ed è stato archiviato in $_REQUEST. È rimasto un po 'sorpreso (anche se non comicamente, sfortunatamente) quando gli ho detto come si comporta quella variabile. Inutile dire che quella pratica è stata revocata.

Le richieste GET dovrebbero essere idempotenti e le richieste POST generalmente non lo sono. Ciò significa che i dati in $_GETe $_POSTdovrebbero generalmente essere utilizzati in modi diversi.

Se l'applicazione utilizza i dati di $_REQUEST, si comporterà allo stesso modo sia per le richieste GET che per le richieste POST, il che viola l'idempotenza di GET.

È vago. Non sai davvero come ti sono arrivati ​​i dati poiché trasporta i dati di post, get e cookie. Non penso necessariamente che sia sempre una cosa negativa, a meno che non sia necessario conoscere o limitare il metodo di consegna.

In realtà mi piace usarlo. Ti dà la flessibilità di utilizzare GET o POST che possono tornare utili per cose come i moduli di ricerca in cui la maggior parte delle volte i dati vengono inseriti in POST, ma a volte potresti voler dire link a una particolare ricerca, quindi puoi usare invece i parametri GET .

Inoltre, se guardi molti altri linguaggi (ASP.NET per esempio) non fanno alcuna distinzione tra le variabili GET e POST.

ETA :

Non ho mai usato REQUEST per ottenere i valori dei COOKIE, ma penso che Kyle Butt abbia un ottimo punto nei commenti su questo post a riguardo. NON è una buona idea usare REQUEST per ottenere i valori dei COOKIE. Credo che abbia ragione sul fatto che ci sia un potenziale reale di contraffazione delle richieste cross-site se lo fai.

Inoltre, l'ordine in cui le cose vengono caricate in REQUEST è controllato dai parametri di configurazione in php.ini (variables_order e request_order). Quindi, se hai la stessa variabile passata sia tramite POST che GET, quella che entra effettivamente in REQUEST dipende da quelle impostazioni ini. Ciò potrebbe influire sulla portabilità se si dipende da un ordine particolare e tali impostazioni sono configurate in modo diverso da come ci si aspetta che siano.

È importante capire quando usare POST, quando usare GET e quando usare un cookie. Con $ _REQUEST, il valore che stai guardando potrebbe provenire da uno qualsiasi di essi. Se ti aspetti di ottenere il valore da un POST o da un GET o da un COOKIE, è più informativo per qualcuno che legge il tuo codice utilizzare la variabile specifica invece di $ _REQUEST.

Qualcun altro ha anche sottolineato che non vuoi che tutti i POST oi cookie vengano sovrascritti dai GET perché ci sono diverse regole cross-site per tutti loro, ad esempio, se restituisci dati ajax mentre usi $ _REQUEST, sei vulnerabile a un attacco cross site script.

L'unica volta che si usa $_REQUESTnon è una cattiva idea è con GET.

• Se lo utilizzi per caricare i valori POST, rischi di falsificare le richieste tra siti
• Se lo utilizzi per caricare i valori dei cookie, rischi di nuovo di falsificare le richieste tra siti

E anche con GET, $_GETè più breve da digitare rispetto a $_REQUEST;)

Potrei essere usato solo se vuoi recuperare l'URL o il nome host corrente, ma per analizzare effettivamente i dati da quell'URL come i parametri che usano il simbolo & probabilmente non è una buona idea. In generale, non vuoi usare una descrizione vaga di ciò che stai cercando di fare. Se devi essere specifico, è lì che $ _REQUEST è sbagliato, se non hai bisogno di essere specifico, sentiti libero di usarlo. Penserei.

Se sai quali dati desideri, dovresti richiederli esplicitamente. IMO, GET e POST sono due animali diversi e non riesco a pensare a una buona ragione per cui avresti mai bisogno di mescolare i dati dei post e le stringhe di query. Se qualcuno ne ha uno, sarei interessato.

Può essere conveniente usare $ _REQUEST quando i tuoi script potrebbero rispondere a GET o POST nello stesso modo. Direi però che questo dovrebbe essere un caso estremamente raro, e nella maggior parte dei casi si preferiscono due funzioni separate per gestire due concetti separati, o per lo meno controllare il metodo e selezionare le variabili corrette. Il flusso del programma è di solito molto più facile da seguire quando non è necessario fare riferimenti incrociati da dove potrebbero provenire le variabili. Sii gentile con la persona che deve mantenere il tuo codice tra 6 mesi. Potresti essere tu.

Oltre ai problemi di sicurezza e ai WTF causati dai cookie e dalle variabili di ambiente nella variabile REQUEST (non farmi iniziare su GLOBAL), considera cosa potrebbe accadere in futuro se PHP iniziasse a supportare nativamente altri metodi come PUT e DELETE. Sebbene sia estremamente improbabile che questi vengano fusi nel superglobal REQUEST, è possibile che possano essere inclusi come opzione nell'impostazione variable_order. Quindi non hai davvero idea di cosa contenga REQUEST e cosa abbia la precedenza, in particolare se il tuo codice è distribuito su un server di terze parti.

POST è più sicuro di GET? Non proprio. È meglio usare GET dove pratico perché è più facile vedere nei tuoi log come la tua applicazione viene sfruttata quando viene attaccata. Il POST è migliore per le operazioni che influenzano lo stato del dominio perché gli spider generalmente non li seguono e i meccanismi di recupero predittivo non eliminano tutti i tuoi contenuti quando accedi al tuo CMS. Tuttavia, la domanda non riguardava i meriti di GET vs POST, ma di come il ricevitore dovrebbe trattare i dati in arrivo e perché è sbagliato unirli, quindi questo è davvero solo un BTW.

Penso che non ci siano problemi $_REQUEST, ma dobbiamo stare attenti quando lo usiamo poiché è una raccolta di variabili da 3 fonti (GPC).

Immagino $_REQUESTsia ancora disponibile per rendere i vecchi programmi compatibili con le nuove versioni di php, ma se iniziamo nuovi progetti (comprese nuove librerie) penso che non dovremmo $_REQUESTpiù usarli per rendere i programmi più chiari. Dovremmo anche prendere in considerazione l'eliminazione degli usi $_REQUESTe la sua sostituzione con una funzione wrapper per rendere il programma più leggero, specialmente nell'elaborazione di dati di testo inviati di grandi dimensioni, poiché $_REQUESTcontiene copie di $_POST.

// delete $_REQUEST when program execute, the program would be lighter 
// when large text submitted
unset($_REQUEST);

// wrapper function to get request var
function GetRequest($key, $default = null, $source = '') 
{
  if ($source == 'get') {
    if (isset($_GET[$key])) { 
      return $_GET[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'post') {
    if (isset($_POST[$key])) { 
      return $_POST[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'cookie') {
    if (isset($_COOKIE[$key])) { 
      return $_COOKIE[$key]; 
    } else { 
      return $default; 
    }
  } else {
    // no source specified, then find in GPC
    if (isset($_GET[$key])) {
      return $_GET[$key];     
    } else if (isset($_POST[$key])) {
      return $_POST[$key]; 
    } else if (isset($_COOKIE[$key])) {
      return $_COOKIE[$key]; 
    } else {
      return $default; 
    } 
  }
}

Darren Cook: "Dal momento che php 5.3 il php.ini predefinito dice che solo i dati GET e POST sono inseriti $_REQUEST. Vedi php.net/request_order Sono appena incappato in questa interruzione della retrocompatibilità quando mi aspettavo che i dati dei cookie fossero presenti $_REQUESTe mi chiedevo perché non lo fosse" non funziona! "

Wow ... alcuni dei miei script hanno smesso di funzionare a causa di un aggiornamento a PHP 5.3 . Ha fatto la stessa cosa: presumere che i cookie vengano impostati quando si utilizza il$_REQUEST variabile. Con l'aggiornamento esattamente quello ha smesso di funzionare.

Ora chiamo i valori dei cookie separatamente usando $_COOKIE["Cookie_name"]...

Il problema centrale è che contiene cookie, come altri hanno detto.

In PHP 7 puoi fare questo:

$request = array_merge($_GET ?? [], $_POST ?? []);

Questo evita il problema dei cookie e ti dà nel peggiore dei casi un array vuoto e nella migliore delle ipotesi una fusione di $ _GET e $ _POST con quest'ultimo che ha la precedenza. Se non sei troppo preoccupato di consentire l'inserimento di parametri tramite la stringa di query, è abbastanza conveniente.

È molto insicuro. Inoltre è imbarazzante poiché non sai se stai ricevendo un POST o un GET o un'altra richiesta. Dovresti davvero conoscere la differenza tra loro durante la progettazione delle tue applicazioni. GET è molto insicuro in quanto viene passato nell'URL e non è adatto a quasi nulla oltre alla navigazione della pagina. POST, sebbene non sia sicuro da solo, fornisce un livello di sicurezza.