データベースの 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. データベース名の値を指定するのにデータが使用される場合。

データベースの 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 クエリを作成し、実行します [1]。 識別子は、現在の認証されたユーザーに関連付けられているすべての領収書のリストから選択されています。

  def searchInvoice(value:String) = Action.async { implicit request =>
    val result: Future[Seq[Invoice]] = db.run {
      sql"select * from invoices where id=$value".as[Invoice]
    }
    ...
  }

問題は、開発者が 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 つの形態があります。

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

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

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

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

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

例 1: 次のコードは、信頼できないデータでコールされた場合、攻撃者によって制御されたシステム コマンドを実行する 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 つの形態があります。

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

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

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

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

2.アプリケーションが、絶対パスを指定しないか、実行されるバイナリを検証しないでコマンドを実行する場合。

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

例 1: 次のコードは、ユーザーがシステムのパスワードを更新できるインターフェイスを提供する Web アプリケーションのものです。

def changePassword(username: String, password: String) = Action { request =>
    ...
    s'echo "${password}" | passwd ${username} --stdin'.!
    ...
}

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 もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1. 信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。 持続型 XSS (別名: ストアド XSS) の場合、信頼できないソースはデータベースなどのバックエンドデータストアであるのが一般的です。一方、リフレクト XSS の場合は Web リクエストであるのが一般的です。


2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

例 1: 次の ABAP コードセグメントは特定の ID の従業員をデータベースでクエリし、対応する従業員の名前を出力します。

...
DATA: BEGIN OF itab_employees,
        eid   TYPE employees-itm,
        name  TYPE employees-name,
      END OF itab_employees,
      itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.

SELECT *
  FROM employees
  INTO CORRESPONDING FIELDS OF TABLE itab_employees
  FOR ALL ENTRIES IN itab
  WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...

name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

例 2: 次の ABAP コードセグメントは従業員 ID eid を HTTP リクエストから読み取り、ユーザーに表示します。

...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...

Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを入れるコードにより引き起こされます。XSS 攻撃が被害をもたらす可能性のある手段は 3 つあります。

- Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。

- Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1. 信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。 持続型 XSS (別名: ストアド XSS) の場合、信頼できないソースはデータベースなどのバックエンドデータストアであるのが一般的です。一方、リフレクト XSS の場合は Web リクエストであるのが一般的です。


2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

例 1: 次の ActionScript のコードセグメントは特定の ID の従業員をデータベースでクエリし、対応する従業員の名前を出力します。

  stmt.sqlConnection = conn;
  stmt.text = "select * from emp where id="+eid;
  stmt.execute();
  var rs:SQLResult = stmt.getResult();
  if (null != rs) {
    var name:String = String(rs.data[0]);
    var display:TextField = new TextField();
    display.htmlText = "Employee Name: " + name;
  }

name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

例 2: 次の ActionScript コードセグメントは従業員 ID eid を HTTP リクエストから読み取り、ユーザーに表示します。

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...

Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを入れるコードにより引き起こされます。XSS 攻撃が被害をもたらす可能性のある手段は 3 つあります。

- Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。

- Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1.信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。持続型 XSS の場合、信頼できないソースはデータベース クエリの結果であることが多く、リフレクト XSS の場合は Web リクエストであることが一般的です。

2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

悪意のあるコンテンツは通常、JavaScript コードの一部となっていますが、ほかにも、HTML、Flash、またはブラウザーによって実行される可能性のあるアクティブなコンテンツである場合もあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

例 1:次の Apex コードセグメントは、特定の ID を持つ連絡先名をデータベースに照会し、対応する従業員名を返します。返された従業員名は、後で Visualforce コードによって出力されます。

...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...

<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>

name の値が単なる英数字のように適切に定義されている場合はこのコードが正しく動作しますが、悪意のあるデータのチェックは行われません。データベースの内容はユーザー指定のデータから取得されることがあるため、データベースから読み取る場合でも値を適切に検証する必要があります。このように、攻撃者はリフレクト XSS でのように攻撃対象者とやり取りしなくても、ユーザーの Web ブラウザ内で悪意のあるコマンドを実行することができます。このタイプの攻撃はストアド XSS (または持続型 XSS) と呼ばれていて、データが脆弱な関数に間接的に提供されるため、検出するのが非常に困難な場合があります。また、複数のユーザーに影響する可能性があるため、影響が大きくなることもあります。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含め、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

例 2: 次の Visualforce コード セグメントは HTTP リクエスト パラメーター username を読み取って、ユーザーに表示します。

<script>
document.write('{!$CurrentPage.parameters.username}')
</script>

この例のコードは、英数字のテキストのみを受け取って、表示することを目的としていました。ただし、username にメタ文字またはソース コードが含まれている場合、コードは Web ブラウザで実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを入れるコードにより引き起こされます。XSS 攻撃を実行する際に使用される手段は 2 つあります。

- Example 1 に示すように、データベースなどのデータ ストアからアプリケーションに危険なデータが提供され、動的コンテンツに追加されることがあります。攻撃者の立場からすると、悪意のあるコンテンツを保存するのに最適な場所は、すべてのユーザー (特に、高い権限を持つ、機密情報の処理や重要な操作を実行する可能性の高いユーザー) がアクセスできる領域です。

