User-Agent avec composant encodé en base64?

(Question de prime en bas)

Je rencontre un problème avec un client accédant à notre site, et la cause principale est que le WAF (Web Application Firewall) n'aime pas sa chaîne User-Agent:

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

Dans ce cas, la chaîne encodée en base64 déclenche un faux positif dans le WAF qui pense que l'agent utilisateur est libwww-perl. La chaîne base64 ne décode pas en texte lisible.

• La présence d'une chaîne codée en base64 dans un User-Agent est-elle normale ou inhabituelle?
• L'utilisation de chaînes base64 dans un User-Agent est-elle couverte par des RFC ou des pratiques des principaux fournisseurs?

J'essaie de comprendre ce qui se passe ici; Je ne pense pas que la signature WAF soit complètement hors de propos, donc je préfère ne pas simplement la désactiver, mais je n'ai jamais vu ce type de chaîne User-Agent auparavant, je préfère donc mieux comprendre à quel point elle est courante et / ou légitime un cas d'utilisation.

Le site est conçu pour être utilisé par les humains avec des navigateurs - ce n'est pas une API ou quelque chose comme ça - et il m'a été signalé que l'utilisateur a essayé d'accéder au site avec "FF / IE / Chrome" et a échoué. Cependant, je montre des connexions réussies à partir de la même IP cliente avec un agent utilisateur Opera:

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

C'est un peu étrange que l'utilisateur signale avoir essayé IE, mais toutes les chaînes User-Agent que je vois semblent être Linux. (Comme d'habitude, le contact avec l'utilisateur final passe par plusieurs parties, je ne peux donc pas faire entièrement confiance à ce que j'entends). Il est également probable que l'IP soit le côté sortant d'un proxy Web de classe affaires, ce qui expliquerait pourquoi je vois certains Opera travailler pour quelqu'un tandis que quelqu'un d'autre signale des problèmes à partir de la même IP.

Mise à jour

Inspiré par l'exemple de @PlanetScaleNetworks, j'ai googlé la chaîne et à partir de là j'ai fini par utiliser UA Tracker pour rechercher des chaînes base64 (ou, le sous-ensemble d'entre elles qui ont été remplies - j'ai cherché "=)"). Il a renvoyé environ 20 User-Agents:

Je vais ajouter une prime à cette question, et l'espace de réponse que je recherche est "quel type de logiciel met des chaînes base64 dans les User-Agents, et pourquoi? Et y a-t-il une marque de légitimité pour cette pratique? "

Point mineur:

L'utilisateur a contourné notre problème en utilisant un plugin de navigateur pour modifier son User-Agent, donc c'est maintenant un problème académique - mais je pense que c'est un problème académique intéressant :)

Si tout autre trafic provenant de cette adresse IP est légitime, je ne m'inquiéterais pas du déclenchement de la règle WAF. Il ne se décode pas en une chaîne lisible par l'homme. Il a donc probablement été inséré par un périphérique proxy à des fins de suivi.

En ce qui concerne vos préoccupations concernant la RFC, elles sont écrites comme une recommandation sur la façon dont le champ doit être utilisé, bien qu'il y ait peu de cohérence entre les plateformes. Cela étant dit, c'est une valeur définie par le client à laquelle on ne peut pas faire confiance car elle est triviale à modifier. C'est pourquoi les règles WAF sont nécessaires.

Il y a deux domaines dans lesquels je vois les chaînes User-Agent devenir une préoccupation:

1. Buffer Overflow - essayez de déborder le tampon sur le serveur ou dans le site Web / l'application. Cela ne se produit clairement pas dans l'exemple fourni.
2. Injection de script / code - fournissant des scripts en ligne, des références à des fichiers distants, etc. Encore une fois, clairement pas applicable à votre situation.

Si vous êtes vraiment inquiet / paranoïaque, remplacez la chaîne User-Agent de votre propre système par celle-ci et parcourez les mêmes pages tout en utilisant un proxy tel que Fiddler, Burp, etc. Comment la demande / les réponses se comparent-elles à l'utilisation de votre original Chaîne de l'agent utilisateur?

Je ne recommanderais pas de bloquer les adresses IP sur la base de l'exemple fourni, sauf si tout le trafic provenant de cette IP est malveillant. Même alors, il ne devrait être bloqué que pour une durée limitée. Mieux encore, créez une "page Web bloquée" avec des détails sur la façon de débloquer. Redirigez le trafic jusqu'à ce qu'il soit contacté.

La présence d'une chaîne codée en base64 dans un User-Agent est-elle normale ou inhabituelle?

Creuser dans la liste des agents utilisateurs sur WhichBrowser . Il est raisonnable de conclure que cela est rare, mais peut-être le résultat d'une infection par un logiciel malveillant.

Cependant, j'ai également abusé de ce comportement pour ajouter une autre couche de sécurité à mon propre site dans le passé, où seuls quelques clients avec un jeton UA ​​base64 spécifique pouvaient même afficher la page de connexion. De même, cette empreinte unique pourrait également être utilisée pour servir une page d'attaque ou rediriger ailleurs.

L'utilisation de chaînes base64 dans un User-Agent est-elle couverte par des RFC ou des pratiques des principaux fournisseurs?

Pas spécifiquement. Rien n'est documenté dans les informations du fournisseur des navigateurs Gecko. Dans l'UA que vous avez fournie, la base64 ne fait pas partie des informations sur le produit, mais d'un commentaire. Il n'y a apparemment aucune restriction du champ de commentaire, bien que la présence de base64 dans les informations sur le produit ne soit pas autorisée par RFC7231car elle peut être considérée comme des informations inutiles ajoutées à la chaîne UA.

Votre WAF ne peut probablement pas identifier l'UA comme quelque chose de spécifique et peut-être retourne libwww-perlparce que le filtre n'est pas spécifique (faux positif) et est trop satisfait du bit Linux / X11 car il ne peut pas donner un sens au commentaire base64.

Faire une vérification en ligne est tombé sur cette chaîne d'agent utilisateur sur le site closetnoc.org . Cet agent utilisateur a été identifié comme étant l' un d'un certain nombre qui ont été tracées à une seule adresse IP 192.185.1.20qui a été signalé comme spammeur par list.quorum.to, bl.csma.bizet spamsources.fabel.dk.

Pour bloquer l'accès à cette IP (et à son tour à cet User-Agent) ...

Utilisation du pare-feu CISCO

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

Utilisation de Nginx

Modifiez nginx.conf et insérez include blockips.conf; s'il n'existe pas. Modifiez blockips.conf et ajoutez ce qui suit:

deny 192.185.1.20/32;

Utilisation du pare-feu Linux IPTables

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

Utilisation de Microsoft IIS Web Server

<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>

Utilisation d'Apache .htaccess

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

Source: closetnoc.org

Je vois aussi des agents utilisateurs encodés simil-b64. Après quelques analyses, il s'avère que ce sont des clients sur lesquels l'antivirus Kaspersky est installé et qui recherchent des mises à jour.