3

Zend Framework MVCアプリケーションでは、GETとPOSTの2つのリクエストメソッドのみを使用しています。他の要求タイプ（PUTやDELETEなど）を受信した場合に例外をスローするために、ベースコントローラーにチェックを入れる必要があるかどうか疑問に思っています。

私が見る限り、考慮すべき2つの領域があります。

  1. それはセキュリティをまったく改善しますか？フレームワークがPUT、DELETEなどに応答することを許可した場合、潜在的なハッカーに有利なスタートを切ることができますか？
  2. サイトの正しい運用に支障をきたしますか？たとえば、検索エンジンボットはGETとPOST以外のリクエストに依存していますか？

あなたのアイデアは大歓迎です！

4

2 に答える 2

2

正しい応答コードは405 Method Not Allowed、Allow: GET, POST ヘッダーを含めてです。

10.4.6405メソッドは許可されていません

Request-Lineで指定されたメソッドは、Request-URIで識別されたリソースには許可されていません。応答には、要求されたリソースの有効なメソッドのリストを含むAllowヘッダーを含める必要があります。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

于 2013-03-24T02:22:30.790 に答える
1

人々は、エラーが原因で、または意図的にアプリ/フレームワーク/サイトなどの API に違反し、サイトの弱点を調査します。(あなたのサイトが内部専用またはパブリック ネット上にある場合にのみ、頻度が重要になります。)

あなたのサイトが開発者をサポートしている場合、それが 405 code of method not allowed で応答する理由として考えられます。おそらく、セッション (セッションを想定) が開発者モードであるとマークされている場合のみです。

正当な開発者を期待していない場合は、悪意のある人にとってより困難にするために、悪い入力を黙って飲み込むことをお勧めします。

通常のケースでエラー メッセージを表示しないもう 1 つの理由: 特定のケースでエラー メッセージが表示されない場合、不良データが他のデータよりもスタックの奥にあると解釈され、攻撃経路の可能性が示されます。

最後に、エラー リターン (タイプ、応答前の遅延など) を使用して、アプリ/フレームワークなどの特定のバージョンを特徴付けることができます。攻撃ベクトルが見つかったら、これを使用して、他の脆弱なインストールをすばやく見つけることができます。

はい、上記は悲観的です。誰もがping、echo、およびその他の診断要求に応答した80年代を懐かしく思い出します。しかし、悪者はここにいます。システムを強化するのは私たちの責任です。詳細については、このTED ビデオをご覧ください。

于 2013-03-24T08:48:12.557 に答える