problemi di sicurezza con $ _SERVER ['REQUEST_URI'] e intestazione ('posizione: ...');

Question

Il mio sito web ha un'intestazione, un piè di pagina e il contenuto principale. Se l'utente non ha effettuato l'accesso, per il contenuto principale potrebbe essere visualizzato un modulo di accesso invece del contenuto effettivo.

Su tale modulo di accesso scrivo lo $_SERVER['REQUEST_URI'] nella variabile di sessione $_SESSION['redirect'].

mio form di login posthandler, che registrerà l'utente, invierà l'utente dopo loggin con successo a questo link via header('location: http://myserver.com'.$_SESSION['redirect']);

Quindi, se vado a myserver.com/somesite.php?somevar=10 mostrerà il sito corretto se si è effettuato l'accesso Altrimenti mostrerà il modulo di login, tuttavia l'URL nella barra degli indirizzi nel browser continua a dire myserver.com/somesite.php?somevar=10 Quindi inserisci le tue credenziali e verrai reindirizzato a myserver.com/somesite.php?somevar=10, che poi - dal momento che hai effettuato l'accesso - verrà visualizzato completamente.

Non utilizzo il valore REQUEST_URI per un'azione modulo o come collegamento href.

Inoltre, tutte le variabili $_GET che utilizzo prima controllano se corrispondono a un'espressione regolare (in genere la variabile sarà una stringa sha1 o una stringa generata in modo casuale solo di numeri e lettere, senza caratteri speciali) e utilizzo sempre istruzioni preparate se la variabile get viene utilizzata in una query db.

La mia domanda è se ci sono problemi di sicurezza con quello? Qualche modo per sfruttarlo, inserire qualcosa di malizioso nell'url e quindi inviarlo a un altro utente, ad esempio ...? Dovrei scappare qualcosa in qualche modo da qualche parte lungo il processo?

Answer 1

La regola fondamentale è che si controlla sempre l'input/output e vedere cosa si può e non può controllo (e quindi, cosa può essere controllato da un utente). Sulla base di ciò, si applicano misure di sicurezza/sanitizzazione.

Se comprendo correttamente lo scenario, viene visualizzata la pagina, a meno che un utente non abbia effettuato l'accesso.In tal caso, viene visualizzata una casella di accesso e, dopo aver effettuato correttamente il login, l'utente torna alla pagina che stava tentando di visitare utilizzando lo $_SERVER['request_uri'] (memorizzato in una sessione).

Quindi l'utente ovviamente può controllare questa variabile, può sfogliare la tua pagina con alcuni caratteri scomodi. Quindi è necessario disinfettarlo. Come @Wayne menziona nei commenti, gli utenti possono attraversare l'albero delle directory, ad esempio.

Pertanto, come le vostre variabili $_GET, è necessario disinfettare anche lo $_SERVER['request_uri']. Ci sono molti modi per farlo. Il più sicuro è probabilmente per verificare se request_uri è una pagina esistente, dopo aver disinfettato con html_entities() o qualcosa del genere. Si noti che i metodi di attraversamento delle directory speciale come ../, // e ./ potrebbe scivolare attraverso metodi convenzionali sanization come il suddetto html_entities()

E per rispondere alla lettera: Devo scappare qualcosa in qualche modo da qualche parte lungo il processo? - Sì, tutto, all'inizio di ogni processo.

------ EDIT @ 2013/12/12 -----

(troppo a lungo una risposta per un commento, quindi mi expain qui come potenzialmente un utente può utilizzare directory . attraversamento, compresa potenziali situazioni di pericolo)

dal manuale di PHP:

$_SERVER['REQUEST_URI']: The URI which was given in order to access this page; 
         for instance, '/index.html'. 

Quindi, dire che voglio andare a yourdomain.com/posts/post.php?../../../ssh tua webapp noterà che io non sono collegato, negozio post.php?../../../ssh in una sessione e processo accesso, dopo di che mi rimanda all'URL. A causa della parte ../../../ssh, non verrà inviata a post.php, ma a una directory sul server denominata ssh che si trova sotto il webroot. Per tua comodità hai memorizzato le tue chiavi SSH lì. Questo sembra sicuro, perché è fuori dal webroot che nessun utente web dovrebbe essere in grado di accedervi. Tuttavia, posso a causa della mia aggiunta geniale al tuo URL.

Anche se questo è un po 'inverosimile, un ambiente di chroot, un ambiente di chroot configurato correttamente, impedirà questo, questo esempio mostra che se si consente l'aggiunta di questi caratteri, potrebbero far sì che gli utenti accedano ai percorsi. non dovrebbero

A seconda dell'implementazione, aggiungere ciecamente $_SERVER['request_uri'] potrebbe anche significare che roba indesiderata viene aggiunta a una sessione e se la si archivia in un database, verrà aggiunta al database. Non sono realmente aggiornato su come sia (in) sicuro il PHP, ma posso immaginare che questo permetta di scomporre le variabili di sessione e potenzialmente di iniettare cose nel tuo database.

