データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、整数に依存するため、SQL Injection の脆弱性に対して脆弱ではないステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

DATA: id TYPE i.
...
id = request->get_form_field( 'invoiceID' ).

CONCATENATE `INVOICEID = '` id `'` INTO cl_where.
SELECT *
    FROM invoices
    INTO CORRESPONDING FIELDS OF TABLE itab_invoices
    WHERE (cl_where).
ENDSELECT.
...

問題は、開発者が ID に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var id:int = int(Number(params["invoiceID"]));
        var query:String = "SELECT * FROM invoices WHERE id = :id";

        stmt.sqlConnection = conn;
        stmt.text = query;
        stmt.parameters[":id"] = id;
        stmt.execute();
        ...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SOQL/SOSL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコード例では、inputID 値は事前定義されたリストから取得されていて、バインド変数は SOQL/SOSL Injection を防止するのに役立ちます。

...
result = [SELECT Name, Phone FROM Contact WHERE (IsDeleted = false AND Id=:inputID)];
...

上記の例で問題となるのは、事前定義された ID リストを使用するだけでは、ユーザーによる inputID の値の変更を防止するには不十分なことです。攻撃者がインターフェイスをバイパスし、別の値を使用してリクエストを送信できる場合は、他の連絡先情報にアクセスできてしまいます。この例のコードの場合、リクエストされた連絡先へのアクセス権限がユーザーにあるか確認しないため、ユーザーがこの連絡先を表示する権限がない場合でも、すべての連絡先が表示されます。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. LINQ クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、指定された識別子と一致する領収書を検索する LINQ クエリを実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...

int16 id = System.Convert.ToInt16(invoiceID.Text);
var invoice = OrderSystem.getInvoices()
	.Where(new Invoice { invoiceID = id });
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
CMyRecordset rs(&dbms);
rs.PrepareSQL("SELECT * FROM invoices WHERE id = ?");
rs.SetParam_int(0,atoi(r.Lookup("invoiceID").c_str()));
rs.SafeExecuteSQL();
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1:次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
ACCEPT ID.
EXEC SQL
    DECLARE C1 CURSOR FOR
    SELECT INVNO, INVDATE, INVTOTAL
    FROM INVOICES
    WHERE INVOICEID = :ID
END-EXEC.
...

問題は、開発者が ID に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入力された場合。


2. データベース名の値を指定するのにデータが使用される場合。

データベースの Access Control エラーが発生するのは次の場合です。

1.信頼できないソースからデータがプログラムに入力された場合。


2.SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
id := request.FormValue("invoiceID")
query := "SELECT * FROM invoices WHERE id = ?";
rows, err := db.Query(query, id)
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
id = Integer.decode(request.getParameter("invoiceID"));
String query = "SELECT * FROM invoices WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
ResultSet results = stmt.execute();
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

一部には、モバイルの世界ではデータベースの Access Control エラーのような古典的な Web アプリケーションの脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 2: 次のコードでは、Android プラットフォームにExample 1 を応用しています。

...
        String id = this.getIntent().getExtras().getString("invoiceID");
        String query = "SELECT * FROM invoices WHERE id = ?";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, new Object[]{id});
...

最新の Web フレームワークの多くが、ユーザー入力を検証するためのメカニズム (Struts および Struts 2 を含む) を提供しています。検証されていない入力ソースの問題を正確に反映させるために、Fortify セキュア コーディング ルールパックは、フレームワーク検証メカニズムが使用されている場合には、その証拠を示し、悪用の可能性を低く見積もり、Fortify Static Code Analyzer により報告される問題の優先度を動的に変更します。この機能は、状況依存ランキングと呼ばれます。Fortify ユーザーがさらに監査プロセスを効果的に進めることができるように、Fortify Software Security Research グループでは、入力ソースに適用される検証メカニズムを基準としたフォルダに問題をグループ化する Data Validation (データ検証) プロジェクト テンプレートのフォルダを用意しています。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

	...
	var id = document.form.invoiceID.value;
	var query = "SELECT * FROM invoices WHERE id = ?";
	db.transaction(function (tx) {
		tx.executeSql(query,[id]);
		}
	)
	...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...

        NSManagedObjectContext *context = [appDelegate managedObjectContext];
        NSEntityDescription *entityDesc = [NSEntityDescription entityForName:@"Invoices" inManagedObjectContext:context];
        NSFetchRequest *request = [[NSFetchRequest alloc] init];
        [request setEntity:entityDesc];
        NSPredicate *pred = [NSPredicate predicateWithFormat:@"(id = %@)", invoiceId.text];
        [request setPredicate:pred];

        NSManagedObject *matches = nil;
        NSError *error;
        NSArray *objects = [context executeFetchRequest:request error:&error];

        if ([objects count] == 0) {
                 status.text = @"No records found.";
        } else {
                matches = [objects objectAtIndex:0];
                invoiceReferenceNumber.text = [matches valueForKey:@"invRefNum"];
                orderNumber.text = [matches valueForKey:@"orderNumber"];
                status.text = [NSString stringWithFormat:@"%d records found", [objects count]];
        }
        [request release];
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

        ...
	$id = $_POST['id'];
	$query = "SELECT * FROM invoices WHERE id = ?";
	$stmt = $mysqli->prepare($query);
	$stmt->bind_param('ss',$id);
	$stmt->execute();
        ...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

