コード レビュー

トピック

	モジュールの内容
	目的
	適用対象
	モジュールの使用方法
	FxCop
	テキスト検索の実行
	クロスサイト スクリプティング (XSS)
	SQL インジェクション
	バッファ オーバーフロー
	マネージ コード
	コード アクセス セキュリティ
	アンマネージ コード
	ASP.NET のページおよびコントロール
	Web サービス
	サービス対象のコンポーネント
	Remoting
	データ アクセス コード
	要約
	関連情報

モジュールの内容

セキュリティ コード レビューは、セキュリティ問題およびインシデントの原因となりうるセキュリティで保護されていないコーディングや脆弱性の識別に重点を置きます。コード レビューには時間がかかりますが、開発段階でセキュリティの短所修正に要する労力およびコストは、その後の製品展開や保守サイクルで要する労力およびコストに比べてはるかに少ないため、プロジェクト開発サイクルの定期的なイベントとして行う必要があります。

このモジュールは、Microsoft® .NET Framework を使用して構築された ASP.NET Web アプリケーション コードをレビューするうえで役立ちます。このモジュールは機能別に構成されています。また、コード レビュー プロセスの手法およびフレームワークを把握するうえで役立つ、包括的なレビュー項目リストを含むセクションも用意されています。

ページのトップへ

目的

このモジュールの目的は次のとおりです。

ページのトップへ

適用対象

このモジュールは、次の製品およびテクノロジに適用されます。

ページのトップへ

モジュールの使用方法

このモジュールを使用して、コード レビュー プロセスを作成、または既存のコード レビュー プロセスを拡張します。コード レビューが開発サイクルの一部として組み込まれていることを確認し、その効果は割り当てられたリソースと予算の量に応じたものであることを認識しておく必要があります。

レビューの目標は、コードを展開する前にできるだけ多くのセキュリティの脆弱性を識別することです。開発段階でセキュリティの短所修正に要する労力およびコストは、その後の製品展開サイクルで要する労力やコストに比べてはるかに少ないからです。

このモジュールから最大限の成果を得るための参考資料は、次のとおりです。

ページのトップへ

FxCop

レビュー プロセスを始めるにあたって、まずコンパイル済みのアセンブリを FxCop 分析ツールにかけることをお勧めします。このツールを使用してバイナリ アセンブリ (ソース コードではありません) を分析し、それらが MSDNで入手可能な「.NET Framework Design Guidelines」(英語) に準拠していることを確認することができます。強固な名前がアセンブリに付けられていることも、このツールで確認されます。強固な名前には不正操作を防ぐなどのセキュリティ上の利点があります。このツールにはあらかじめルールが定義されていますが、ルールをカスタマイズまたは拡張することもできます。

詳細については、以下のリソースを参照してください。

ページのトップへ

テキスト検索の実行

レビュー プロセスに使用するため、ファイル内の文字列を検索するテキスト検索ツールの使用法を知っていることが必要です。この種のツールを使用すると、脆弱なコードをすばやく検索することができます。このモジュールのレビュー項目では、特定の脆弱性の検索に最も適した文字列が多く示されています。

既存の検索ツールを使用していらっしゃると思いますが、Visual Studio® .NET の Find in Files、または Microsoft Windows オペレーティング システムのコマンド ライン ツールである Findstr も使用できます。

注: エクスプローラから Windows XP 検索ツールの [ファイルに含まれる単語または句] オプションを使用する場合、最新の Windows XP の Service Pack がインストールされていることを確認してください。インストールされていないと、検索に失敗する可能性があります。詳細については、マイクロソフト サポート技術情報の 309173「"ファイルに含まれる単語または句" 検索条件が機能しない」を参照してください。

ハード コード文字列の検索

ソース コードを 1 行ずつ詳細に分析する前にコード全体を高速検索し、ハード コードされたパスワード、アカウント名、データベースの接続文字列を特定します。key、secret、password、pwd、および connectionstring のような一般的な文字列パターンについて、コードの検索を行います。
たとえば、アプリケーションの Web ディレクトリで password という文字列を検索する場合は、次のように、コマンド プロンプトで Findstr ツールを使用します。

findstr /S /M /I /d:c:\projects\yourweb "password" *.*

Findstr では、以下のコマンド ライン パラメータを使用します。

Findstr の自動化

一般的な検索文字列を含むテキスト ファイルを作成することもできます。以下に示すように、Findstr を使用して作成されたテキスト ファイルから文字列を読み込み、検索することができます。.apsx ファイルを含むディレクトリから以下のコマンドを実行します。

findstr /N /G:SearchStrings.txt *.aspx

/N は一致する各行の前に行番号を出力します。/G は検索文字列を含むファイルを示します。この例では、SearchStrings.txt に含まれるすべての文字列の検索がASP.NET の全ページ (*.aspx) で行われます。

ILDASM

Findstr コマンドと ildasm.exe ユーティリティを組み合わせると、ハード コード文字列のバイナリ アセンブリを検索することもできます。以下のコマンドでは、ildasm.exe を使用して ldstr 中間言語ステートメントを検索し、文字列定数を識別しています。以下の出力結果が、ハード コードされたデータベース接続、およびよく知られている SA アカウントのパスワードを示していることに注目してください。

