了解 Wapiti 结果答案

【问题标题】：Understanding Wapiti results了解 Wapiti 结果
【发布时间】：2011-04-10 13:50:09
【问题描述】：

我在我的网络服务器上运行 Wapiti。我在前后转储数据库，删除了时间戳的最后一行，发现两个文件都有相同的哈希值，所以我知道数据库没有改变。

但根据报告，我没有通过多项测试。这是信息中的数据

500 HTTP Error code.
Internal Server Error. The server encountered an unexpected condition which prevented it from fulfilling the request.

    * World Wide Web Consortium: HTTP/1.1 Status Code Definitions
    * Wikipedia: List of HTTP status codes

似乎每一个都是由 ASP.NET 不喜欢的格式错误的字符串引起的（注意我使用带有 xsp 的 debian 机器来托管。它运行良好）。

我应该不在乎生成的报告说什么吗？我应该只通过手动浏览页面来检查是否有任何更改或损坏吗？

    SQL Injection (1)   Blind SQL Injection (2)     File Handling (3)   Cross Site Scripting (4)    CRLF (5)    Commands execution (6)  Resource consumption (7)    Htaccess Bypass (8)     Backup file (9)     Potentially dangerous file (10) 
High    14  14  13  0   0   14  0   0   0   0
Medium  0   0   0   0   0   0   0   0   0   0
Low     0   0   0   0   0   0   0   0   0   0

【问题讨论】：

标签： asp.net security wapiti

【解决方案1】：

数据库恢复是一个非常好的主意。您确实需要一个填充的数据库来获得适当的代码覆盖率。您还需要确保启用了错误报告，讨厌的输入必须导致 sql 错误，否则 wapiti 可能找不到它。 Wapiti 确实有盲目的 sql 注入测试，但它并不准确。

我会查看./wapiti.py http://yourdomain.com 的正常输出，这将列出所有发现的漏洞，然后您可以修补它们。完成第一轮补丁后，重新运行 wapiti 以确保补丁正常工作。它生成的报告主要是为不知道漏洞是什么的经理等提供的，他们只是想知道自己是否安全。 SQL 注入可能不会损坏数据库或任何页面，Wapiti 确实会进行存储的 xss 测试，这会损坏页面，但如果您正在恢复数据库，那么一切都应该没问题。

【讨论】：

看来都是因为 xsp/mono/apache 不喜欢输入字符串。 AFAIK 一切都很好。我查看了正常的输出，但不幸的是我不记得它说了什么。所以我觉得我很好。
@acidzombie24 这听起来不太可能。由于讨厌的输入，它看到了一个 SQL 错误，一般错误不会产生误报。您的逃生方法很可能很弱。只是出于好奇，您是否推出了自己的逃生套路？您是否正确使用它们？甚至 mysql_real_escape_string() 也可能被误用...

【解决方案2】：

如果你想测试sql注入，我推荐使用一个特别擅长的工具。即：

sqlmap

http://sqlmap.sourceforge.net/

请注意，debian 存储库版本已经过时了。

【讨论】：