最新の Web フレームワークの多くが、ユーザー入力を検証するためのメカニズム (Struts および Struts 2 を含む) を提供しています。検証されていない入力ソースの問題を正確に反映させるために、Fortify セキュア コーディング ルールパックは、フレームワーク検証メカニズムが使用されている場合には、その証拠を示し、悪用の可能性を低く見積もり、Fortify Static Code Analyzer により報告される問題の優先度を動的に変更します。この機能は、状況依存ランキングと呼ばれます。Fortify ユーザーがさらに監査プロセスを効果的に進めることができるように、Fortify Software Security Research グループでは、入力ソースに適用される検証メカニズムを基準としたフォルダに問題をグループ化する Data Validation (データ検証) プロジェクト テンプレートのフォルダを用意しています。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

procedure get_item (
itm_cv IN OUT ItmCurTyp,
id in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'invoiceID = :invid' ||
     	using id;
end get_item;

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
id = request.POST['id']
c = db.cursor()
stmt = c.execute("SELECT * FROM invoices WHERE id = %s", (id,))
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
id = req['invoiceID'].respond_to(:to_int)
query = "SELECT * FROM invoices WHERE id=?"
stmt = conn.prepare(query)
stmt.execute(id)
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

...
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Invoices", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
let pred : NSPredicate = NSPredicate(format:"(id = %@)", invoiceId.text)
fetchRequest.setPredicate = pred
do {
    let results = try managedContext.executeFetchRequest(fetchRequest)
    let result : NSManagedObject = results.first!
    invoiceReferenceNumber.text = result.valueForKey("invRefNum")
    orderNumber.text = result.valueForKey("orderNumber")
    status.text = "\(results.count) records found"
} catch let error as NSError {
    print("Error \(error)")
}
...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. SQL クエリで主キーの値を特定するためにデータが使用されている場合。
例 1: 次のコードは、メタ文字をエスケープして SQL Injection の脆弱性を阻止するパラメーター化されたステートメントを使用して、指定された識別子と一致する領収書を検索する SQL クエリを作成し、実行します [1]。識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

	...
	id = Request.Form("invoiceID")
	strSQL = "SELECT * FROM invoices WHERE id = ?"
	objADOCommand.CommandText = strSQL
	objADOCommand.CommandType = adCmdText
	set objADOParameter = objADOCommand.CreateParameter("id" , adString, adParamInput, 0, 0)
	objADOCommand.Parameters("id") = id
	...

問題は、開発者が id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。

2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: システムユーティリティの次のコードでは、レジストリキー APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。

...
CALL FUNCTION 'REGISTRY_GET'
  EXPORTING
     KEY   = 'APPHOME'
  IMPORTING
     VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...

Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにレジストリエントリ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを高い権限で実行できます。このプログラムはレジストリから読み取った値の検証を行わないので、レジストリキー APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

例 2: 次のコードは、ユーザーが rman ユーティリティに対するバッチファイルラッパーを使用して Oracle データベースのバックアップを開始し、その後 cleanup.bat スクリプトを実行して一部のテンポラリ ファイルを削除できるインターフェイスを持つ Web アプリケーションのものです。スクリプト rmanDB.bat は、実行するバックアップのタイプを指定するコマンドライン パラメーターを 1 つ受け取ります。データベースへのアクセスが制限されているため、アプリケーションは権限を持つユーザーとしてバックアップを実行します。

...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
  EXPORTING
    commandname                   = cmd_exe
    long_params                   = cmd_string
  EXCEPTIONS
    no_permission                 = 1
    command_not_found             = 2
    parameters_too_long           = 3
    security_risk                 = 4
    OTHERS                        = 5.
...

ここでの問題はプログラムがユーザーから読み取る backuptypeパラメーターを検証しないことです。通常、関数モジュール SXPG_COMMAND_EXECUTE_LONG は複数のコマンドを実行しませんが、この例のプログラムは最初に cmd.exe シェルを実行して、CALL 'SYSTEM' を 1 回コールするだけで複数のコマンドを実行しています。呼び出されたシェルは、2 つのアンパサンドで区切られた複数のコマンドを実行できます。攻撃者が "&& del c:\\dbms\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。

例 3: 次のコードは、ユーザーがシステムのパスワードを更新できるインターフェイスを提供する Web アプリケーションのものです。特定のネットワーク環境でパスワードを更新する処理には、/var/yp ディレクトリでの make コマンドの実行が含まれます。

...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...

ここでの問題は、プログラムが make のための絶対パスを指定しておらず、CALL 'SYSTEM' のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。

2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: 次のコードでは、設定ファイルの入力を使用してインストール先のディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。

        ...
        var fs:FileStream = new FileStream();
        fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
        home = String(fs.readObject(home));
        var cmd:String = home + INITCMD;
        fscommand("exec", cmd);
        ...

Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するように設定ファイル configStream の内容を変更することにより、攻撃者はアプリケーションの任意のコマンドを高い権限で実行できます。このプログラムではファイルから読み取った値の検証が実行されないため、攻撃者がこの値を制御できる場合、アプリケーションを操って悪意のあるコードを実行し、システムを制御できます。

例 2: 次のコードは、ユーザーが rman ユーティリティに対するバッチファイルラッパーを使用して Oracle データベースのバックアップを開始し、その後 cleanup.bat スクリプトを実行して一部のテンポラリ ファイルを削除できるインターフェイスを持つ Web アプリケーションのものです。スクリプト rmanDB.bat は、実行するバックアップのタイプを指定するコマンドライン パラメーターを 1 つ受け取ります。データベースへのアクセスが制限されているため、アプリケーションは権限を持つユーザーとしてバックアップを実行します。

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var btype:String = String(params["backuptype"]);
        var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
        fscommand("exec", cmd);
        ...

ここでの問題はプログラムがユーザーから読み取る backuptypeパラメーターを検証しないことです。通常、関数 fscommand() は複数のコマンドを実行しませんが、この例のプログラムは最初に cmd.exe シェルを実行して、fscommnd() を 1 回コールするだけで複数のコマンドを実行しています。呼び出されたシェルは、2 つのアンパサンドで区切られた複数のコマンドを実行できます。攻撃者が "&& del c:\\dbms\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。

例 3: 次のコードは、ユーザーがシステムのパスワードを更新できるインターフェイスを提供する Web アプリケーションのものです。特定のネットワーク環境でパスワードを更新する処理には、/var/yp ディレクトリでの make コマンドの実行が含まれます。

        ...
        fscommand("exec", "make");
        ...

ここでの問題は、プログラムが make のための絶対パスを指定しておらず、fscommand() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。

2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: システムユーティリティの次のコードでは、システムプロパティ APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。

...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...

Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

例 2: 次のコードは、ユーザーが rman ユーティリティに対するバッチファイルラッパーを使用して Oracle データベースのバックアップを開始し、その後 cleanup.bat スクリプトを実行して一部のテンポラリ ファイルを削除できるインターフェイスを持つ Web アプリケーションのものです。スクリプト rmanDB.bat は、実行するバックアップのタイプを指定するコマンドライン パラメーターを 1 つ受け取ります。データベースへのアクセスが制限されているため、アプリケーションは権限を持つユーザーとしてバックアップを実行します。

...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
              + btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...

ここでの問題は、このプログラムが BackupTypeFieldをいっさい検証しないことです。通常、Process.Start() 関数は複数のコマンドを実行しませんが、この例のプログラムは最初に cmd.exe シェルを実行して、Process.Start() を 1 回コールするだけで複数のコマンドを実行しています。呼び出されたシェルは、2 つのアンパサンドで区切られた複数のコマンドを実行できます。攻撃者が "&& del c:\\dbms\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。

例 3: 次のコードは、ユーザーがアクセスしてシステムのパスワードを更新できるインターフェイスを持つ Web アプリケーションのものです。このネットワーク環境でパスワードを更新する処理には、次に示すように update.exe コマンドの実行が含まれます。

...
Process.Start("update.exe");
...

ここでの問題は、プログラムが絶対パスを指定しておらず、Process.start() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、update.exe という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の update.exe もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この例では、1 つ目のシナリオが最も懸念されます。この場合、攻撃者は実行されるコマンドを直接的に制御します。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。


2. データが、アプリケーションがコマンドとして実行する文字列の一部の場合。


3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: 次の単純なプログラムはファイル名をコマンド ライン引数として受け取り、ユーザーに対してファイルの内容を表示します。このプログラムは setuid root にインストールされている、システム管理者用の学習ツールです。権限が設定されているシステム ファイルを変更したりシステムに損傷を与えたりすることができない状態で、それらのファイルをチェックすることができます。

int main(char* argc, char** argv) {
	char cmd[CMD_MAX] = "/usr/bin/cat ";
	strcat(cmd, argv[1]);
	system(cmd);
}

このプログラムは root 権限で実行されるため、system() のコールも root 権限で実行されます。ユーザーが標準的なファイル名を指定した場合、コールは想定どおりに動作します。しかし、攻撃者が ";rm -rf /" という形の文字列を渡すと、system() へのコールでは引数がないため cat を実行できず、root パーティションの内容を回帰的に削除してしまいます。

例 2: 権限が設定されているプログラムの次のコードは、環境変数 $APPHOME を使用してアプリケーションのインストール先ディレクトリを判断し、そのディレクトリの初期化スクリプトを実行します。

	...
	char* home=getenv("APPHOME");
	char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
	if (cmd) {
		strcpy(cmd,home);
		strcat(cmd,INITCMD);
		execl(cmd, NULL);
	}
	...

Example 1 に例示するコードを利用すれば、攻撃者はアプリケーションの権限を高めて任意のコマンドを実行できます。この例では、攻撃者は環境変数 $APPHOME を変更して、INITCMD の悪意ある改変版が置かれた別のパスを指定することができます。プログラムでは環境から読み取った値を検証しないため、攻撃者は環境変数を制御することでアプリケーションを操って悪意あるコードを実行させることができます。

攻撃者は環境変数を使用して、プログラムが呼び出すコマンドを制御します。この例には環境の影響が明らかに示されています。次に、コマンドの解釈を攻撃者が変更できる場合にどうなるか見てみましょう。

例 3: 次のコードは、ユーザーが自分のパスワードを変更するための Web ベースの CGI ユーティリティのものです。NIS によるパスワード更新処理には、/var/yp ディレクトリでの make の実行も含まれます。プログラムはパスワードレコードも更新するので setuid root にインストールされている、ということに注意してください。

プログラムは次のようにして make を呼び出します。

system("cd /var/yp && make &> /dev/null");

前述した例とは異なり、この例ではコマンドはハードコーディングされているため、攻撃者は system() に渡される引数を制御できません。ただし、プログラムでは make の絶対パスが指定されておらず、コマンドを呼び出す前にすべての環境変数がチェックされません。このため、攻撃者は $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、シェル プロンプトから CGI スクリプトを実行させることができます。また、プログラムが setuid root にインストールされているため、攻撃者の make は root 権限で実行されます。

Windows では、この他のリスクも存在します。

例 4:CreateProcess() を直接または _spawn() ファミリの関数のいずれかへのコールを介して呼び出す場合、実行可能ファイルまたはパスにスペースがあるときは注意が必要です。

...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...

CreateProcess() がスペースを解析する方法では、オペレーティングシステムが最初に実行を試みる実行可能ファイルは、MyApplication.exe ではなく Program.exe です。このため、攻撃者がシステムに Program.exe という名前の悪意あるアプリケーションをインストールできる場合、Program Files ディレクトリを使用して CreateProcess() を不正にコールするプログラムは、目的のアプリケーションの代わりにこのアプリケーションを実行します。

環境は、プログラム内のシステムコマンドの実行に大きな役割を果たします。system()、exec()、および CreateProcess() といった関数は、自身をコールするプログラムの環境を使用するため、攻撃者はそれらのコールの動作を変更できる可能性があります。

Command Injection 脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドを明示的に制御します。

- プログラムに対するパラメーターを攻撃者が変更可能である。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を暗黙的に制御します。

この場合は第 2 のシナリオが最も懸念されます。環境変数を変更したり、悪意のある実行可能ファイルを検索パスの最初の方に置くことにより、攻撃者はコマンドの意味を変更することができます。このタイプの Command Injection 脆弱性が発生するのは、次の場合です。

1.攻撃者がアプリケーションの環境を変更する。

2.絶対パスを指定せずに、または実行するバイナリを検証せずに、アプリケーションがコマンドを実行する。



3.アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: この例は、コマンドを解釈する方法を攻撃者が変えられる場合に何が起きるかを示しています。コードは、ユーザーが自分のパスワードを変更するための Web ベースの CGI ユーティリティのものです。NIS によるパスワード更新処理には、/var/yp ディレクトリでの make の実行も含まれます。プログラムはパスワード レコードを更新するため、setuid root にインストールされていることに注意してください。

プログラムは、make を次のように呼び出します。

MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
                               length of command-line
                               run-unit-id
                               stack-size
                               flags

この例のコマンドはハードコードされているため、攻撃者は CBL_EXEC_RUN_UNIT に渡す引数を制御できません。しかしプログラムは make の絶対パスを指定せず、コマンド呼出しの前に環境変数をスクラブしないため、攻撃者は $PATH 変数が make という名前の悪意のあるバイナリをポイントするように変更して、シェル プロンプトから CGI スクリプトを実行できます。さらに、プログラムは setuid root にインストールされているため、攻撃者バージョンの make は root 権限で実行されるようになります。

例 2: 以下のコードは環境変数を使用して、pdfprint コマンドを使用して印刷するファイルを含む一時ディレクトリを決定します。

DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
             ws-temp-dir DELIMITED SPACE
             "/" DELIMITED SIZE
             ws-pdf-filename DELIMITED SPACE
             x"00" DELIMITED SIZE
             INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer

前の例と同様に、コマンドはハードコードされています。しかし、プログラムは pdfprint の絶対パスを指定しないため、攻撃者は $PATH 変数が悪意のあるバイナリをポイントするように変更できます。さらに、DELIMITED SPACE フレーズが ws-temp-dir および ws-pdf-filename における埋め込みスペースを防止する一方で、シェル メタ文字 (&& など) が埋め込まれている可能性もあります。

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。

2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: 次のコードがあると、攻撃者は、cmd リクエストパラメーターを介して任意のコマンドを指定できてしまいます。

    ...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
    arguments = "/c #var#"
    timeout = "1"
    variable="mycmd">
</cfexecute>
    ...

Command Injection 脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドを明示的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を暗黙的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection 脆弱性が発生するのは、次の場合です。

1.信頼できないソースからアプリケーションにデータが入力された場合。

2.アプリケーションによって実行されるコマンドを表す文字列として、またはその一部であるデータが使用された場合。

3.アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: システム ユーティリティの次のコードは、システム プロパティ APPHOME を使用してインストール先ディレクトリを特定し、指定されたディレクトリからの相対パスに基づいて初期化スクリプトを実行します。

	...
	final cmd = String.fromEnvironment('APPHOME');
    await Process.run(cmd);
	...

Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

Command Injection 脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドを明示的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を暗黙的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection 脆弱性が発生するのは、次の場合です。

1.信頼できないソースからアプリケーションにデータが入力された場合。


2.アプリケーションで実行されるコマンドを表す文字列 (またはその一部) としてデータが使用された場合。

3.アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例: 次のコードでは、ユーザー制御のコマンドを実行します。

  cmdName := request.FormValue("Command")
  c := exec.Command(cmdName)
  c.Run()

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。

2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: システムユーティリティの次のコードでは、システムプロパティ APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。

	...
	String home = System.getProperty("APPHOME");
	String cmd = home + INITCMD;
	java.lang.Runtime.getRuntime().exec(cmd);
	...

Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

例 2: 次のコードは、ユーザーが rman ユーティリティに対するバッチファイルラッパーを使用して Oracle データベースのバックアップを開始し、その後 cleanup.bat スクリプトを実行して一部のテンポラリ ファイルを削除できるインターフェイスを持つ Web アプリケーションのものです。スクリプト rmanDB.bat は、実行するバックアップのタイプを指定するコマンドライン パラメーターを 1 つ受け取ります。データベースへのアクセスが制限されているため、アプリケーションは権限を持つユーザーとしてバックアップを実行します。

...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...

ここでの問題はプログラムがユーザーから読み取る backuptypeパラメーターを検証しないことです。通常、関数 Runtime.exec() は複数のコマンドを実行しませんが、この例のプログラムは最初に cmd.exe シェルを実行して、Runtime.exec() を 1 回コールするだけで複数のコマンドを実行しています。呼び出されたシェルは、2 つのアンパサンドで区切られた複数のコマンドを実行できます。攻撃者が "&& del c:\\dbms\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。

例 3: 次のコードは、ユーザーがシステムのパスワードを更新できるインターフェイスを提供する Web アプリケーションのものです。特定のネットワーク環境でパスワードを更新する処理には、/var/yp ディレクトリでの make コマンドの実行が含まれます。

...
System.Runtime.getRuntime().exec("make");
...

ここでの問題は、プログラムが make のための絶対パスを指定しておらず、Runtime.exec() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。

一部には、モバイルの世界では Command Injection のような古典的な脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 4: 次のコードは、Android のインテントから実行されるコマンドを読み取ります。

...
        String[] cmds = this.getIntent().getStringArrayExtra("commands");
	Process p = Runtime.getRuntime().exec("su");
        DataOutputStream os = new DataOutputStream(p.getOutputStream());
        for (String cmd : cmds) {
        	os.writeBytes(cmd+"\n");
        }
        os.writeBytes("exit\n");
        os.flush();
...

ルート化されたデバイス上では、悪意のあるアプリケーションが標的となるアプリケーションにスーパー ユーザーの権限で任意のコマンドを強制的に実行させることができます。

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。


2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: システム ユーティリティの次のコードでは、環境変数 APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。

var cp = require('child_process');
  ...
  var home = process.env('APPHOME');
  var cmd = home + INITCMD;
  child = cp.exec(cmd, function(error, stdout, stderr){
    ...
  });
  ...

Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システム プロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

例 2: 次のコードは、ユーザーが rman ユーティリティに対するバッチファイル ラッパーを使用して Oracle データベースのバックアップを開始できるようにする管理用 Web アプリケーションのものです。スクリプト rmanDB.bat は、実行するバックアップのタイプを指定するコマンドライン パラメーターを 1 つ受け取ります。データベースへのアクセスが制限されているため、アプリケーションは権限を持つユーザーとしてバックアップを実行します。

var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
  var btype = url.parse(request.url, true)['query']['backuptype'];
  if (btype !== undefined){
    cmd = "c:\\util\\rmanDB.bat" + btype;
    cp.exec(cmd, function(error, stdout, stderr){
      ...
    });
  }
  ...
}
...
http.createServer(listener).listen(8080);