Ildasm.exe secureapp.dll /text | findstr ldstr
IL_000c:  ldstr      "RegisterUser"
IL_0027:  ldstr      "@userName"
IL_0046:  ldstr      "@passwordHash"
IL_0065:  ldstr      "@salt"
IL_008b:  ldstr      "Exception adding account. "
IL_000e:  ldstr      "LookupUser"
IL_0027:  ldstr      "@userName"
IL_007d:  ldstr      "SHA1"
IL_0097:  ldstr      "Exeception verifying password. "
IL_0009:  ldstr      "SHA1"
IL_003e:  ldstr      "Logon successful: User is authenticated"
IL_0050:  ldstr      "Invalid username or password"
IL_0001:  ldstr      "Server=AppServer;database=users; username='sa'   
password=password"

注: Ildasm.exe は、\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\bin フォルダに保存されています。サポートされるコマンド ラインの詳細については、「ildasm.exe /?」を実行してヘルプを参照してください。

ページのトップへ

クロスサイト スクリプティング (XSS)

入力パラメータがクライアントへ戻る出力 HTML ストリームに使用されている場合、コードのその箇所はどこもクロスサイト スクリプティング (XSS、または CSS とも呼ばれます) 攻撃に対して脆弱です。アプリケーションが XSS に対して脆弱かどうかは、コード レビュー前でも簡単にテストできます。ユーザー入力情報がブラウザに返されるページを検索してください。

XSS バグは、ユーザーが入力したデータを信頼しすぎるために生じる問題の一例です。たとえば、ユーザーが価格を入力することになっているアプリケーションに、攻撃者は価格だけでなく HTML と JavaScript を入力します。したがって、信頼関係にないソースから入力されたデータは、必ず検証することが必要です。コード レビューでは、データが検証済みかどうかを常に確認してください。HTTP ヘッダ、クエリ文字列、フォーム データなど ASP.NET アプリケーションのすべてのエントリ ポイントをリストし、すべての入力がどこかのポイントで必ず検証されるようにします。このアプローチでは潜在的に危険な入力はすべて把握されていることを前提としているため、不正な入力値かどうかはテストしないてください。データが ASP.NET アプリケーションで有効であることの確認に、正規表現を使用した方法が最も一般的に用いられます。

フォーム フィールドに XYZ などの文字列を入力して出力させるだけで簡単にテストできます。ブラウザに "XYZ" と表示される、または HTML のソースに "XYZ" が含まれる場合、その Web アプリケーションは XSS に対して脆弱です。より動的に確認する場合は、「<script>alert('hello');</script>」を挿入します。この手法は入力が出力生成にどのように利用されるかに依存しているため、すべての場合に有効な訳ではありません。

次の手順は、一般的な XSS に対する脆弱性を確認するうえで役立ちます。

入力を出力するコードの識別

ブラウザからページの出力ソースを表示させ、属性の中にコードが入っているかどうかを確認します。入っている場合、以下のコードを挿入して出力表示を再び確認します。

"onmouseover= alert('hello');"

開発者によく用いられる手法が、「<」および「>」の文字をフィルタすることです。レビューしているコードがこれらの文字をフィルタする場合、次に以下のコードを使用してテストします。

&{alert('hello');}

コードがこれらの文字をフィルタしない場合、以下のスクリプトを使用してコードをテストします。

<script>alert(document.cookie);</script>;

以下に示すように、タグを閉じてからでないと、このスクリプトが使用できない場合もあります。

"></a><script>alert(document.cookie);</script>

Write の検索

.aspx ソース コードおよびアプリケーションで開発したすべての関連アセンブリに含まれるコードで、文字列 .Write を検索します。この検索により、Response.Write、および以下に示すような Response オブジェクト変数を介して出力を生成する内部ルーチンを確認できます。

public void WriteOutput(Response respObj)
{
respObj.Write(Request.Form["someField"]);
}

以下に示すように、.aspx ソース コードを、同じように出力の書き込みに用いられる文字列 "<%=" で検索する必要があります。

<%=myVariable %>

表 21.1 に、Response.Write が入力フィールドとともに使用される一般的な状況を示します。

表 21.1: 考えられる入力ソース

 Response.Write(name.Text);
Response.Write(Request.Form["name"]); 

 Response.Write(Request.QueryString["name"]); 

Response.Write(  
Request.Cookies["name"].Values["name"]);

Response.Write(Session["name"]);
Response.Write(Application["name"]);

SqlDataReader reader = cmd.ExecuteReader();
Response.Write(reader.GetString(1));

潜在的に危険な HTML タグおよび属性の識別

以下は、完全には網羅していませんが、悪意のあるユーザーがスクリプト コードの挿入に使用する可能性がある一般的な HTML タグです。

src、lowsrc、style、href などの HTML 属性は、これらのタグと組み合わせて XSS を引き起こす際に使用される可能性があります。

たとえば、<img> タグの src 属性は、以下の例に示すように挿入のソースとなることがあります。

