1

Facebookアプリケーションを使用する必要がありますが、私のWebページは200ではなく206の応答を返すため、Facebookアプリケーションはhttpコード500を返します。

http://developers.facebook.com/tools/debug/og/object?q=http://adserver.leadhouse.net/test/test/index.phpでテストし、joomla.itの代わりに206を返します。それらは同じカールです-I応答データ

私はこのperlスクリプトでテストしました：http：//pastebin.com/NCDv9eTh そして私のページはjoomla.itの代わりに脆弱です。

私の答えは Facebookデバッガーの間で非常に近いと思います：応答206 とApacheWebサーバーのセキュリティと最適化のヒント

しかし、apacheの構成をどのように変更するのかわかりません。解決策は次のページにあります：www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2同様のコード：

    SetEnvIf Range (,.*?){5,} bad-range=1
    RequestHeader unset Range env=bad-range

またはhttpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

Webページに対する脆弱性を減らすにはどうすればよいですか？

4

2 に答える 2

1

ここでどのような「脆弱性」について話しているのかわかりません。

応答ステータスコード206を示すFacebookデバッガーは正常です。これは、デバッガーがURLから最初のx（K）バイトのみを要求しようとするためです。サーバーがそのような範囲要求を受け入れて正しく応答する場合、応答コードは206になります。

その中に脆弱性はありません。

これによりサイトに他の問題が発生する場合は、わかりやすい方法で説明してください。

于 2012-06-26T15:05:11.090 に答える
0

はい、すべてはFacebookのデバッグから始まります。ダイアログは私のページで500httpコードを返します。206httpコードを返します。そして私の好奇心は、perlスクリプトhttp://pastebin.com/NCDv9eThをテストしたときのhttpコード206のDoS脆弱性に焦点を当てています。

私はapacheドキュメントについていくつかの重要なフレーズを報告します：

この脆弱性は、「サービス拒否」攻撃に関係しています。つまり、リモートの攻撃者は、適切な状況下で、サービスまたはサーバーの速度を低下させ、要求を処理するために使用できるメモリをクロールまたは使い果たし、正当なクライアントにタイムリーにサービスを提供できなくなります。

これがリモートエクスプロイトにつながるという兆候はありません。サードパーティがセキュリティを危険にさらし、サーバー自体の足がかりを得る可能性がある場合。この脆弱性の結果は、サーバーを停止状態にし、サーバーへの追加の接続を拒否することにより、サービスを拒否することの1つです。

LimitRequestFieldSize回避策が不十分なため、Apache wikiドキュメントに関する段落を参照してパラメータを変更できます：Rangehttp ： //wiki.apache.org/httpd/CVE-2011-3192 リターンhttpコード間の切り替えを取得します：206から200。構成されていますが、DoSの脆弱性にさらされています。Mitigation

私はこの行を追加mod_headersしました：

RequestHeader unset Range

そして今、私のページはhttpコード200を返します。そしてリクエストを処理するために利用可能なメモリの枯渇を制限するために、私mod_limitipconnはこのコードで追加するIP接続を制限します：

MaxConnPerIP 10
于 2012-07-29T20:43:55.647 に答える