ここでの問題は、プログラムがユーザーから読み取る backuptypeパラメーターを、その存在を除いて検証しないことです。シェルが呼び出されると、複数のコマンドの実行が許可され、アプリケーションの特性により、データベースとの対話に必要な権限を使用して実行されるので、攻撃者が挿入する任意のコマンドもそれらの権限を使用して実行されることになります。

例 3: 次のコードは、ユーザーがシステムのパスワードを更新できるインターフェイスを提供する Web アプリケーションのものです。特定のネットワーク環境でパスワードを更新する処理には、/var/yp ディレクトリでの make コマンドの実行が含まれます。

...
require('child_process').exec("make", function(error, stdout, stderr){
  ...
});
...

ここでの問題は、プログラムが make の絶対パスを指定しておらず、child_process.exec() の呼び出しを実行する前に環境をクリーニングできないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。

2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: システムユーティリティの次のコードでは、システムプロパティ APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。

	...
	$home = $_ENV['APPHOME'];
	$cmd = $home . $INITCMD;
	system(cmd);
	...

Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

例 2: 次のコードは、ユーザーが rman ユーティリティに対するバッチファイルラッパーを使用して Oracle データベースのバックアップを開始し、その後 cleanup.bat スクリプトを実行して一部のテンポラリ ファイルを削除できるインターフェイスを持つ Web アプリケーションのものです。スクリプト rmanDB.bat は、実行するバックアップのタイプを指定するコマンドライン パラメーターを 1 つ受け取ります。データベースへのアクセスが制限されているため、アプリケーションは権限を持つユーザーとしてバックアップを実行します。