<IMG SRC="javascript:alert('hello');">
<IMG SRC="java&#010;script:alert('hello');">
						<IMG SRC="java&#X0A;script:alert('hello');">

<style> タグも、以下に示すように MIME タイプを変更させることにより、挿入のソースとなることがあります。

<style TYPE="text/javascript">
alert('hello');
</style>

危険なことが分かっている文字をフィルタして、コードが入力のサニタイジングを試みるかどうかを確認します。一般的に、悪意のあるユーザーは検証をバイパスできる別の表記を見つけるため、このアプローチに依存しないでください。このアプローチに依存する代わりに、セキュリティで保護された安全な既知の入力をコードが検証できるようにする必要があります。表 21.2 に、一般的な文字を表記するさまざまな方法が示されています。

表 21.2: 文字表記

 
"

"

 "

\u0022

'

'

'

\u0027

&

&#x26

&

\u0026

&#60

<

<

\u003c

&#62

>

>

\u003e

URL を処理するコードの識別

URL を処理するコードが脆弱な場合があります。次のような一般的な攻撃に対して脆弱かどうかについて、コードをレビューしてください。

http://www.YourWebServer.com/..%255%../winnt
http://www.YourWebServer.com/..%255%..//somedirectory

http://www.YourWebServer.com/..%c0f%af../winnt

http://www. WebServer.com/test.aspx?var=ここに非常に大きなデータを挿入する

出力がエンコードされていることの確認

入力のフォームおよび内容が正しいことを確認する代わりにはなりませんが、すべての入力タイプを含む HTML 出力が、HtmlEncode を使用してエンコードされていることを確認する必要があります。URL 文字列が UrlEncode を使用してエンコードされていないことも確認してください。入力データは、クエリ文字列、フォーム データ、Cookie、HTTP ヘッダ、および、特にデータベースが他のアプリケーションと共有されている場合はデータベースの読み込み値である可能性があります。データをエンコードすることにより、ブラウザが HTML を実行可能なスクリプトとして利用するのを防ぐことができます。

文字のエンコードが正しいかどうかの確認

文字エンコードが入力の表記方法を正しく制限する設定になっていることを確認して、正規化およびマルチバイトのエスケープ文字列を使用する攻撃者により、入力検証ルーチンが欺かれるのを防ぎます。

アプリケーションの Web config ファイルが、以下に示す <globalization> 要素で構成される requestEncoding および responseEncoding 属性を持つことを確認します。

<configuration>
<system.web>
						<globalization requestEncoding="ISO-8859-1" responseEncoding="ISO-8859-1" />
					</system.web>
</configuration>

文字エンコードは、<meta> タグまたは以下に示すように ResponseEncoding ページ レベル属性を使用して、ページ レベルで設定することもできます。

<% @ Page ResponseEncoding="ISO-8859-1" %>

詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」を参照してください。

validateRequest 属性の確認

.NET Framework version 1.1 を使用して構築された Web アプリケーションでは、埋め込みスクリプトのような潜在的に悪意のある入力を取り除くため、入力のフィルタ処理を行います。この処理に依存することはできませんが、重層的な防御のために使用してください。構成ファイルの <pages>要素で、validateRequest属性が true に設定されていることを確認します。この属性もページ レベルで設定することができます。.aspx ソース ファイルを validateRequest で検索して、どのページも false に設定されていないことを確認します。

HttpOnly Cookie オプションの確認

Internet Explorer 6 SP 1 は、クライアントのスクリプトが document.cookie プロパティから Cookie へアクセスすることを阻止する、新しい HttpOnly Cookie 属性をサポートしています。読み込もうとすると、空文字列が戻されます。ユーザーが現在のドメインで Web サイトを参照する場合は、Cookie はこれまでと同様にサーバーに送信されます。詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」の「クロスサイト スクリプティング」を参照してください。

<frame> セキュリティ属性の確認

Internet Explorer 6 以降では、<frame> および <iframe> 要素での新しい security 属性がサポートされています。この security 属性を使用して、ユーザーの Internet Explorer のセキュリティ ゾーンの制限付きサイト設定を各 frame または iframe に適用することができます。詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」の「クロスサイト スクリプティング」を参照してください。

innerText および innerHTML プロパティの使用の確認

信頼できない入力が含まれるページを作成した場合、innerHTML プロパティの代わりに innerText プロパティを使用していることを確認します。innerText プロパティを使用すると、コンテンツが安全に表示され、スクリプトが実行されないことが確実になります。

関連情報

XSS の詳細については、以下の資料を参照してください。

ページのトップへ

SQL インジェクション

入力パラメータを使用して SQL ステートメントを構築している箇所はすべて、SQL インジェクション攻撃に対し脆弱です。XSS バグと同様に、SQL インジェクション攻撃は、ユーザーからの入力を信頼してその入力の内容とフォームが正しいことを検証しないことが原因です。

以下の手順は、SQL インジェクション攻撃に対する脆弱性を確認するうえで役立ちます。

SqlDataAdapter myCommand = new SqlDataAdapter("spLogin", conn);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add(
"@userName", SqlDbType.VarChar,12);
parm.Value=txtUid.Text;

