Question

我最近对我工作的其中一个网站进行了安全审核。这是通过Acunetix Web漏洞扫描程序完成的。这回来了一堆我正在整理的结果。

很多关于XSS的点击都出现了，但我不确定它们是否是误报。

代码如：

if(isset($_GET['variableNameX']))
    $var_to_use_in_app = mysql_escape_string(trim($_GET['variableNameX']));

回来对XSS开放。任何带有查询字符串的页面都会回来，因为它可能对XSS开放，或者它是否足够聪明，知道我正在处理这个服务器端？

感谢您的帮助。

Answer 1

如果有传入querystring参数的HTML，你会在页面上显示吗？如果是这样，那不是误报。

换句话说，如果你通过了这样的事情： 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> （可能编码......但你明白了）

Answer 2

$ var_to_use_in_app = mysql_escape_string（trim（$ _ GET ['variableNameX']））;

这通常是错误的做法。应用程序内部使用的字符串应始终为纯文本版本。那么你可以肯定的是，你的字符串操作都不会破坏它，你也不会向页面输出错误的东西。

例如，如果您有提交的字符串：

O'Reilly

mysql_escape_string会将其转义为：

O\'Reilly

当你将该字符串输出到HTML页面时，看起来很傻。如果你把它输出到一个然后再次提交的表单字段，你会得到另一个反斜杠，它会变成两个黑色斜杠，如果再次编辑它会变成四个，八个......和不久你就会得到由数百个反斜杠组成的字符串。这是一个常见的问题，在写得不好的CMS和服务器上启用了恶魔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的parameterised queries。

对于HTML，应使用htmlspecialchars（）函数进行转义：

<div id="greeting">
    Hello, Mr. <?php echo htmlspecialchars($name); ?>!
</div>

您可以定义一个执行echo（htmlspecialchars（））但具有较短名称（例如h（））的函数，以使其稍微不那么难看。

如果您错过了对htmlspecialchars的调用，那么您的扫描仪绝对正确地告诉您您的站点容易受到XSS攻击。但是不要觉得太糟糕，几乎所有其他PHP程序员都会犯同样的错误。

mysql_ [real_] escape_string在这里根本没有帮助，因为在HTML中突破文本的字符是'＆amp;'，'＆lt;'，并且在属性中，'''。这些都不是在SQL字符串文字中很特别，所以mysql_escape_string根本不会触及它们。恶意：

<script>alert("I'm stealing your cookies! "+document.cookie);</script>

只有转义为：

<script>alert("I\'m stealing your cookies! "+document.cookie);</script>

就安全而言，无论如何都无济于事。

Answer 3

Acunetix是一个不错的工具，但它不能替代基于手动的App Penetration Testing。它没有逻辑来跟踪潜在的漏洞......

它肯定在银行中使用，我已在建议书（已批准）中推荐它进行正式的工作。如果您有一个相当复杂的应用程序，其中包含大量动态生成的页面，并且预算/时间是一个问题，您可以使用Acunetix或类似工具启动，以指示您使用应用程序的潜在热点方向。然后，您可以通过手动方式关注这些区域 - 无论是手动测试还是单步调试。这是您的Pen Test house获得条纹的地方。

客户根本没有足够的资源来彻底浏览大型应用程序。

哦，请记住，有很多误报。

Answer 4

我不知道具体的工具，但它不太可能“知道”你在服务器端处理它，因为这需要在一般情况下解决等价问题。除此之外，该工具甚至可以访问您的mysql实例吗？怎么会知道？

Answer 5

我使用过的很多工具都会带来误报。如果它正在审核实际代码，那么可能会返回一个潜在的漏洞，并且将$ _GET或$ _POST变量分配给正常变量，即使它稍后没有打印出来。

为了安全起见，你应该检查一切，并假设没有任何误报。

安全扫描现场

5 个答案: