大きなhttp本文サイズを許可することの潜在的な脆弱性は何ですか？
NGINXとPHPを使用すると、5GBのファイルをサーバーに「アップロード」することができますが、「正当」でない限りダウンロードされません（別の質問です;））。これにより、DDOS攻撃やその他の攻撃が容易になるのでしょうか、それとも、1つの大きなリクエストが同じくらい多くの小さなhttpリクエストよりも少なくない場合でも同じであるため、通常と同じくらい脆弱です。
私は答えに行きますが、私はこの特定のトピックの専門家でもないので、入ってくるかもしれない他の答えを読みたいと思います。
短い答えはこれだと思います。大きなHTTPポストボディを許可することは確かにDOS攻撃への道を提供しますが、それは必ずしもDOS攻撃にとって最も魅力的な道ではありません。結果として、最大のボディサイズを必要以上に大きく設定しないことは確かですが、大きなポストボディが必要な場合は、それを許可し、あまり心配しません。詳細に：
推奨されるDDOS攻撃ベクトル
ウェブサイトをDOS化する方法はたくさんあります。最近の最大のDDOS攻撃は、増幅されたDDOS攻撃によるものです。これらは、（通常）少量のトラフィックを受信し、インターネット上の任意のIPアドレスに送信されるはるかに大量のトラフィックで応答できるUDPプロトコルを攻撃する攻撃です。たとえば、最大のDDOS攻撃の現在の（2018年3月）レコードは、このような攻撃ベクトル（ https://githubengineering.com/ddos-incident-report/ ）を使用してgithubにヒットしました。これらの種類の攻撃は、ターゲットサーバーのネットワーク容量を完全に圧倒し、攻撃が続く限りサーバーを停止させようとします。
Githubインシデントで使用されたベクトルの増幅係数は〜51,000でした。つまり、元のボットネットが作成したネットワークトラフィックの各バイトで、51,000バイトがgithubにヒットしました。攻撃のピーク時には、githubのネットワーク（またはそれらのDDOS軽減プロバイダーのネットワーク）でおよそ1.35Tbsのトラフィックが見られました。増幅係数を51000xとすると、これは、攻撃をトリガーした実際のボットネットが約26Mbsのトラフィックを押し出す可能性があることを意味します。同じボットネットを使用して、大量のアップロードを受け入れるエンドポイントに大量のデータを単純にアップロードした場合、増幅は行われず、Githhubは約26Mbsのgithubのトラフィックを消費するDDOS攻撃に見舞われたでしょう。彼らが気づいたとは思えません。
上記では、増幅ベースのDDOS攻撃に焦点を当てましたが、それらが明らかに唯一の選択肢ではありません。増幅部分はこれを成功させたものです（ネットワークトラフィックの観点から-実際にはgithubをダウンさせませんでした）が、そのような攻撃を実行するために悪用できる適切な増幅ベクトルを見つける必要もあります。それ以外の場合でも、サービスをDDOSする方法は他にもたくさんあります。CPU機能をオーバーランさせることができ（リクエストごとに大量のCPUまたはデータベースリソースを消費する、パフォーマンスの低いエンドポイントを繰り返しヒットすることを想像してください）、大量のデータをスローするだけでネットワークをオーバーランさせることができます。そのとき、サーバーがその接続プールなどを空にするまで、開いているTCP/IP接続を保持できます。
ファイルアップロードを攻撃することの短所
つまり、ファイルアップロードエンドポイントをオーバーランさせることは、システムをDOS化しようとする1つの方法ですが、おそらく最善ではありません。問題は、攻撃側と防御側が同じ領域に置かれることです。送信できる量のデータでのみターゲットを圧倒できます。オープンな接続プールの使用、高リソースエンドポイントへの攻撃、増幅攻撃などはすべて、リソースを攻撃する方法であり、リソースにさらなるレバレッジを与え、DDOSの人々にとってそれを容易にします。その結果、ファイルアップロードエンドポイントを圧倒することでDOSを確実に実行できますが、おそらくもっと効果的な方法があります。さらに、十分なネットワークトラフィックがある限り、ファイルアップロードエンドポイントにアクセスしても特に利点はないと思います。相手側のサーバーの有無に関係なく、データを送信できると思います。それを受け取るように感じます。ファイルアップロードエンドポイント（この分野の専門家ではありませんが）にアクセスした場合に見られる唯一の利点は、ファイルが実際にはサーバーのどこかに保存され、ハードドライブをいっぱいにすることができることです。大きな一時ファイル。これでも、おそらく最も効果的なDOS戦略ではありません。
これにより、最初に私が言ったことに戻ります。賢く、必要以上に大幅なアップロードを許可するようにサーバーを構成しないでください。ただし、セキュリティ上の懸念から、これよりも大きいアップロードが存在する可能性があります。
ファイルアップロードエンドポイントの保護
ファイルアップロードエンドポイントがDDOS攻撃に遭遇する場所の最初の選択肢ではないかもしれませんが、それはセキュリティの懸念が窓の外に出るべきであることを意味しません。コメントで述べたように、ユーザーアクセスの要求はそれほど役に立ちません：PHPは、アップロードを受け入れて一時的な場所に保存します。何もしないとすぐに削除されますアップロードでは、一時的にディスクに書き込まれます。
/tmpディレクトリのサイズを十分に大きくして（使用可能な帯域幅によって決定される）空き容量が不足しないようにするという他の提案により、ハードドライブがいっぱいにならないようにします（ただし、/tmpディレクトリは、特にサーバーが独自のパーティションにある場合は、必ずしもサーバーを強制終了するわけではありません。次に、チェーンの次の弱点を示します。ファイルアップロードエンドポイントを圧倒するためにすべての帯域幅が使用されている場合、マシンにハードスペースがあるかどうかに関係なく、サービスがダウンします。ドライブ（ネットワーク帯域幅がすべて使用されているため）。その時点では、ファイルのアップロードを介したDDOSはもはや不可能であるため、どれがあなたの質問にかなり答えます。ネットワーク帯域幅を完全に圧倒することを除いてファイルアップロードエンドポイントをDDOSできない場合、ファイルアップロードエンドポイントをDDOSしようとする人は誰もいません。ネットワーク接続を圧倒するために十分なトラフィックを狙うだけです。その時点で、ファイルのアップロードは安全だと思います。
ハードドライブの容量をどれだけ購入するのにどれくらいの費用がかかるかはわかりません。ホスティングプロバイダー（ハードドライブの容量は通常安いですが）と利用可能な帯域幅によって異なります。そうは言っても、そのようなシステムを保護するためのかなり単純なソリューションもあります。ファイルアップロードシステムを別のネットワーク上の別のサーバーに配置し（uploads.example.com）、すべてのシステムにDDOS保護（つまり、 cloudflare）。その後、ファイルアップロードエンドポイントに対するDDOSはそれを停止できますが、システムの残りの部分は陽気な方法で続行されます。もちろん、その場合、誰かがtryでファイルをアップロードすることを想像することはできません。彼らは、メインシステムに影響を与えるより魅力的な攻撃ベクトルを見つけようとするだけです。
大規模なアップロードを許可する場合、2つの大きなリスクがあります。
1つ目は、アップロードされたファイルがサーバーのディスク領域をいっぱいにする可能性があることです。クォータまたはマウントを巧みに使用しても、他のアップロードが失敗する可能性があります。厳密に構成されていないシステムでは、他のアプリケーションが失敗したり、オペレーティングシステムで障害が発生したりする可能性があります。特定の問題は、アップロードされたファイルがすべての状況で最終的に削除されることを保証することです。
2番目のリスク、および攻撃者にとってより魅力的なリスクは、大量のアップロードにより、ファイルを処理するコードでバッファオーバーフローが発生する可能性があることです。簡単に言えば、このようなオーバーフローは、ファイルが「正当」であることを確認するコードを破壊し、違法なアップロードが明らかに正当なダウンロードとして終わる可能性があります。ただし、バッファオーバーフローも権限昇格の潜在的な原因であり、攻撃者がWebサーバーをエスケープしてオペレーティングシステムで直接操作を実行できるようにします。
したがって、少なくとも次のことを考慮する必要があります。
- ファイルのアップロードでディスク容量がいっぱいになるとどうなりますか？
- ファイル処理（検証など）はファイル全体をメモリに読み込みますか、それとも小さなチャンクで処理しますか？サードパーティのパーサー（XMLなど）を使用する場合は特に注意してください
- あなたのコードは、ファイルの処理における予期しないエラーをどのように処理しますか？例えば検証で
VALIDまたはINVALIDが返されることが期待されますが、代わりにセグメンテーション違反が発生します。これにより、アップロードが有効なファイルとして解釈されますか？ - エラーが発生した場合でも、大きなファイルはディスク上のすべての場所から削除されますか？