select status from Users where UserName=@userName

string sql = "select status from Users where UserName='" 
+ txtUserName.Text + "'";

ページのトップへ

バッファ オーバーフロー

バッファ オーバーフローのコード レビューでは、P/Invoke または COM Interop 層経由でアンマネージ コードを呼び出すコードを特にレビューしてください。配列がアクセスするすべての箇所で配列範囲が自動的に確認されるため、マネージ コード自体のバッファ オーバーフローに対する脆弱性はそれほど大きくありません。Win32 DLL または COM オブジェクトを呼び出したら直ちに、その API 呼び出しを慎重に検査する必要があります。

次の手順は、バッファ オーバーフローに対する脆弱性を確認するうえで役立ちます。

void SomeFunction( char *pszInput )
{
char szBuffer[10];
// 要注意、長さ確認が行われていません。入力はバッファへ直接コピーされます。
// 長さを確認するか、strncpy を使用する必要があります。
strcpy(szBuffer, pszInput);
  . . .
}

ページのトップへ

マネージ コード

ここのレビュー項目を使用して、マネージ ソース コード全体を分析してください。レビュー項目はアセンブリの種類に関係なく使用することができます。ここでは、一般的なマネージ コードの脆弱性を識別するうえで役立ちます。ここで説明した問題の詳細、および脆弱性を説明したコード サンプルについては、モジュール 7「セキュリティ保護されたアセンブリを構築する」を参照してください。

マネージ コードに明示的なコード アクセス セキュリティ機能を使用している場合は、関連するレビュー ポイントについて、このモジュールの「コード アクセス セキュリティ」を参照してください。次のレビュー項目を使用すると、マネージ コードの脆弱性を識別するうえで役立ちます。

クラス デザインのセキュリティ保護

アセンブリは、含まれるクラスや他の型と同程度のセキュリティでしか保護されません。次のレビュー項目は、クラス デザインのセキュリティをレビューするうえで役立ちます。

スレッド の作成

マルチスレッド コードは、見つけにくいタイミング関連のバグまたはセキュリティの脆弱性の原因となりうる競合を引き起こしやすいコードです。マルチスレッド コードの場所を確認するには、以下のコード フラグメントに示すようにソース コードを「Tread」で検索して、新しい Tread オブジェクトが作成された場所を識別してください。

Thread t = new Thread(new ThreadStart(someObject.SomeThreadStartMethod));

次のレビュー項目を使用すると、スレッドの脆弱性を識別するうえで役立ちます。

シリアル化の使用

シリアル化をサポートするクラスは SerializableAttribute に指定されるか、あるいは Iserializable から派生します。シリアル化をサポートするクラスは、文字列 Serializable のテキスト検索によって見つけることができます。次に、以下の問題についてコードをレビューします。

リフレクションの使用

リフレクションを使用するコードを確認するには、リフレクション型を含む名前空間の "System.Reflection" で検索を行います。リフレクションを使用する場合、次のレビュー項目を確認すると、潜在的な脆弱性を識別するうえで役立ちます。

例外の処理

セキュリティで保護された例外処理は、堅牢なコードに必要です。例外の詳細なログを確実に記録して問題の診断に役立て、内部システムの詳細がクライアントに公開されるのを確実に防ぎます。次のレビュー項目を確認すると、例外処理の脆弱性を識別するうえで役立ちます。

暗号化の使用

使用する場合は、コードが自身の暗号化ルーチンを実装していないことを確認します。暗号化ルーチンを実装する代わりに、名前空間 System.Security.Cryptography、あるいはデータ保護 API (DPAPI) などの Win32 暗号化を使用する必要があります。次のレビュー項目を確認すると、潜在的な暗号化関連の脆弱性を識別するうえで役立ちます。

機密情報の格納

アセンブリが機密情報を格納する場合、デザインをレビューして機密情報の格納が絶対必要であることを確認します。機密情報を格納する必要がある場合、次のレビュー項目を確認してできるだけセキュリティで保護してください。

委任の使用

どのコードも、メソッドと委任を関連付けることができます。委任には、低い信頼レベルで実行される潜在的に悪意のあるコードも含まれます。

ページのトップへ

コード アクセス セキュリティ

すべてのマネージ コードに対し、コード アクセス セキュリティ許可が要求されます。問題の多くは、コードが部分的に信頼された環境で使用され、コードまたは呼び出しコードがコード アクセス セキュリティ ポリシーから十分に信頼されない場合にのみ、発生します。

ここで説明した問題の詳細については、モジュール 8「コード アクセス セキュリティの実践」を参照してください。

以下のレビュー ポイントを使用して、適切で安全なコード アクセス セキュリティが使用されていることを確認してください。

部分的に信頼された呼び出し元のサポート

コードが部分的に信頼された呼び出し元をサポートする場合、攻撃される危険性が大きくなります。その結果、広範囲に渡る徹底したコード レビューを行うことが特に重要になります。Web アプリケーションの <trust> レベルが、部分的に信頼されたレベルで実行される設定になっているかどうかを確認してください。この設定になっている場合、そのアプリケーション用に開発されるアセンブリは、部分的に信頼された呼び出し元をサポートする必要があります。

次のレビュー項目を確認すると、潜在的に脆弱な領域を識別するうえで役立ちます。

パブリックな型およびメンバへのアクセスの制限

コード アクセス セキュリティ ID 要求を使用して、パブリックな型およびメンバへのアクセスを制限することができます。これは、アセンブリが攻撃を受ける危険性を減らすのに役立ちます。

宣言型セキュリティ属性の使用

宣言型セキュリティ属性は Permview.exe. などのツールを使用して表示させることができます。これは、アセンブリの利用者および管理者がコードのセキュリティ要件を理解するうえで非常に役立ちます。

Assert の呼び出し

Assert 呼び出しについてコードを検索してください。この検索により Debug.Assert のインスタンスが見つかることがあります。コードがどこで CodeAccessPermission オブジェクトに Assert を呼び出すかを探します。コード アクセス許可をアサートする場合は、危険性のあるプラクティスであるスタック ウォークを要求するコード アクセス セキュリティ許可を回避してください。悪意のある呼び出し元が、セキュリティで保護されたリソースまたは権限による操作にアクセスするアサートを行えないようにするための、コードにおける処理方法を確認してください。次のレビュー項目を確認してください。

必要に応じた、アクセス許可の要求の使用

コードは常に .NET Framework クラス ライブラリからのアクセス許可の要求チェックを受けますが、コードが明示的なアクセス許可の要求を使用する場合、適切に要求されていることを確認してください。コードを文字列. Demand で検索して、宣言型または強制型のアクセス許可の要求のどちらであるかを識別し、次に次のレビュー項目を確認します。

リンク確認要求の使用

一般的な確認要求とは異なり、リンク確認要求はコードの直接の呼び出し元だけをチェックします。完全なスタック ウォークは実行されないため、リンク確認要求を使用するコードはおとり攻撃にさらされます。おとり攻撃の詳細については、モジュール 8「コード アクセス セキュリティの実践」を参照してください。

コードを文字列 .LinkDemand で検索し、リンク確認要求が使用されている箇所を識別してください。これらは宣言的にのみ使用されます。一例を以下のコード フラグメントに示します。

[StrongNameIdentityPermission(SecurityAction.LinkDemand,  
PublicKey="00240000048...97e85d098615")]
public static void SomeOperation() {}

ここで説明した問題の詳細については、モジュール 8「コード アクセス セキュリティの実践」の「リンク要求」を参照してください。次のレビュー項目は、コードのリンク確認要求の使用法についてレビューするうえで役立ちます。

潜在的に危険なアクセス許可の使用

以下のアクセス許可型が信頼できるコードにのみ付与されていることを確認してください。これらのほとんどは独自のアクセス許可型を持たず、一般的な SecurityPermission 型を使用します。これらの型を使用するコードを綿密に検査して、その危険性が最小限に抑えられていることを確認する必要があります。また、これらのアクセス許可をどうしても使用しなくてはならない理由も必要です。

表 21.3: 危険なアクセス許可

/unsafe オプションを指定したコンパイル

Visual Studio .NET を使用して、プロジェクトのプロパティの Allow Unsafe Code Blocks が true に設定されていることを確認してください。これにより /unsafe コンパイラ フラッグが立てられ、コードが安全でないブロックを含むことをコンパイラに通知し、最小アクセス許可 SkipVerification をアセンブリに付与するよう要求します。

/unsafe でコンパイルする場合、そうしなくてはならない理由についてレビューしてください。合理的な理由がある場合は、潜在的な脆弱性がないかソース コードを特に注意してレビューしてください。

ページのトップへ

アンマネージ コード

Win32 DLL や COM オブジェクトなどのアンマネージ コードを呼び出すコードはセキュリティ リスクが高いため、特に注意してください。アンマネージ コードは安全であることが検証できる型ではなく、潜在的にバッファ オーバーフローを招くものです。アンマネージ コードからのリソースへのアクセスにはコード アクセス セキュリティ チェックが行われません。これはマネージ ラッパー クラスの責任範囲になります。

アンマネージ コードは、通常は部分的に信頼された呼び出し元に直接公開しないでください。ここで説明した問題の詳細については、モジュール 7「セキュリティ保護されたアセンブリを構築する」およびモジュール 8「コード アクセス セキュリティの実践」を参照してください。

次のレビュー項目を使用して、アンマネージ コードの使用について検証してください。

// カスタム暗号化許可を要求します。
(new EncryptionPermission(
EncryptionPermissionFlag.Encrypt, storeFlag)).Demand();
// アンマネージ コードのアクセス許可をアサートします。
(new SecurityPermission(SecurityPermissionFlag.UnmanagedCode)).Assert();
// ここで P/Invoke を使用してアンマネージ DPAPI 機能を呼び出します。

ページのトップへ

ASP.NET のページおよびコントロール

このセクションのレビュー項目を使用して、ASP.NET のページおよびコントロールをレビューしてください。ここで説明した問題の詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」を参照してください。