...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...

ここでの問題はプログラムがユーザーから読み取る backuptypeパラメーターを検証しないことです。通常、関数 Runtime.exec() は複数のコマンドを実行しませんが、この例のプログラムは最初に cmd.exe シェルを実行して、Runtime.exec() を 1 回コールするだけで複数のコマンドを実行しています。呼び出されたシェルは、2 つのアンパサンドで区切られた複数のコマンドを実行できます。攻撃者が "&& del c:\\dbms\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。

例 3: 次のコードは、ユーザーがシステムのパスワードを更新できるインターフェイスを提供する Web アプリケーションのものです。特定のネットワーク環境でパスワードを更新する処理には、/var/yp ディレクトリでの make コマンドの実行が含まれます。

...
$result = shell_exec("make");
...

ここでの問題は、プログラムが make のための絶対パスを指定しておらず、Runtime.exec() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。

2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例: 次のコードは、信頼できないデータでコールされた場合、攻撃者によって制御されたシステム コマンドを実行する T-SQL ストアド プロシージャを定義します。

...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。

2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: システムユーティリティの次のコードでは、システムプロパティ APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。

	...
	home = os.getenv('APPHOME')
	cmd = home.join(INITCMD)
	os.system(cmd);
	...

Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

例 2: 次のコードは、ユーザーが rman ユーティリティに対するバッチファイルラッパーを使用して Oracle データベースのバックアップを開始し、その後 cleanup.bat スクリプトを実行して一部のテンポラリ ファイルを削除できるインターフェイスを持つ Web アプリケーションのものです。スクリプト rmanDB.bat は、実行するバックアップのタイプを指定するコマンドライン パラメーターを 1 つ受け取ります。データベースへのアクセスが制限されているため、アプリケーションは権限を持つユーザーとしてバックアップを実行します。

