トピック

	モジュールの内容
	目的
	適用対象
	モジュールの使用方法
	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「コード アクセス セキュリティの実践」の「リンク要求」を参照してください。次のレビュー項目は、コードのリンク確認要求の使用法についてレビューするうえで役立ちます。