エラー メッセージの詳細表示の無効化

アプリケーションの範囲を超えた例外が適用されると、ASP.NET が詳細な情報を呼び出し元に返す場合があります。この情報には、攻撃者にとって有用な完全なスタック トレースなどの情報も含まれます。<customErrors> 要素の、モード属性が On または RemoteOnly に設定されていることを確認してください。

<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />

トレースの無効化

トレース情報も攻撃者にとって非常に有用です。<customErrors> 要素で、トレースが無効になっていることを確認してください。

<trace enabled="false" localOnly="true" pageOutput="false"  
       requestLimit="10" traceMode="SortByTime"/>

フォーム フィールド入力の検証

ポストされたフォーム フィールド経由で、攻撃者が悪意のある入力を Web ページおよびコントロールに渡すことがあります。隠しフォーム フィールドを含むすべてのフォーム フィールドが検証されていることを確認します。フォーム フィールドの型、範囲、フォーマット、および長さを検証してください。次のレビュー項目を使用して、ASP.NET の入力処理をレビューしてください。

try
{
  string mappedPath = Request.MapPath( inputPath.Text,  
                                       Request.ApplicationPath, false);
}
catch (HttpException)
{
// クロス アプリケーション マッピングを実行しようとしました。
}

XSS 攻撃に対する脆弱性

XSS に対する脆弱性について、必ず Web ページをレビューしてください。詳細については、このモジュールの「クロスサイト スクリプティング」を参照してください。

クエリ文字列と Cookie の入力の検証

コードが、URL クエリ文字列から渡された入力フィールドおよび Cookie から抽出された入力フィールドを検証することを確認してください。以下のテキスト文字列を検索して、脆弱なコードを見つけます。

入力値の型、範囲、フォーマット、および長さが、型付けされたオブジェクトおよび正規表現を使用して、フォーム フィールドに対してと同様に検証されることを確認してください (前述した「フォーム フィールド入力の検証」を参照してください)。無効なコンストラクトを打ち消してしまうと XSS バグにつながるおそれがあるため、ユーザー入力から派生するすべての HTML や URL エンコード出力についても考慮してください。

ビュー ステートのセキュリティ保護

アプリケーションがビュー ステートを使用する場合、不正操作は防止されているかどうかを確認します。次のレビュー項目を確認してください。

<pages enableViewState="true" enableViewStateMac="true" />

Global.asax のイベント ハンドラのセキュリティ保護

Global.asax ファイルには、ASP.NET および HTTP モジュールで生成されるアプリケーション レベルのイベント用のイベント ハンドラ コードが含まれています。以下のイベント ハンドラをレビューして、コードに脆弱な箇所がないことを確認してください。

適切な承認の実行

次のレビュー項目を確認して、承認方法を確認してください。

ページのトップへ

Web サービス

ASP.NET Web サービスは、ASP.NET Web アプリケーションと多くの機能を共有しています。最初に、「ASP.NET のページおよびコントロール」セクションのレビュー項目を使用して Web サービスをレビューし、以下の Web サービス固有のレビュー項目を確認してください。ここで説明した問題の詳細については、モジュール 12「セキュリティ保護された Web サービスを構築する」を参照してください。

制限付きの操作またはデータの公開

Web サービスが制限付きの操作またはデータを公開する場合、そのサービスが呼び出し元の認証を行うことを確認してください。NTLM、Kerberos、基本認証、クライアントの X.509 認証などのプラットフォーム認証のメカニズムを利用するか、または SOAP ヘッダに認証トークンを渡すことができます。

認証トークンを渡す場合、WSE (Web Services Enhancements) を使用して、新しい WS-Security 仕様に準拠した方法で SOAP ヘッダを使用することができます。

呼び出し元の承認方法

.NET Framework (URL 承認、ファイル承認、.NET ロールなど)、あるいはファイル ACL などのプラットフォーム オプションによって提供される適切な承認方式を選択します。

権限による操作の制限

コード アクセス セキュリティ ポリシーの信頼レベルにより、Web サービスがアクセスできるリソースの型が決定されます。Machine.config または Web.config. の <customErrors> 要素設定を確認してください。

カスタム認証の使用

自分自身の認証方式を作成する代わりに、WSE (Web Service Enhancements) によって提供される機能を使用してください。

すべての入力の検証

外部に公開された Web メソッドが信頼範囲外のソースから入力を受け取った場合、その入力を使用または下流のコンポーネントやデータベースに渡す前に、入力パラメータをすべて検証することを確認してください。

SOAP ヘッダの検証

アプリケーションでカスタム SOAP ヘッダを使用する場合、その情報が不正操作またはリプレイされたものではないことを確認します。不正操作されていないことを保障するため、ヘッダ情報をデジタル署名してください。WSE を使用すると、標準的な方法での Web サービス メッセージのサインに役立ちます。

SoapException および SoapHeaderException オブジェクトがエラーを正しく処理し、クライアントに必要最小限の情報を提供するために使用されていることを確認してください。トラブルシューティングで使用するため、例外が適切にログ出力されていることを確認してください。

ページのトップへ

サービス対象のコンポーネント