- ,Example 2 に示すように、データが HTTP リクエストから読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS は、攻撃者が脆弱な Web アプリケーションに危険なコンテンツを配信し、それをユーザーに反映して、ユーザーのブラウザで実行するように設定できる場合に発生します。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は攻撃対象者をこの URL に誘い込みます。コンテンツがユーザーに戻されてサイトに反映されると、コンテンツが実行され、攻撃対象者のコンピュータから個人の機密情報を転送する、不正な操作を実行する、などの複数の操作が実行可能になります。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1. 信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。 持続型 XSS (別名: ストアド XSS) の場合、信頼できないソースはデータベースなどのバックエンドデータストアであるのが一般的です。一方、リフレクト XSS の場合は Web リクエストであるのが一般的です。


2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

例 1: 次の ASP.NET の Web フォームは、データベースに対して、指定された従業員 ID を持つ従業員をクエリし、その ID に関連づけられている名前を出力します。

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>

EmployeeName は、次のように定義されるフォーム コントロールです。

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

例 2: 次の ASP.NET コードセグメントは、Example 1 と機能的には同じですが、すべてのフォーム要素をプログラミングによって実装しています。

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;

name の値の動作が適切であればこれらのコード例は正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

例 3: 次の ASP.NET Web フォームは、従業員 ID 番号を HTTP リクエストから読み取り、ユーザーに対して表示します。

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

Login および EmployeeID は、次のように定義されるフォーム コントロールです。

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

例 4: 次の ASP.NET コードセグメントは、Example 3 をプログラミングで実装する方法を示しています。

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

Example 1 や Example 2 のような例では、Login に標準の英数字テキストだけが含まれている場合に正しく動作します。Login の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。 実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意ある内容が攻撃対象のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを入れるコードにより引き起こされます。XSS 攻撃が被害をもたらす可能性のある手段は 3 つあります。

- Example 1 および Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。

- Example 3 や Example 4 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。

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

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1. 信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。 持続型 XSS (別名: ストアド XSS) の場合、信頼できないソースはデータベースなどのバックエンドデータストアであるのが一般的です。一方、リフレクト XSS の場合は Web リクエストであるのが一般的です。


2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

例 1: 次の CFML コードセグメントは特定の ID の従業員をデータベースでクエリし、対応する従業員の名前を出力します。

 
<cfquery name="matchingEmployees" datasource="cfsnippets">
  SELECT name
  FROM Employees 
  WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>

name の値の動作が適切であれば、この例のコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

例 2: 次の CFML コードセグメントは従業員 ID eid を Web フォームから読み取りユーザーに表示します。

<cfoutput>
Employee ID: #Form.eid#
</cfoutput>

Example 1 と同様に、このコードは、Form.eid に標準の英数字テキストだけが含まれている場合に正しく動作します。Form.eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを入れるコードにより引き起こされます。XSS 攻撃が被害をもたらす可能性のある手段は 3 つあります。

- Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。

- Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1.信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。リフレクト XSS の場合、信頼できないソースは Web リクエストであることが最も多く、一方、持続型 XSS (別名: ストアド XSS) の場合はデータベースなどのバックエンドデータストアであるのが一般的です。

2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。


例 1: 次の Go コード セグメントはユーザー名 user を HTTP リクエストから読み取り、ユーザーに表示します。

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  user := r.FormValue("user")
  ...
  fmt.Fprintln(w, "Username is: ", user)
}

この例のコードは、user に標準の英数字テキストだけが含まれている場合に正しく動作します。user の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

例 2: 次の Go コード セグメントは特定の ID の従業員をデータベースでクエリし、対応する従業員の名前を出力します。

func someHandler(w http.ResponseWriter, r *http.Request){
  ...
  row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
  err := row.Scan(&name)
  ...
  fmt.Fprintln(w, "Username is: ", name)
}

Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザーで攻撃者が悪意あるコマンドを実行することがあります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターに「ゲストブック」を提供している Web サイトで、次のような形式で開始されます。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを含めるコードによって発生します。被害を及ぼす可能性のある XSS 攻撃手段は 3 つあります。

- Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険なコンテンツを入力させられてしまい、それがユーザーに送り返されて Web ブラウザーにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意あるコンテンツを実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりすることがあります。

- アプリケーション外のソースで危険なデータがデータベースなどのデータ ストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1. 信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。 持続型 XSS (別名: ストアド XSS) の場合、信頼できないソースはデータベースなどのバックエンドデータストアであるのが一般的です。一方、リフレクト XSS の場合は Web リクエストであるのが一般的です。


2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

例 1: 次の JSP コードセグメントは特定の ID の従業員をデータベースでクエリし、対応する従業員の名前を出力します。

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

例 2: 次の JSP コード セグメントは従業員 ID eid を HTTP リクエストから読み取ってユーザーに表示します。

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

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

例 3: 次のコードでは、Android の WebView で JavaScript を有効にして (デフォルトでは JavaScript は無効)、Android インテントから受け取った値に基づいてページをロードできます。

...
        WebView webview = (WebView) findViewById(R.id.webview);
        webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

url の値が javascript: から始まる場合、それに続く JavaScript コードが WebView 内の Web ページのコンテキストから実行されます。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを入れるコードにより引き起こされます。XSS 攻撃が被害をもたらす可能性のある手段は 3 つあります。

- Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。

- Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。

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