...
	btype = req.field('backuptype')
	cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
	os.system(cmd);
...

ここでの問題はプログラムがユーザーから読み取る backuptypeパラメーターを検証しないことです。通常、関数 Runtime.exec() は複数のコマンドを実行しませんが、この例のプログラムは最初に cmd.exe シェルを実行して、Runtime.exec() を 1 回コールするだけで複数のコマンドを実行しています。呼び出されたシェルは、2 つのアンパサンドで区切られた複数のコマンドを実行できます。攻撃者が "&& del c:\\dbms\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。

例 3: 次のコードは、ユーザーがシステムのパスワードを更新できるインターフェイスを提供する Web アプリケーションのものです。特定のネットワーク環境でパスワードを更新する処理には、/var/yp ディレクトリでの make コマンドの実行が含まれます。

...
result = os.system("make");
...

ここでの問題は、プログラムが make のための絶対パスを指定しておらず、os.system() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。


2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: システムユーティリティの次のコードでは、システムプロパティ APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。

...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...

Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

例 2: 次のコードは、ユーザーが rman ユーティリティに対するバッチファイルラッパーを使用して Oracle データベースのバックアップを開始し、その後 cleanup.bat スクリプトを実行して一部のテンポラリ ファイルを削除できるインターフェイスを持つ Web アプリケーションのものです。スクリプト rmanDB.bat は、実行するバックアップのタイプを指定するコマンドライン パラメーターを 1 つ受け取ります。データベースへのアクセスが制限されているため、アプリケーションは権限を持つユーザーとしてバックアップを実行します。

