我看不出在用户代理字符串中插入转义引号是一个漏洞。

我不确定情况是否如此，我认为需要更多信息。我能想到的唯一一件事是他们可能暴露了会话劫持的可能性。

基本上， PHPSESSID=08rtvlq03bd9d57qor4abjg7q4 属于不同用户的会话，他们通过 cookie 欺骗此会话 ID，并得到正常响应，即使用户代理已从原始用户更改。

澄清：

用户 A 使用以下 User-Agent 字符串打开网站：

Mozilla Compatible (MSIE)

然后为用户 A 分配以下会话 ID：

08rtvlq03bd9d57qor4abjg7q4

用户 B（坏人）然后使用他/她的 cookie 中具有相同会话 ID 的 cookie 向服务器发送请求，但是他们的 User-Agent 字符串是：

\"

然后，您的应用程序应该意识到这不是同一个用户，并销毁会话。

我绝不肯定这是这种情况，监控用户代理也不会阻止会话劫持，因为用户代理很容易被欺骗，但这是我在这里看到的唯一潜力。

注入用户代理（或相关的引用）值可能会以多种方式成为潜在威胁，但是如果您当前的情况实际上是一个漏洞，那么如果不查看系统的整体情况就很难判断。

我经常看到以某种方式使用用户代理的系统。通常它用于存储有关最常用浏览器和类似浏览器的信息。有时，被称为机器人的用户代理会受到不同的对待。有很多情况。

注射

在用户代理领域尝试 XSS 攻击的情况并不少见。例如，我前一段时间正在测试的一个网站向我展示了一些关于我自己的信息。

有趣的是，它将用户代理输出回给我。当我注入用户代理'FooBar"> <img src="javascript:alert('document.cookie')'时，它会提醒我。

现在，为了将这种攻击用于其他用户，该网站还有一个统计页面，其中显示了平均每天有多少用户，最常见的浏览器是什么等等。这些数字似乎是基于请求的数量。构建一个使用我的 XSS 发出足够多请求的快速脚本，只需将我的用户代理放在前 100 名列表中，并且该向量现在是持久的并与其他用户一起工作

SQL 注入也有同样的可能。尝试使用 useragent 到处跑Im Harmless";DROP TABLE users。也许你破坏了一些系统。

探测漏洞

像示例中一样输入 /" 看看会发生什么。也许你会收到一条错误消息，或者网站上的其他地方发生了一些事情。

检查如果您使用非常旧的用户代理或搜索引擎用户代理会发生什么有时会非常有用。有时这是解锁网站上某些内容并探测该内容是否存在漏洞的唯一方法。

通过使用例如Burpsuite，后者很容易实现自动化，然后快速浏览所有不同的请求以查找差异。

编辑：在您的具体示例中，发出请求的客户端似乎已将用户代理设置为 \" 。如果这是故意的，则很难判断一个错误或只是隐藏其用户代理的人，但我肯定会调查该用户提出的其他请求。

他们试图向你推销本应毫无价值的东西。

HTTP 协议允许这种东西。我可以将用户代理（AKA，“您使用哪种浏览器？”）设置为"User Agent: User Agent: User Agent: Trust no one"

如果您的软件没有以现代方式考虑代码注入（SQL、脚本等），那么这可能是一个问题。但是您使用最佳实践编写了您的软件，并且正确地清理了所有输入，并且使用了数据库抽象层，对吧？

就提高安全性的方法而言，监控诸如来源、请求频率、分析他们提出的请求、检查用户代理、检查引荐来源页面、检查……一切，是一种主动监控，您可以通过这种方式提供更多安全性。我不相信这是他们试图告诉你做的事情（根据亚历克斯的部分回答），只是“你可以改变这个”，对于任何足够了解 HTTP 的人来说，这完全是“不行的” ，但可能只是吓跑一些增值绒毛的一种方式。

因此，如果您的 PHP 代码允许任何输入 - 包括 - 将用户代理字符串插入数据库而没有经过适当清理，并且使用数据库抽象层，那么您将度过一个非常糟糕的一天。

我会给你一个免费的提示，你的推荐人标题可以设置为：

Referrer: \' -- TRUNCATE `Users`

问题不在于您可以设置这些标头，您可以轻松地将这些数据作为地址表单中的“名称”提交。

那么问题来了，您是否想让那些在某处表格中没有您的用户代理的人不使用您的网站？可能是一个愚蠢的想法，因为hacker无论如何 a 都可以将其设置为有效的。

答案很简单。不要在没有先清理它的情况下在响应的内容中包含传递给请求的任何标头值。就此而言，在没有首先清理数据的情况下，永远不要以任何方式使用任何用户提供的数据。始终清理输入。

如果您的内容中未包含客户端传递的标头值，则可以忽略此警告。