用户代理与base64编码的组件？

（底部的赏金问题）

客户端访问我们的网站时遇到问题，根本原因是WAF（Web应用程序防火墙）不喜欢其User-Agent字符串：

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

在这种情况下，base64编码的字符串会触发WAF中的误报，认为用户代理是libwww-perl。base64字符串不会解码为任何可读文本。

• 用户代理内部是否包含base64编码的字符串，这是正常的还是异常的？
• 任何RFC或主要供应商惯例是否涵盖了在User-Agent中使用base64字符串？

我试图了解这里发生的事情；我不认为WAF签名与对象完全不符，所以我宁愿不只是禁用它，而且之前我还没有看过这种User-Agent字符串，所以我宁愿更好地理解它的通用性和/或使此用例合法。

该网站是专为人类使用浏览器而设计的-它不是API或类似的东西-并向我报告说，该用户尝试使用“ FF / IE / Chrome”访问该网站，但失败了。但是，我确实显示了来自同一客户端IP与Opera用户代理的成功连接：

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

用户报告曾尝试使用IE，但我看到的所有User-Agent字符串似乎都是Linux，这有点奇怪。（与往常一样，与最终用户的联系是通过多方协调的，因此我无法完全相信听到的任何声音）。IP也很可能是业务类Web代理的出站端，这可以解释为什么我看到某些Opera在为某人工作而其他人报告了同一IP的问题。

更新资料

受@PlanetScaleNetworks示例的启发，我搜索了字符串，然后从那里使用UA Tracker搜索base64字符串（或被填充的子集-我搜索了“ =）”）。它返回了大约20个用户代理：

我将为这个问题增加赏金，我正在寻找的答案空间是“哪种软件将base64字符串放入User-Agent中，为什么？这种做法是否合法？ ”

次要点：

用户通过使用浏览器插件修改其User-Agent来解决我们的问题，所以这现在是一个学术问题-但我认为这是一个有趣的学术问题：）

如果来自该IP地址的所有其他流量都是合法的，那么我不必担心会触发WAF规则。它不会解码为人类可读的字符串。因此，它很可能是由代理设备插入以进行跟踪的。

关于你提到的有关RFC的关注，他们写成如何领域的建议，应该使用虽然有平台之间很少具有一致性。话虽这么说，它是客户端定义的值，因为它很容易修改，因此无法信任。因此，为什么需要WA​​F规则。

我看到用户代理字符串在两个方面引起关注：

1. 缓冲区溢出-尝试使服务器或网站/应用程序中的缓冲区溢出。在提供的示例中显然没有发生这种情况。
2. 脚本/代码注入-提供内联脚本，对远程文件的引用等。同样，显然不适用于您的情况。

如果您真的很担心/偏执，请将您自己的系统的User-Agent字符串更改为该字符串，并使用诸如Fiddler，Burp等的代理浏览相同的页面。用户代理字符串？

我不建议您根据所提供的示例阻止任何IP地址，除非来自该IP的所有流量都是恶意的。即使这样，它也只能在有限的时间内被阻止。更好的是，创建一个“阻止的网页”，其中包含有关如何取消阻止的详细信息。将流量重定向到那里，直到联系为止。

用户代理内部是否包含base64编码的字符串，这是正常的还是异常的？

在WhereBrowser中浏览用户代理列表。可以合理地得出结论，这种情况很少见，但可能是恶意软件感染的结果。

但是，我过去也滥用这种行为在自己的站点上添加了另一个安全层，在该站点中，只有少数具有特定base64 UA令牌的客户端甚至会显示登录页面。同样，这种独特的指纹也可以用于提供攻击页面或重定向到其他位置。

任何RFC或主要供应商惯例是否涵盖了在User-Agent中使用base64字符串？

不具体。Gecko浏览器的任何供应商信息均未记录任何内容。在您提供的UA中，base64不是产品信息的一部分，而是注释。尽管不允许在产品信息中使用base64，但注释字段似乎没有任何限制，RFC7231因为可以将其视为附加到UA字符串的不必要信息。

您的WAF可能无法将UA识别为特定的任何东西，并且可能会返回，libwww-perl因为过滤器是非特定的（误报），并且对Linux / X11有点满意，因为它无法理解base64注释。

在网站closetnoc.org上遇到了在线检查的用户代理字符串。此用户剂识别为已经被追踪到一个单一的IP地址的数目中的一个192.185.1.20已经由标记为垃圾邮件发送者list.quorum.to，bl.csma.biz和spamsources.fabel.dk。

要阻止访问此IP（以及该User-Agent）...

使用CISCO防火墙

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

使用Nginx

编辑nginx.conf并插入include blockips.conf; 如果不存在。编辑blockips.conf并添加以下内容：

deny 192.185.1.20/32;

使用Linux IPTables防火墙

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

使用Microsoft IIS Web服务器

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

使用Apache .htaccess

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

资料来源：closetnoc.org

我也看到了simil-b64编码的用户代理。经过一些分析，结果表明客户端是安装了卡巴斯基防病毒软件并正在寻找更新的客户端。