1

我在我的网络服务器上运行了 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
4

2 回答 2

0

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

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

于 2010-09-10T17:27:19.877 回答
0

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

sqlmap

http://sqlmap.sourceforge.net/

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

于 2011-09-17T15:00:19.020 回答