Innanzi tutto, non so cosa il presunto attaccante sta cercando di realizzare. Forse c'è uno script PHP o una versione PHP là fuori vulnerabili a qualche strano attacco ID sessione, non lo so. Tuttavia, probabilmente non hai nulla di cui preoccuparti.
Il tuo server si è comportato esattamente come previsto. 200 è il codice previsto in quella particolare situazione a causa del modo in cui Apache interpreta l'URL che gli viene passato.
Innanzitutto, http://allrequestsallowed.comviene trattata come la più comune intestazione "Host:" ( nota che non penso che questo sia specificato nell'RFC e che altri server potrebbero non interpretarlo in questo modo mi sbagliavo, questo è specificato nell'RFC 2616 nella sezione 5.1. 2, anche se i client sembrano raramente utilizzare quel modulo. Mi scusi, devo sistemare un'implementazione del server HTTP che ho scritto qualche tempo fa ...).
Ora, presumibilmente non hai un sito chiamato "allrequestsallowed.com". Quindi cosa succede quando Apache ottiene Host:un'intestazione (o equivalente) per un nome host che non riconosce? Seleziona il primo host virtuale come predefinito. Questo è un comportamento ben definito e documentato per Apache. Quindi, qualunque sia il tuo primo host virtuale (o solo la configurazione del server principale se non ci sono vhosts) prende il sopravvento, indipendentemente dal nome.
Ora, il resto dell'URL fornito è composto da due parti: il percorso /e un parametro GET (il ?PHPSESSID...bit).
Ora, il percorso /dovrebbe essere presente praticamente su tutti i web server là fuori. Nella maggior parte dei casi, si associa a qualcosa di simile index.htmlo forse a uno index.phpscript, anche se puoi ovviamente ignorare tutto questo.
Se si associa a un file HTML statico, non accade assolutamente nulla di insolito: il contenuto del file viene restituito, ed è questo, il parametro viene semplicemente ignorato. (Supponendo che non siano state impostate alcune direttive di configurazione avanzata e quasi sicuramente non lo si fa.)
D'altra parte, se si tratta di uno script di qualche tipo, quella PHPSESSIDvariabile verrà passata allo script. Se lo script utilizza effettivamente quella variabile (in questo caso particolare, è probabile che solo gli script PHP che utilizzano la gestione della sessione integrata di PHP), il suo comportamento dipenderà dal contenuto.
Con ogni probabilità, tuttavia, anche se ti /capita di mappare uno script PHP usando sessioni, non accadrà nulla di straordinario. L'ID sessione probabilmente non esisterà comunque e verrà ignorato o lo script mostrerà un errore.
Nel caso improbabile che esista l'ID sessione, beh, l'attaccante potrebbe presumibilmente dirottare la sessione di qualcun altro. Sarebbe un male, ma non è in realtà un buco di sicurezza in sé - il buco sarebbe ovunque l'attaccante ricevesse le informazioni sull'ID di sessione (annusare una rete wireless è un buon candidato se non stai usando HTTPS). In realtà non sarebbero in grado di fare nulla che l'utente la cui sessione era originariamente non potesse fare.
Modifica: Inoltre, '% 5C' all'interno di SESSIONID viene mappato a un carattere barra rovesciata. Questo sembra essere un test per attacchi di attraversamento di directory su host Windows.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. La configurazione predefinita sembra restituire una pagina "Benvenuti in nginx" senza contenuto significativo, sul nostro sistema Ubuntu. Quindi è una risposta 200, ma è una semplice pagina generale: in realtà non stiamo inoltrando la richiesta altrove o qualcosa del genere.