ここでは、Enterprise Services アプリケーション内で使用されるサービス対象のコンポーネントをレビューする際に、考慮する必要がある重要レビュー ポイントを説明します。ここで説明した問題の詳細については、モジュール 11「セキュリティ保護されたサービス コンポーネントを構築する」を参照してください。

アセンブリ レベルのメタデータの使用

アセンブリ レベルのメタデータを使用して Enterprise Services のセキュリティ設定を定義していることを確認してください。assemblyinfo.cs ファイルおよび属性を使用して、認証および承認の設定を定義します。これは、管理する際に設定が正しく確立されていることを確実にするうえで役立ちます。管理者はこれらの設定をオーバーライドできますが、オーバーライドを通じて、管理者はどのような設定が期待されているかを明確に把握することができます。

匿名アクセスの防御

コードが、ApplicationAccessControl 属性を使用して認証レベルを指定していることを確認してください。文字列 AuthenticationOption で検索を行い、関連する属性を確認してください。呼び出しレベル以上の認証が使用され、コンポーネントへのそれぞれの呼び出しの認証を保障していることを確認してください。

[assembly:ApplicationAccessControl(
Authentication = AuthenticationOption.Call)]

制限付きの偽装レベルの使用

サービス対象のコンポーネントに対して定義した偽装レベルが、通信対象のすべてのリモート サーバーの偽装レベルを決定します。文字列 ImpersonationLevel を検索して、コードがそのレベルを設定していることを確認してください。

[assembly:ApplicationAccessControl(
ImpersonationLevel=ImpersonationLevelOption.Identify)]

リモート サーバーに必要な、最も厳しい制限付きレベルの設定したことを確認してください。たとえば、サーバーが認証目的でユーザーを識別する必要があるが偽装する必要はない場合、上に示した識別レベルを使用してください。Windows 2000 ではセキュリティ コンテキストがコンピュータからコンピュータへと渡される回数に制限がないため、委任レベルの偽装は注意して適用してください。Windows Server™ 2003 は制限付き委任を導入しています。

注: Windows Server 2003 および Windows 2000 Service Pack 4 以降では、偽装権限はすべてのユーザーに与えられていません。

コンポーネントがサーバー アプリケーション内にあり、Enterprise Services に登録されている場合、上記のアセンブリ レベル属性がコンポーネントの初期設定を制御します。

コンポーネントがライブラリ アプリケーション内にある場合、クライアントの処理が偽装レベルを決定します。クライアントが ASP.NET Web アプリケーションの場合、Machine.config ファイルの <processModel> 要素で comImpersonationLevel 設定を確認してください。

ロール ベースのセキュリティの使用

コードがロール ベースのセキュリティを正しく使用し、権限のないアクセスを防いでいることを、次のレビュー項目を確認して確認してください。

[assembly:ApplicationAccessControl(true)]

[assembly:ApplicationAccessControl(AccessChecksLevel= 
AccessChecksLevelOption.ApplicationComponent)]

[ComponentAccessControl(true)]
public class YourServicedComponent :ServicedComponent
{
}

オブジェクト コンストラクタ文字列の使用

文字列 ConstructionEnabled でコードを検索して、オブジェクト コンストラクタ文字列を使用するクラスを確認してください。

[ConstructionEnabled(Default="")]
public class YourServicedComponent :ServicedComponent, ISomeInterface

オブジェクト コンストラクタ文字列を使用している場合、次のレビュー項目を確認してください。

中間層の監査

分散アプリケーションの層についても監査を行う必要があります。サービス コンポーネントが操作とトランザクションをログで記録していることを確認してください。呼び出し元のオリジナル ID は SecurityCallContext オブジェクトを通じて入手できます。これは、アプリケーションのセキュリティ レベルが、以下の属性を使用してプロセス レベルおよびコンポーネント レベルのチェック用に構成されている場合にのみ、入手可能です。

[assembly:ApplicationAccessControl(AccessChecksLevel= 
AccessChecksLevelOption.ApplicationComponent)]

ページのトップへ

Remoting

ここでは、.NET Remoting を使用するコードをレビューする際に考慮する必要がある重要レビュー ポイントを説明します。ここで説明した問題の詳細については、モジュール 13「セキュリティ保護されたリモート コンポーネントを構築する」を参照してください。

オブジェクトのパラメータとしての引き渡し

TcpChannel を使用していてコンポーネント API がカスタム オブジェクト パラメータを受け取る場合、またはカスタム オブジェクトがコンテキストの呼び出しによって渡される場合、コードには 2 つのセキュリティ脆弱性が存在します。

カスタム オブジェクトがリモート コンポーネントにオブジェクト参照、またはデータ値で渡されることを防ぐために、サーバー側のフォーマッタ チャネル シンクの TypeFilterLevel プロパティを TypeFilterLevel.Low に設定してください。

呼び出しコンテキストで渡されるオブジェクトを見つけるには、文字列 IlogicalThreadAffinative で検索してください。このインターフェイスを実装しているオブジェクトだけが、呼び出しコンテキストに渡されることができます。

カスタム認証とプリンシパル オブジェクトの使用

