ファイルアップロードの脆弱性を防ぐ方法
ファイル アップロード モジュールは、Web アプリケーションで最も弱いリンクの 1 つです。わずかなミスであっても、サーバーの制御がサイバー攻撃者の手に渡る可能性があります。このため、ソフトウェア開発者は、最も一般的な間違いと、発生する可能性のあるいくつかの攻撃方法を知る必要があります。
では、クライアント側の改ざんとは何ですか? サイトとユーザーを安全に保つために、これにどのように対処できますか?
クライアント側の改ざんとは?
クライアント側の改ざんは、Web アプリケーション攻撃全体の基本概念です。簡単に言えば、ユーザーに送信するデータを信頼できなくなったことを意味します。さらに、クライアント側の改ざんは、安全なアプリケーション開発の基盤の 1 つです。扱っているファイル アップロード モジュールを調べて、クライアント側の改ざんを検討する場合、信頼できないデータには次のものがあります。
- アップロードされたファイルの名前。
- アップロードされたファイルの Content-Type。
これら 2 つの項目は、ソフトウェア開発者としてホワイトリストに登録する機会がある場所です。アップロードされたファイルの名前データには、クライアント側で改ざんされたものを含めることができます。攻撃者がアップロードしている場合でも、アップロードされたファイルの Content-Type データを使用します。exe ファイルの場合、このファイルはシステムでイメージ/jpeg として表示される場合があります。
ファイル拡張子とホワイトリスト
ファイル アップロード モジュールの開発中に最初に行うことは、ファイル拡張子のホワイトリスト登録プロセスです。たとえば、ユーザーが「muo.jpeg」という名前のファイルをアップロードしたいとします。ユーザーがアップロードしようとしているこのファイル拡張子が であることを確認する必要があります。jpeg。このために、システムはアップロードされたファイルをチェックし、それが許可されたファイル拡張子の 1 つであるかどうかを確認する必要があります。これを行う方法を理解するには、次の単純な PHP コードを調べてください。
$file_parts = pathinfo($filename);
switch($file_parts['extension'])
{
case "jpg":
break;
case "bat": // Or exe, dll, so, etc.
break;
case "":
case NULL: // No file extension
break;
}
上記のようなコード ブロックを使用してこれを行うか、使用しているフレームワークによって提供されるクラスと関数を使用することができます。
コンテンツ タイプ情報とは
Content-Type 情報は、ファイルのアップロードごとに HTTP 要求で送信される情報です。インターネット ブラウザーはこの情報を検出し、送信された要求に追加します。攻撃者は、クライアント側の改ざんによって情報を変更し、サーバー側の検証をバイパスしようとする可能性があります。この段階で、開発者は Content-Type 情報を検証するための制御メカニズムが必要です。これだけでは十分ではありません。それでも、開発者が注意を払うべき重要な問題です。
ファイル拡張子を正しくチェックするメカニズムをエンコードし、拡張子が . jpeg拡張子。この予防メカニズムに加えて、万が一に備えて Content-Type 情報をチェックし、画像/jpeg 情報を含むファイルのみを受け入れることができます。これにより、サイバー攻撃に対する追加レベルの保護が実現します。
SWF Flash ファイルと攻撃手順
ファイル拡張子と Content-Type データは、Adobe Flash Player などのプラグインをサポートするインターネット ブラウザーにとっては何の意味もありません。そのプレーヤーのサポートは終了しましたが、Flash のセキュリティ リスクが残っているにもかかわらず、これらの関連ファイルを多くのシステムにインストールすることは可能です。関連する予防策を講じていないシステムでは、拡張子に関係なく、<object> タグを使用して Flash ファイルを呼び出すことができます。これにより、別の重大なセキュリティ問題が発生します。
行動を起こすために、開発者はサイバー犯罪者がたどる経路を知る必要があります。それがどのように起こるかは次のとおりです。
- 悪意のある攻撃者は、「image.jpeg」という名前の SWF (Adobe Flash ファイル形式) をターゲットの Web サイトにアップロードします。アップロード プロセス中に、ホワイトリストの検証で、攻撃者によってアップロードされたファイルに . jpeg拡張子。コンテンツ タイプの検証は、クライアント側の改ざんによってバイパスされます。攻撃者によってアップロードされたこのファイルが「www(dot)target-site(dot)com/images/images.jpeg」に送られると想像してください。
- 攻撃者が、attacker(dot)com という Web サイトを持っているとします。攻撃者は、application/x-shockwave-flash タイプが割り当てられた <object> タグを使用して、この Web サイトのターゲット サイトにアップロードされた image.jpeg ファイルを呼び出します。
- 無実のユーザーが attack(dot)com にログインします。そのサイトは www(dot)target-site(dot)com/images/image.jpeg にある SWF ファイルを呼び出し、SWF に与えられたコマンドを実行します。
- これにより、サイバー攻撃者は、通常のユーザーが気付かないうちに、target-site(dot)com アドレスに対する HTTP 要求アクションを作成できます。これらのリクエストにより、攻撃者は罪のないユーザーのセッションを使用し、CSRF チェックをバイパスします。
この攻撃シナリオをより明確に理解するには、次のコードが、攻撃者 (ドット) com によってユーザーに送信された HTML <object> コンテンツにあると考えてください。
style="height:1px;width:1px;" data="www.target-site.com/images/image.jpeg" type="application/x-shockwave-flash" allowscriptaccess="always" flashvars="c=read&u=somethings"
最善の解決策の 1 つは、別のサブドメインを介してファイル アップロードでアップロードされたファイルにアクセスすることです。前述のシナリオでは、同じドメインからではなく、「http(コロン)//file.target-site(ドット)com/images/image.jpeg」のように別のサブドメインから静的ファイルにアクセスできます。
もう 1 つの解決策は、アップロードするファイルへのアクセス要求を受け取ったときに、Content-Disposition: 添付情報を HTTP 応答に追加することです。
ファイル アップロードの脆弱性に注意する
ユーザーが Web サイトにファイルをアップロードすることは危険であるため、これは開発者が最も注意を払うべき問題の 1 つです。攻撃者がこのような脆弱性を発見すると、サイト内でシェルを開き、サーバー上の情報を簡単に悪用できます。ユーザーがアップロードしたすべてのファイルを制御し、ホワイトリスト方式を適用し、可能であればアップロードされたディレクトリの場所を非表示にすることが非常に重要です。
もちろん、ファイル モジュールをアップロードする際に推奨されるすべての予防措置を講じたとしても、サイトを保護するために必要な追加の手順は他にもたくさんあります。HTTP セキュリティ ヘッダーの使用は、実行できるそのような手順の 1 つです。
コメントを残す