19

アプリの URL で合理的なアプリ スキャンを実行すると、次の結果が返されます。

Web サーバーは、次の HTTP メソッド (動詞) の 1 つ (または複数) を許可するように構成されているようです - DELETE - SEARCH - COPY - MOVE - PROPFIND - PROPPATCH - MKCOL - LOCK - UNLOCK - PUT

これを修正するために、これらのメソッドを禁止する RewriteRule を追加しました。手動でテストすると、応答コード 403 が返されます。

curl -X PUT https://someurl.com/somecontext/somepage.xhtml

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /somecontext/somepage.xhtml
on this server.</p>
</body></html>

しかし、Rational app scan はこれを問題として示しています。誰かが同じ問題に遭遇しましたか。この URL は、AJP 経由で tomcat バックエンドに移動します。これに対する解決策をいただければ幸いです。

PS: Limit と LimitExcept を念頭に置いていましたが、mod_proxy または mod_jk 経由のリクエストをブロックするかどうかはわかりません

4

4 に答える 4

19

最終的にうまくいった簡単な解決策

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)
RewriteRule .* - [R=405,L]

これにより、アプリのスキャンが快適になります（そして私も）

于 2013-04-16T06:46:47.173 に答える
7

Apache が OPTIONS リクエスト (サポートされる可能性のあるメソッドのリストを取得する) を Tomcat に転送していると思われます。次に、 のデフォルトの HttpServlet 実装を取得します。これは明らかにヘッダーをdoOptions返します。AllowTRACE

doOptionsこの誤解を招くリストから削除するようにオーバーライドできますTRACE。たとえば、Apache と一致させることができます。

response.setHeader("Allow", "OPTIONS, GET, HEAD, POST");

または、OPTIONS の他の機能 (CORS プリフライトなど) が必要ないことが確実な場合は、OPTIONS を完全にブロックすることもできます。ちなみに、mod_rewrite 処理チェーンにドラッグするのではなく、Mod_access と一緒にLimitを使用して、目的のメソッドへのアクセスを制限することもできます。

または、実際に持っていない、TRACEまたは他の不要な方法が利用可能であることが確実な場合は、その結果を無視することができます. AppScan は、利用可能な危険な方法がいくつかあるように見えることを警告しようとしていますが、実際にはそのような脆弱性は発見されていません。実際には機能しない戻りメソッドを持つことは望ましくありませんが、実際のセキュリティ上の問題ではありません。OPTIONS

于 2013-04-12T14:26:29.183 に答える
6

最初に Apache の httpd.conf で以下の conf を設定して、脆弱な HTTP メソッド [TRACE|TRACK|PUT|DELETE|CONNECT|OPTIONS] を無効にしましたが、うまくいきませんでした。

    RewriteEngine on

    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|PUT|DELETE|CONNECT|OPTIONS)

    RewriteRule .* - [F]

これで、ルールとその動作を以下に設定しました。

 Order allow,deny

 Allow from all

 <LimitExcept POST GET>

       Deny from all

 </LimitExcept>

于 2015-05-27T04:32:05.960 に答える