1

Web サーバーで 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 インジェクション テストがありますが、それほど正確ではありません。

からの通常の出力を見ると、./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 に答える