User-Agent con componente con codifica base64?

(Domanda di bontà in fondo)

Sto riscontrando un problema con un client che accede al nostro sito e la causa principale è che a WAF (Web Application Firewall) non piace la stringa User-Agent:

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0; C7QcSBPWTsrpX5YLvVZMqiujEZLWPtOYk3tDZ9WhW18=) Gecko/20100101 Firefox/34.0

In questo caso, la stringa codificata in base64 sta innescando un falso positivo nel WAF che pensa che User-Agent sia libwww-perl. La stringa base64 non viene decodificata in alcun testo leggibile.

• Avere una stringa con codifica base64 all'interno di un User-Agent è normale o inusuale?
• L'uso di stringhe base64 all'interno di un User-Agent è coperto da RFC o dalle principali pratiche dei fornitori?

Sto cercando di capire cosa sta succedendo qui; Non credo che la firma WAF sia completamente fuori linea rispetto all'oggetto, quindi preferirei non solo disabilitarlo, ma non ho mai visto questo tipo di stringa User-Agent prima, quindi preferirei capire meglio quanto comune e / o legittimo un caso d'uso questo è.

Il sito è progettato per essere utilizzato da utenti con browser - non è un'API o qualcosa del genere - e mi è stato riferito che l'utente ha tentato di accedere al sito con "FF / IE / Chrome" e non è riuscito. Tuttavia, mostra connessioni riuscite dallo stesso IP client con un user-agent Opera:

User-Agent: Opera/9.80 (X11; Linux i686) Presto/2.12.388 Version/12.16

È un po 'strano che l'utente riferisca di aver provato IE, ma tutte le stringhe User-Agent che vedo sembrano essere Linux. (Come sempre, il contatto con l'utente finale è mediato da diverse parti, quindi non posso fidarmi completamente di tutto ciò che sento). È anche probabile che l'IP sia il lato in uscita di un proxy Web di classe business, il che spiegherebbe perché vedo Opera che lavora per qualcuno mentre qualcun altro segnala problemi dallo stesso IP.

Aggiornare

Ispirato dall'esempio di @PlanetScaleNetworks, ho cercato su Google la stringa e da lì ho finito con UA ​​Tracker per cercare stringhe base64 (o, il loro sottoinsieme che era imbottito - ho cercato "=)"). Ha restituito circa 20 User-Agent:

Aggiungerò una generosità a questa domanda, e lo spazio di risposta che sto cercando è "che tipo di software sta mettendo le stringhe di base64 in User-Agent, e perché? E c'è qualche segno di legittimità per questa pratica? "

Punto minore:

L'utente ha risolto il nostro problema utilizzando un plug-in del browser per modificare il proprio User-Agent, quindi questo è ora un problema accademico - ma penso che sia un problema accademico interessante :)

Se tutto il traffico proveniente da questo indirizzo IP è legittimo, non mi preoccuperei che la regola WAF venga attivata. Non si decodifica in una stringa leggibile dall'uomo. Quindi è stato probabilmente inserito da un dispositivo proxy a scopo di tracciamento.

Per quanto riguarda la tua preoccupazione per la RFC, sono scritti come una raccomandazione su come usare il campo , anche se c'è poca coerenza tra le piattaforme. Detto questo, è un valore definito dal client di cui non ci si può fidare in quanto è banale da modificare. Ecco perché sono necessarie le regole WAF.

Ci sono due aree in cui vedo che le stringhe User-Agent stanno diventando una preoccupazione:

1. Overflow del buffer: si tenta di overflow del buffer sul server o all'interno del sito Web / dell'applicazione. Questo chiaramente non sta accadendo nell'esempio fornito.
2. Iniezione di script / codice: fornisce script in linea, riferimenti a file remoti, ecc. Ancora una volta, chiaramente non applicabile alla tua situazione.

Se sei davvero preoccupato / paranoico, cambia la stringa User-Agent del tuo sistema in questa e sfoglia le stesse pagine mentre usi un proxy come Fiddler, Burp, ecc. Come si confronta la richiesta / risposta con l'utilizzo dell'originale Stringa User-Agent?

Non consiglierei di bloccare alcun indirizzo IP in base all'esempio fornito a meno che tutto il traffico proveniente da questo IP non sia dannoso. Anche allora dovrebbe essere bloccato solo per un tempo limitato. Meglio ancora, crea una "pagina web bloccata" con i dettagli su come sbloccare. Reindirizzare il traffico lì fino a quando non viene contattato.

Avere una stringa con codifica base64 all'interno di un User-Agent è normale o inusuale?

Scavando attraverso l'elenco dei programmi utente su WhichBrowser . È ragionevole concludere che questo è raro, ma probabilmente il risultato di un'infezione da malware.

Tuttavia, ho anche abusato di questo comportamento per aggiungere un altro livello di sicurezza al mio sito in passato, in cui solo alcuni client con un token UA base64 specifico avrebbero persino visualizzato la pagina di accesso. Allo stesso modo questa impronta digitale unica potrebbe anche essere utilizzata per servire una pagina di attacco o reindirizzare altrove.

L'uso di stringhe base64 all'interno di un User-Agent è coperto da RFC o dalle principali pratiche dei fornitori?

Non specificamente. Nulla è documentato in nessuna delle informazioni del fornitore dei browser Gecko. Negli Emirati Arabi Uniti che hai fornito, il base64 non fa parte delle informazioni sul prodotto, ma un commento. Apparentemente non ci sono restrizioni nel campo dei commenti sebbene non sia consentito avere base64 nelle informazioni sul prodotto RFC7231in quanto possono essere viste come informazioni non necessarie aggiunte alla stringa UA.

Il tuo WAF probabilmente non è in grado di identificare UA come qualcosa di specifico e forse ritorna libwww-perlperché il filtro non è specifico (falso positivo) e diventa troppo felice con il bit Linux / X11 in quanto non ha senso per il commento base64.

Effettuando un controllo online è stata rilevata questa stringa dell'agente utente sul sito closetnoc.org . Questo agente utente è stato identificato come uno dei tanti che sono stati fatta risalire a un unico indirizzo IP 192.185.1.20che è stato contrassegnato come uno spammer da list.quorum.to, bl.csma.bize spamsources.fabel.dk.

Per bloccare l'accesso a questo IP (e, a sua volta, a tale User-Agent) ...

Utilizzo di CISCO Firewall

access-list block-192-185-1-20-32 deny ip 192.185.1.20 0.0.0.0 any
permit any ip

Usando Nginx

Modifica nginx.conf e inserisci include blockips.conf; se non esiste. Modifica blockips.conf e aggiungi quanto segue:

deny 192.185.1.20/32;

Utilizzo di Linux IPTables Firewall

/sbin/iptables -A INPUT -s 192.185.1.20/32 -j DROP

Utilizzo del server Web Microsoft IIS

<rule name="abort ip address block 192.185.1.20/32" stopProcessing="true">           
    <match url=".*" />   
    <conditions>    
        <add input="{REMOTE_ADDR}" pattern="^192\.185\.1\.20$" />   
    </conditions>  
    <action type="AbortRequest" /> 
</rule>

Utilizzando Apache .htaccess

RewriteCond %{REMOTE_ADDR} ^192\.185\.1\.20$ [NC] 
RewriteRule .* - [F,L]

Fonte: closetnoc.org

Vedo anche gli user agent con codifica simil-b64. Dopo alcune analisi si scopre che si tratta di client con antivirus Kaspersky installato e in cerca di aggiornamenti.