...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...

ここでの問題はプログラムがユーザーから読み取る backuptypeパラメーターを検証しないことです。Kernel.spawn 経由で呼び出されたシェルは、2 つのアンパサンドで区切られた複数のコマンドの実行を許可します。攻撃者が "&& del c:\\dbms\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。

例 3: 次のコードは、ユーザーがシステムのパスワードを更新できるインターフェイスを提供する Web アプリケーションのものです。特定のネットワーク環境でパスワードを更新する処理には、/var/yp ディレクトリでの make コマンドの実行が含まれます。

...
system("make")
...

ここでの問題は、プログラムが make のための絶対パスを指定しておらず、Kernel.system() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。

Command Injection の脆弱性には、次の 2 つの形態があります。

- プログラムが実行するコマンドを攻撃者が変更可能である。この場合、攻撃者はコマンドの内容を直接的に制御します。

- コマンドが実行される環境を攻撃者が変更可能である。この場合、攻撃者はコマンドの動作を間接的に制御します。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は実行されるコマンドを制御できる可能性があります。このタイプの Command Injection の脆弱性が発生するのは、次の場合です。

1. 信頼できないソースからアプリケーションにデータが入り込んだ場合。

2. データが、アプリケーションが実行するコマンドを表す文字列 (またはその一部) として使用された場合。

