我最近对我工作的一个网站进行了安全审计。这是通过 Acunetix Web Vulnerability Scanner 完成的。这带来了一堆我正在整理的结果。
出现了很多关于 XSS 的点击，但我不确定它们是否是误报。
代码如：
if(isset($_GET['variableNameX']))
$var_to_use_in_app = mysql_escape_string(trim($_GET['variableNameX']));
以对 XSS 开放的方式回归。任何带有查询字符串的页面是否会返回可能对 XSS 开放，或者它是否足够聪明，知道我正在处理这个服务器端？
谢谢您的帮助。
如果有 HTML 传递给 querystring 参数，你会在页面上显示它吗？如果是这样，这不是误报。
换句话说，如果你通过有这样的东西： http ://www.example.com/?myVar=Test
并且您在页面上显示 myVar 的结果而无需测试 HTML/Script，那么有人可能会将其更改为： http ://www.example.com/?myVar=<b>Test</b> ；
或者类似的东西： http ://www.example.com/?myVar=<script>+doSomethingBad()+</script> ; （可能编码......但你明白了）
$var_to_use_in_app = mysql_escape_string(trim($_GET['variableNameX']));
这通常是错误的做法。应用程序内部使用的字符串应始终是纯文本版本。然后你可以确定你的任何字符串操作都不会破坏它，并且你不会向页面输出错误的东西。
例如，如果您有提交的字符串：
O'Reilly
mysql_escape_string 会将其转义为：
O\'Reilly
当您将该字符串输出到 HTML 页面时，它看起来很傻。如果你把它输出到一个表单域，然后再次提交，你会得到另一个反斜杠，它会变成两个黑斜线，如果再次编辑会变成四个，八个......不久你就得到了由数百个反斜杠组成的字符串。这是在编写不佳的 CMS 和打开了 evil magic_quotes 功能的服务器中常见的问题。
然后，如果您想将名称的前两个字母放入数据库查询中，则可以剪切子字符串：
O\
然后将其连接到查询中：
SELECT * FROM users WHERE namefirst2='O\';
哎呀，语法错误，该字符串现在未终止。对预转义字符串进行字符串处理的变体同样容易让您陷入安全问题。
除了在最终输出阶段将它们连接成 SQL 或 HTML 中的定界文字外，您可以在应用程序中的任何地方将字符串作为简单的未转义文本字符串保存，而不是这种方法。对于 SQL：
"SELECT * FROM users WHERE name='".mysql_real_escape_string($name)."';"
请注意“真实”函数名称——普通旧的 mysql_escape_string 对于东亚字符集和使用 ANSI SQL_MODE 集的连接/数据库等极端情况会失败，因此通常您应该始终使用“真实”版本。
您可以定义一个与 mysql_real_escape_string 相同但名称更短的函数（例如 m()），以使其不那么难看。或者，更好的是，查看 mysqli 的参数化查询。
对于 HTML，应该使用 htmlspecialchars() 函数进行转义：
<div id="greeting">
Hello, Mr. <?php echo htmlspecialchars($name); ?>!
</div>
您可以定义一个执行 echo(htmlspecialchars()) 但名称更短的函数（例如 h()），以使其不那么难看。
如果您错过了对 htmlspecialchars 的调用，那么您的扫描器绝对正确地告诉您您的网站易受 XSS 攻击。但不要觉得太糟糕，几乎所有其他 PHP 程序员都会犯同样的错误。
mysql_[real_]escape_string 在这里根本没有帮助，因为在 HTML 中从文本中分离出来的字符是 '&'、'<'，并且在属性中是 '"'。这些都不是特殊的SQL 字符串文字，所以 mysql_escape_string 根本不会触及它们。恶意：
<script>alert("I'm stealing your cookies! "+document.cookie);</script>
只会逃到：
<script>alert("I\'m stealing your cookies! "+document.cookie);</script>
就安全性而言，这没有任何帮助。
Acunetix 是一个不错的工具，但它不能替代基于手动的应用程序渗透测试。它没有遵循潜在漏洞的逻辑......
它肯定在银行中使用，我在提案（已获批准）中推荐它来进行正式的工作。如果你有一个相当复杂的应用程序，它有很多动态生成的页面并且预算/时间是一个问题，你可以使用 Acunetix 或类似的工具来引导你指向应用程序潜在热点的方向。然后，您可以通过手动方式专注于这些领域 - 无论是手动测试还是逐步执行代码。这就是您的渗透测试机构赢得荣誉的地方。
客户根本没有资源彻底通过大型应用程序。
哦，请记住，有很多误报。
我不知道具体的工具，但它不太可能“知道”您正在服务器端处理它，因为这需要在一般情况下解决等效问题。除此之外，该工具甚至可以访问您的 mysql 实例吗？它怎么知道？
我使用的很多工具都会返回误报。如果它正在审核实际代码，那么可能会返回一个潜在的漏洞，并且将 $_GET 或 $_POST 变量分配给正常变量，即使它稍后没有被打印出来。
为了安全起见，您应该检查所有内容并假设没有什么是误报。