カスタム認証を使用する場合、クライアントから渡されるプリンシパル オブジェクトに依存していますか。悪意のあるコードが、権限を格上げする拡張ロールを含むプリンシパル オブジェクトを作成する可能性があるため、これは潜在的に危険です。このアプローチを使用する場合、コンポーネントに接続できるクライアント コンピュータを制限する IPSec ポリシーなどの帯域外メカニズムと共に使用しているだけであることを確認してください。

プロキシの資格情報の設定方法

リモート プロキシでクライアント コードがどのように資格情報を設定しているかをレビューしてください。明示的な資格情報が使用されている場合の保管場所を確認します。これらの資格情報は、制限付きレジストリ キーなどのセキュリティで保護された場所に暗号化した上で格納する必要があります。プレーンテキストのままハードコードしないでください。クライアント コードがクライアント プロセス トークンおよび既定の資格情報を使用することが理想的です。

ページのトップへ

データ アクセス コード

ここでは、データ アクセス コードのレビューの際に考慮する必要がある重要レビュー ポイントを説明します。ここで説明した問題の詳細については、モジュール 14「セキュリティ保護されたデータ アクセスを構築する」を参照してください。

SQL インジェクションの防御

入力を検証し、最小限の権限によるアカウントを使用してデータベースに接続し、またパラメータ化ストアド プロシージャまたはパラメータ化 SQL コマンドを使用することによって、SQL インジェクションを防いでいることを確認してください。詳細については、このモジュールの「SQL インジェクション」を参照してください。

Windows 認証の使用

Windows 認証を使用すると、ネットワーク経由でデータベース サーバーに資格情報を渡す必要がなくなり、接続文字列にユーザー名やパスワードが含まれなくなります。Windows 認証接続文字列では、以下の例に示すように Trusted_Connection='Yes' または Integrated Security='SSPI' のいずれかが使用されます。

"server='YourServer'; database='YourDatabase' Trusted_Connection='Yes'"
"server='YourServer'; database='YourDatabase' Integrated Security='SSPI'"

セキュリティで保護されたデータベース接続文字列の使用

コードが正しいこと、およびデータベース接続文字列をセキュリティで保護して使用していることをレビューしてください。ユーザー名やパスワードが含まれる場合は特に、これらの接続文字列をハードコードしたり、設定ファイルにプレーンテキストで格納しないでください。

ADO .NET 接続オブジェクトの場合は文字列 Connection で検索して、ConnectionString プロパティがどのように設定されているかをレビューしてください。

認証されていないコードの制限方法

データ アクセス クラス ライブラリに書き込む場合、承認されていないコードのライブラリへのアクセスによるデータベースへのアクセスを防御方法を確認します。1 つのアプローチは、StrongNameIdentityPermission 要求を使用して、呼び出しコードを特定の強固な名前を持つ秘密キーで署名されたコードにのみ制限することです。

データベースの機密情報のセキュリティによる保護方法

クレジット カード番号などの機密データをデータベースに格納する場合の、データのセキュリティでの保護方法を確認します。3DES などの強固な対称暗号化を使用して暗号化されていることを確認する必要があります。

3DES を使用して暗号化する場合、3DES 暗号化キーのセキュリティでの保護方法を確認します。DPAPI を使用して3DES 暗号化キーを暗号化し、その暗号化キーをレジストリなどの制限付きの場所に格納する必要があります。

ADO .NET 例外の処理

すべてのデータ アクセス コードが try/catch ブロック内にあり、使用する ADO .NET データ プロバイダに応じて、SqlExceptions、OleDbExceptions、または OdbcExceptions をコードが処理することを確認してください。

データベース接続の切断

例外が発生するなどデータベース接続が開いたままの場合にも、コードが脆弱でないことを確認してください。コードが finally ブロック内で接続を閉じるか、あるいは接続オブジェクトが以下に示すように using ステートメントを使用して C# 内部に構築されていることを確認してください。これは、接続が閉じていることを自動的に保障します。

using ((SqlConnection conn = new SqlConnection(connString)))
{
conn.Open();
//接続は次の場合に閉じます。例外が発生、またはコントロール フローが
// using ステートメントのスコープを normally のままにする場合。
}

ページのトップへ

要約

セキュリティ コード レビューは、セキュリティの脆弱性につながるコーディングの短所の識別に重点を置いていることを除くと、通常のコード レビューや検査に似ています。付加価値として、セキュリティの短所が除かれたコードの多くは、より堅牢になります。

このモジュールでは、XSS、SQL インジェクション、バッファ オーバーフローなどの最重要セキュリティ問題に関するマネージ コードのレビュー方法について説明しました。セキュリティの脆弱性や攻撃が成功することにつながる、その他の細かい短所の識別方法についても説明されています。

セキュリティ コード レビューは万能薬ではありません。しかし、非常に効果的であり、開発ライフ サイクル内の定期的なマイルストーンとして位置付けされる必要があります。

ページのトップへ

関連情報

詳細については、MSDN の「.NET Framework のための安全なコーディング ガイドライン」を参照してください。

ページのトップへ