3. アプリケーションがコマンドを実行することにより、本来付与されないはずの権限や機能が攻撃者に与えられた場合。

例 1: システムユーティリティの次のコードでは、システムプロパティ APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。

	...
	Dim cmd
	Dim home

	home = Environ$("AppHome")
	cmd = home & initCmd
	Shell cmd, vbNormalFocus
	...

Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。

例 2: 次のコードは、ユーザーが rman ユーティリティに対するバッチファイルラッパーを使用して Oracle データベースのバックアップを開始し、その後 cleanup.bat スクリプトを実行して一部のテンポラリ ファイルを削除できるインターフェイスを持つ Web アプリケーションのものです。スクリプト rmanDB.bat は、実行するバックアップのタイプを指定するコマンドライン パラメーターを 1 つ受け取ります。データベースへのアクセスが制限されているため、アプリケーションは権限を持つユーザーとしてバックアップを実行します。

...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...

ここでの問題はプログラムがユーザーから読み取る backuptypeパラメーターを検証しないことです。呼び出されたシェルは、2 つのアンパサンドで区切られた複数のコマンドを実行できます。攻撃者が "&& del c:\\dbms\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。

例 3: 次のコードは、ユーザーがシステムのパスワードを更新できるインターフェイスを提供する Web アプリケーションのものです。特定のネットワーク環境でパスワードを更新する処理には、/var/yp ディレクトリでの make コマンドの実行が含まれます。

...
$result = shell_exec("make");
...

ここでの問題は、プログラムが make のための絶対パスを指定しておらず、Runtime.exec() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。

最近の Web ブラウザーは、cookie ごとに Secure フラグをサポートします。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークがスニッフィングされる可能性がありますが、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。

例 1: 次の例では、isSecure パラメーターを true に設定せずに cookie が作成されています。

...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...

HTTPS と HTTP の両方が使用されていても isSecure パラメーターが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はそれ以降の HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックをスニッフィングするのは攻撃者にとって簡単です。また、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。

最近の Web ブラウザでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。

例: 次の例では、Secure プロパティを設定せずにレスポンスに cookie が追加されています。

...
 HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);
...

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。

最近の Web ブラウザーでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報またはセッション ID が保存されている場合や、cookie によって CSRF トークンが送信される場合、特に重要です。
例 1: 次のコードでは、Secure フラグを設定せずに cookie がレスポンスに追加されています。

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
http.SetCookie(response, &cookie)
...

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。

