我在我的网络服务器上运行了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发布于 2010-09-11 01:27:20
数据库恢复是一个非常好的想法。您确实需要一个已填充的数据库来获得适当的代码覆盖率。您还需要确保启用了错误报告,讨厌的输入必须导致sql错误,否则wapiti可能找不到它。Wapiti确实有盲目的sql注入测试,但它并不准确。
我会查看./wapiti.py http://yourdomain.com的正常输出,这将列出所有发现的漏洞,然后您可以对它们进行修补。完成第一轮补丁后,重新运行wapiti以确保补丁正常工作。它生成的报告主要是为那些不知道漏洞是什么的管理者和类似的人准备的,他们只想知道自己是否安全。SQL注入可能不会损坏数据库或任何页面,Wapiti确实会做存储的xss测试,这会损坏一个页面,但如果您正在恢复数据库,那么一切都应该很好。
发布于 2011-09-17 23:00:19
如果你想测试sql注入,我推荐使用一个特别擅长sql注入的工具。即:
sqlmap
http://sqlmap.sourceforge.net/
请注意,debian存储库版本已经非常过时了。
https://stackoverflow.com/questions/3682157
复制相似问题