用户代理与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来解决我们的问题,所以这现在是一个学术问题-但我认为这是一个有趣的学术问题:)