最近の Web ブラウザーでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。

例 1: 次の例では、use-secure-cookie 属性によって remember-me cookie が有効化され、暗号化されていない転送によって送信されます。

	<http auto-config="true">
        ...
        <remember-me use-secure-cookie="false"/>
	</http>

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。

最近の Web ブラウザでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。
例 1: 次の例では、Secure プロパティを true に設定せずにレスポンスに cookie が追加されています。

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。

最近の Web ブラウザでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。
例 1: 下記の例では、Secure フラグを設定せずにレスポンスに cookie が追加されています。

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。

最近の Web ブラウザでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。
例 1: 次のコードでは、Secure フラグを設定せずに cookie がレスポンスに追加されています。

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックを盗聴することによって cookie を入手できます。特に無線ネットワークの場合はネットワーク トラフィックを盗聴することは非常に簡単です。

最近の Web ブラウザでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報またはセッション ID が保存されている場合や、cookie によって CSRF トークンが送信される場合に特に重要になります。
例 1: 次のコードでは、Secure フラグを設定せずに cookie がレスポンスに追加されています。

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックを盗聴することによって cookie を入手できます。特に無線ネットワークの場合はネットワーク トラフィックを盗聴することは非常に簡単です。

最近の Web ブラウザーでは、cookie ごとに Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。
例 1: 下記の例では、Secure フラグを設定せずにレスポンスに cookie が追加されています。

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

HTTPS と HTTP の両方が使用されていても Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。

主要なブラウザーでサポートされている HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly プロパティが設定されずに cookie が作成されています。

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);

ブラウザーで cookie プロパティ HttpOnly を設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly を有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly プロパティが設定されずに cookie が作成されています。

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
...

主要なブラウザーでサポートされている HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly プロパティが設定されずに cookie が作成されています。

javax.servlet.http.Cookie cookie = new javax.servlet.http.Cookie("emailCookie", email);
// Missing a call to: cookie.setHttpOnly(true);

主要なブラウザーでサポートされている HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、httpOnly プロパティが設定されずに cookie が作成されています。

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});

主要なブラウザーでサポートされている HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly プロパティが設定されずに cookie が作成されています。

setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE);  //Missing 7th parameter to set HttpOnly

ブラウザで HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。
例 1: 次のコードでは、HttpOnly プロパティが設定されずに cookie が作成されています。

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例:http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。

例：

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Domain = ".example.com";

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションにクロスサイト スクリプティングの脆弱性が存在するとします。 http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッション ID の cookie が設定されます。

例：

cookie := http.Cookie{
  Name:       "sessionID",
  Value:      getSessionID(),
  Domain:     ".example.com",
}
...

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションにクロスサイト スクリプティングの脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

攻撃者は、cookie の読み取りに加えて、「Cookie Poisoning 攻撃」を実行することもあります。その場合、攻撃者は insecure.example.com を使用して、パスがあまりに広範にわたっている cookie を独自に作成し、Secure.example.com からの cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。

例：

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setDomain(".example.com");

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。

例：

  cookie_options = {};
  cookie_options.domain = '.example.com';
  ...
  res.cookie('important_cookie', info, cookie_options);

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。

例：

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。

例：

setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。

例：

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
  return res
...

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、「Cookie Poisoning 攻撃」が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は ".example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。

例：

...
let properties = [
    NSHTTPCookieDomain: ".example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

安全性の劣る別のアプリケーションが http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。例：

...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...

攻撃者が http://communitypages.example.com/EvilSite に別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスしたフォーラム ユーザーのアカウントであれば、危険にさらされることがあります。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス "/" に設定する傾向にありますが、この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。

例：

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Path = "/";

攻撃者が http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、「/」というパスを持つセッション ID の cookie が設定されます。

例：

cookie := http.Cookie{
  Name:    "sessionID",
  Value:   sID,
  Expires: time.Now().AddDate(0, 0, 1),
  Path:    "/",
}
...

攻撃者が http://communitypages.example.com/EvilSite に別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。フォーラム ユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションへ送信します。攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスしたフォーラム ユーザーのアカウントであれば、危険にさらされることがあります。

攻撃者は、cookie の読み取りに加えて、「Cookie Poisoning 攻撃」を実行することもあります。その場合、攻撃者は /EvilSite を使用して、パスがあまりに広範にわたっている cookie を独自に作成し、/MyForum からの cookie を上書きします。

開発者は cookie を root コンテキストパス ("/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。

例 1:http://communitypages.example.com/MyForum にフォーラムアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。

例：

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setPath("/");

攻撃者が http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。

cookie の読み取りに加えて、Cookie Poisoning 攻撃が実行される可能性もあります。その場合、攻撃者は /EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。