Revisione sicurezza: "L'user-agent dell'intestazione HTTP è stato impostato su (qualcosa)"

L'iniezione nel valore user-agent (o referer per quella materia) può essere una potenziale minaccia in diversi modi, tuttavia se la tua situazione attuale è in realtà una vulnerabilità è difficile da dire senza guardare l'immagine più grande del tuo sistema.

Vedo spesso sistemi che in un modo o nell'altro usano l'utente-agente. Spesso viene utilizzato per memorizzare informazioni sul browser più utilizzato e simili. A volte gli user-agent noti come bot vengono trattati in modo diverso. Ci sono molti casi.

Iniezione

Non è raro vedere gli attacchi XSS provati nel campo user-agent. Ad esempio, un sito che stavo testando qualche tempo fa mi ha presentato un po 'di informazioni su di me.

La cosa interessante è che mi ha restituito l'agente utente. Quando ho iniettato l'agente utente 'FooBar"> <img src="javascript:alert('document.cookie')' , l'ho segnalato a me.

Ora per sfruttare questo attacco su altri utenti il sito aveva anche una pagina delle statistiche in cui mostrava quanti utenti medi al giorno, quali erano i browser più comuni e così via. I numeri sembravano essere basati sul numero di richieste. Costruire uno script veloce che ha fatto abbastanza richieste con il mio XSS ha semplicemente messo il mio user-agent nella top 100 e il vettore era ora persistente e funzionante contro altri utenti

La stessa cosa è possibile per l'iniezione SQL. Prova a correre con useragent Im Harmless";DROP TABLE users . Forse rompi alcuni sistemi.

Analisi della vulnerabilità

Toss in a / "come nell'esempio e vedi cosa succede Forse hai un messaggio di errore, o qualcosa è successo da qualche altra parte sul sito.

Capire cosa succede se si usa un vecchio user-agent o un user-agent di un motore di ricerca può a volte essere molto utile. A volte questo è l'unico modo per sbloccare parte del contenuto del sito e sondare quel contenuto per le vulnerabilità.

Usando per esempio Burpsuite quest'ultimo è molto facile da automatizzare e quindi sfoglia velocemente tutti i diversi requet per le differenze.

EDIT: nel tuo esempio specifico sembra che il client che ha effettuato la richiesta abbia impostato lo user-agent su \ ". Se questo è intenzionalmente, un bug o semplicemente qualcuno che nasconde il loro user-agent è difficile da dire, ma vorrei assolutamente esaminare altre richieste fatte da questo utente.

Non vedo come l'inserimento di una virgoletta con escape nella stringa user-agent sia una vulnerabilità.

Non sono sicuro che sia così, penso che siano necessarie maggiori informazioni. L'UNICA cosa che posso pensare è che stanno probabilmente esponendo un potenziale per un dirottamento di sessione.

Fondamentalmente, PHPSESSID = 08rtvlq03bd9d57qor4abjg7q4 appartiene a una sessione utente diversa, stanno spoofando questo ID sessione tramite un cookie e stanno ottenendo una risposta normale, anche se l'agente utente è cambiato rispetto all'utente originale.

Chiarimento:

L'utente A apre il sito Web, utilizzando la seguente stringa User-Agent:

Mozilla Compatible (MSIE)

All'utente A viene quindi assegnato il seguente ID di sessione:

08rtvlq03bd9d57qor4abjg7q4

L'utente B (cattivo ragazzo) invia quindi una richiesta al server utilizzando un cookie con lo stesso ID di sessione nel suo cookie, tuttavia la sua stringa User-Agent è:

\"

La tua applicazione dovrebbe quindi rendersi conto che non si tratta dello stesso utente e distruggere la sessione.

Non sono affatto certo che questa sia la situazione, né il monitoraggio dello user-agent impedisce un dirottamento di sessione, dato che gli user-agent sono facilmente falsificati, ma questo è l'unico potenziale che vedo qui.

Stanno cercando di venderti qualcosa che dovrebbe essere inutile.

Il protocollo HTTP consente questo tipo di cose. Potrei impostare il User-Agent (AKA, "Che tipo di browser stai usando?") A "User Agent: User Agent: User Agent: Trust no one"

Se il tuo software non è prendendo in considerazione l'iniezione di codice (SQL, Script, ecc.) in un modo moderno, allora questo potrebbe essere stato un problema. Ma hai scritto il tuo software usando le migliori pratiche e hai correttamente disinfettato tutti gli input e stai usando un livello di astrazione del database, giusto?

In termini di modi per migliorare la tua sicurezza, monitorare elementi come l'origine, la frequenza delle richieste, il profilo delle richieste, controllare l'agente utente, controllare la pagina dei referrer, controllare ... tutto, è un monitoraggio attivo che puoi fare per fornire più sicurezza. Non credo che questo sia quello che stavano cercando di dirti di fare (come parte della risposta di Alex), solo che "Puoi cambiare questo", che è un totale "no-duh" per chiunque conosca abbastanza bene l'HTTP , ma probabilmente solo un modo per spaventare un po 'di valore aggiunto.

Quindi, se il tuo codice PHP consente qualsiasi input - incluso - una stringa user-agent da inserire in un DB senza essere adeguatamente disinfettato e l'uso di un livello di astrazione del database, avrai una giornata davvero brutta .

Ti fornirò un suggerimento gratuito , l'intestazione del referrer può essere impostata su questo:

Referrer: \' -- TRUNCATE 'Users'

Il problema non è che puoi impostare queste intestazioni, puoi anche inviare tali dati come "Nome" in un modulo di indirizzo.

Quindi ecco la domanda, vuoi permettere a chi è l'utente-agente che non hai in un tavolo da qualche parte di non usare il tuo sito web? Probabilmente un'idea stupida perché un hacker può comunque essere impostato su un valore valido.

La risposta è semplice. Non includere alcun valore di intestazione passato nella richiesta nel contenuto della risposta senza prima averlo pulito. Del resto, non utilizzare mai i dati forniti dall'utente in alcun modo senza averli prima puliti. Disinfetta sempre gli input.

Se non includi i valori dell'intestazione trasmessi dal client nel tuo contenuto, puoi ignorare questo avviso.

Se le persone che vengono impiegate per testare la sicurezza del tuo sito web, e hanno presumibilmente trascorso una notevole quantità di tempo a lavorarci, non possono spiegare come questo rende il tuo sito in qualche modo vulnerabile, ma può affermare che è un punto debole di sicurezza nel tuo sito, quindi sembra che tu abbia sprecato un sacco di tempo e sforzi su di loro. Sembra che tu abbia ingaggiato degli script-kiddies per fare il tuo test con la penna.

Non c'è alcun consiglio nei dettagli che hai pubblicato. Non ci sono analisi.

Inoltre, il fatto che sembrano eseguire i test su "localhost" suggerisce che non sanno cosa stanno facendo.

E

Pragma: no-cache

In una risposta di intestazione suggerisce che chiunque abbia scritto il codice non capisca neanche l'HTTP. Da rfc 2616 :

Note: because the meaning of "Pragma: no-cache as a response header field is not actually specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in a response

Devi dare un'occhiata alle tue specifiche funzionali se ti stanno dicendo di convalidare i campi di intestazione.

Le tue specifiche funzionali dovrebbero definire quale sia il comportamento consentito. Potrebbe definire qualsiasi / tutti gli agenti utente come accettabile, nel qual caso è necessario accettarlo. Tieni presente che i dati di intestazione, come tutti i dati inviati dall'utente, sono potenzialmente pericolosi.