了解马鹿的结果

时间:2010-09-10 03:54:39

标签: asp.net security wapiti

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

2 个答案:

答案 0 :(得分:0)

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

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

答案 1 :(得分:0)

如果你想测试sql注入,我建议使用一个特别擅长的工具。即:

<强>的SqlMap

http://sqlmap.sourceforge.net/

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