Anche se non tutto è possibile e l'esempio potrebbe non essere realmente possibile, è meglio e non è difficile impedire questo comportamento.

- Piccolo dopo il pensiero: forse la roba header('location'... non è sicura, ma questo: Is this PHP redirect insecure? mostra il suo non proprio. Tuttavia, come dice un commentatore: non è così difficile digitare urlencode()

Answer 2

Ci sono numerosi problemi di sicurezza con l'installazione online di QUALSIASI COSA. Avere uno schema identificabile nelle richieste di posta/acquisizione è una preoccupazione, ma dipende da molti fattori, principalmente ... che cosa può trarre un utente dall'avere a che fare con il tuo sito e da quanto sei responsabile per gli scopi dannosi degli utenti del sito.

Si dovrebbe fare qualche ricerca per sanitizzare il proprio input, utilizzando i token di sessione sarebbe la prima cosa che si potrebbe fare per garantire che il traffico al proprio script di accesso venga effettivamente generato dagli utenti sul proprio sito. Queste due pratiche comuni sono i primi passi nella protezione di agains sql injection e degli attacchi di cross-site scripting. misure appropriate per garantire la protezione dei dati, sia attraverso una buona progettazione del database, sia con una buona progettazione del codice.

Una delle mie tecniche preferite è configurare la mia applicazione per utilizzare intestazioni http personalizzate e qualsiasi script che riceva dati da controlli Super Global per garantire che le intestazioni personalizzate siano correttamente fornite come componenti della mia sicurezza. Queste intestazioni possono essere viste e annusate facilmente da qualsiasi hacker, ma molti attacchi di natura malevola vengono prima eseguiti da uno script, ed è solo un ulteriore passaggio abbastanza facile da implementare che ti rende un bersaglio più difficile per questi tipi di attacchi.

Una rapida ricerca su google fortificare un sito basato php alzato questo articolo, che ha alcuni buoni consigli: http://www.noupe.com/php/php-security-tips.html

Answer 3

Non sarai mai sicuro al 100%. Puoi dare un'occhiata a OWASP Top Ten. Questi sono i principali problemi di sicurezza.

Penso che dovresti avere un token (numero casuale) associato a ciascun utente in $ _SESSION, invece di $_SERVER['REQUEST_URI']. Puoi passare REQUEST_URI per GET e token tramite POST (in un input nascosto) e quindi convalidarlo. Se l'accesso utente è necessario per questo URI, assicurarsi che il token dell'utente ricevuto sia uguale al token dell'utente di sessione.

Answer 4

Si sta reindirizzando a un URL relativo, il che è positivo perché ciò significa che un utente malintenzionato non può utilizzare un metodo such as this per avvelenare la variabile di sessione utilizzando session fixation con un reindirizzamento al proprio dominio. Non dovresti eseguire alcuna codifica su questo valore perché è una copia diretta dell'URI originale ed è anche l'esatto URI a cui desideri reindirizzare l'utente. È necessario verificare che la versione di PHP che si sta utilizzando non sia vulnerabile allo header injection. Sembra che fosse fixed in PHP:

4.4.2 e 5.1.2 Questa funzione ora impedisce più di un'intestazione di essere inviata contemporaneamente come protezione contro gli attacchi di iniezione di intestazione.

Le altre risposte per quanto riguarda path traversal non dovrebbe essere una preoccupazione qui perché non v'è alcun rischio supplementare che l'utente digitando il percorso direttamente nella barra degli indirizzi. Il fatto che vengano reindirizzati utilizzando l'intestazione location non aumenta questo rischio. Tuttavia, dovresti assicurarti che la tua piattaforma server non sia vulnerabile, ma tieni presente che questo non ha nulla a che fare con il tuo metodo di reindirizzamento come location dice semplicemente al client di caricare un altro indirizzo.

Assicurarsi di chiamare exit dopo setting your header, altrimenti un attaccante sarebbe in grado di vedere i tuoi contenuto della pagina visualizzando la risposta HTTP grezzo: -

<html> 
<?php 
/* This will give an error. Note the output 
* above, which is before the header() call */ 
header('Location: http://www.example.com/'); 
exit; 
?> 

non posso commentare su ogni vulnerabilità tuo sito potrebbe avere, ma in sostanza il modo in cui proponi di eseguire il reindirizzamento dovrebbe essere sicuro. Dovresti comunque assicurarti che il tuo sito sia accessibile solo tramite HTTPS che crittograferà la connessione e assicurerà che sia sicuro dagli attacchi MITM. È inoltre necessario impostare secure flag sul cookie di sessione per assicurarsi che non possa essere trapelato su una connessione non HTTPS.