大部分の攻撃は、プログラマーにとって想定外の事態から始まります。DTD または XML スキーマに対して未検証の XML 文書を受け入れると、攻撃者に予期しない不当な悪意のある入力を自由に行わせてしまうことになります。XML パーサーが文書のコンテンツのすべての側面を検証することは不可能です。パーサーはデータのセマンティクスを完全には理解できません。しかし、パーサーは文書構造の完全なチェックを徹底的に行うことはできます。したがって、文書を処理するコードにコンテンツが適正形式であることを保証できます。

大部分の攻撃は、プログラマにとって想定外の事態から始まります。DTD または XML スキーマに対して未検証の XML 文書を受け入れると、攻撃者に予期しない不当な悪意のある入力を自由に行わせてしまうことになります。XML パーサーが文書のコンテンツのすべての側面を検証することは不可能です。パーサーはデータのセマンティクスを完全には理解できません。しかし、パーサーは文書構造の完全なチェックを徹底的に行うことはできます。したがって、文書を処理するコードにコンテンツが適正形式であることを保証できます。

DynamoDB エラーの NoSQL Injection 脆弱性は、次の場合に発生します。

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



2.データが DynamoDB クエリの動的な構築に使用された場合。

例 1: 次のコードは、パスワードとともに電子メール アドレスまたはユーザー名が付与されたユーザーを検索する DynamoDB クエリを動的に構築して実行します。

...
    // "type" parameter expected to be either: "Email" or "Username"
    String type = request.getParameter("type")
    String value = request.getParameter("value")
    String password = request.getParameter("password")
    
    DynamoDbClient ddb = DynamoDbClient.create();

    HashMap<String, AttributeValue> attrValues = new HashMap<String,AttributeValue>();
    attrValues.put(":value", AttributeValue.builder().s(value).build());
    attrValues.put(":password", AttributeValue.builder().s(password).build());

    ScanRequest queryReq = ScanRequest.builder()
        .filterExpression(type + " = :value AND Password = :password")
        .tableName("users")
        .expressionAttributeValues(attrValues)
        .build();

    ScanResponse response = ddb.scan(queryReq);
...

このコードによって実行されるクエリは次のようになります。

Email = :value AND Password = :password

または

Username = :value AND Password = :password

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、クエリは type に予想される値のみが含まれる場合に正しく動作します。攻撃者が :value = :value OR :value などの値のタイプを指定すると、クエリは次のようになります。

:value = :value OR :value = :value AND Password = :password

:value = :value 条件を追加すると、where 句は常に真 (true) の評価を行います。そのため、このクエリは、電子メールの所有者に関係なく、users コレクションに保存されたすべてのエントリを返します。

MongoDB エラーの NoSQL Injection は、次の場合に発生します。

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



2. データが MongoDB クエリの動的な構築に使用された場合。

例 1: 次のコードは、特定の ID を持つ電子メールを検索する MongoDB クエリを動的に構築し、実行します。

...
    String userName = ctx.getAuthenticatedUserName();
    String emailId = request.getParameter("emailId")
    MongoCollection<Document> col = mongoClient.getDatabase("MyDB").getCollection("emails");
    BasicDBObject Query = new BasicDBObject();
    Query.put("$where", "this.owner == \"" + userName + "\" && this.emailId == \"" + emailId + "\"");
    FindIterable<Document> find= col.find(Query);
...

このコードによって実行されるクエリは次のようになります。

    this.owner == "<userName>" && this.emailId == "<emailId>"

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、emailId に二重引用符が含まれない場合のみクエリは正しく動作します。 ユーザー名 wiley を持つ攻撃者が文字列「123" || "4" != "5」を emailId に入力すると、クエリは次のようになります。

    this.owner == "wiley" && this.emailId == "123" || "4" != "5"

|| "4" != "5" 条件を追加すると、where 句は常に真 (true) の評価を行います。そのため、このクエリは、電子メールの所有者に関係なく、emails コレクションに保存されたすべてのエントリを返します。

MongoDB エラーの NoSQL Injection は、次の場合に発生します。

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



2. データが MongoDB クエリの動的な構築に使用された場合。

例 1: 次のコードは、特定の ID を持つ電子メールを検索する MongoDB クエリを動的に構築し、実行します。

...
    userName = req.field('userName')
    emailId = req.field('emaiId')
    results = db.emails.find({"$where", "this.owner == \"" + userName + "\" && this.emailId == \"" + emailId + "\""});
...

このコードによって実行されるクエリは次のようになります。

    this.owner == "<userName>" && this.emailId == "<emailId>"

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、emailId に二重引用符が含まれない場合のみクエリは正しく動作します。 ユーザー名 wiley を持つ攻撃者が文字列「123" || "4" != "5」を emailId に入力すると、クエリは次のようになります。

    this.owner == "wiley" && this.emailId == "123" || "4" != "5"

|| "4" != "5" 条件を追加すると、where 句は常に真 (true) の評価を行います。そのため、このクエリは、電子メールの所有者に関係なく、emails コレクションに保存されたすべてのエントリを返します。

NULL ポインタの例外は通常、プログラマの想定が破られた結果として発生します。この問題には、少なくとも次の 3 種類があります。間接参照後チェック、チェック後間接参照、格納後間接参照です。間接参照後チェックのエラーが発生するのは、プログラムで、ポインタが null であるかを確認する前に、null の可能性があるポインタを間接参照する場合です。チェック後間接参照のエラーが発生するのは、プログラムが null に対して明示的チェックを実行したにも関わらず、null であることが判明しているポインタを間接参照した場合です。この種のエラーの多くは、タイプミスかプログラマの不注意が原因です。格納後間接参照のエラーは、プログラムが明示的にポインタを null に設定し、後でそのポインタを間接参照した場合に発生します。このエラーは通常、変数の宣言時にプログラマがその変数を null に初期化したことが原因で発生します。

NULL ポインタの問題点の大半は一般にソフトウェアの信頼性の問題につながります。しかし、攻撃者が意図的に NULL ポインタ間接参照を引き起こせる場合、その結果生じた例外を利用してセキュリティ ロジックをバイパスすることで Denial of Service 攻撃を実装したり、アプリケーションにデバッグ情報を開示させてそれ以降の攻撃に役立てたりすることができます。

例 1: 次のコードでは、プログラマは変数 ptr は NULL ではないと仮定してします。この仮定は、プログラマがポインタを間接参照したときに明らかになります。その後プログラマが ptr と NULL を比較したときに、この仮定は成り立たなくなります。ptr が if ステートメントでチェックされたときに NULL であるとすれば、間接参照されたときにも NULL である可能性があり、これがセグメンテーション違反の原因となる場合があります。

ptr->field = val;
...
if (ptr != NULL) {
	...
}

例 2: 次のコードでは、プログラマは変数 ptr が NULL であることを確認してから、続いてそれを誤って間接参照しています。ptr が if ステートメントでチェックされたときに NULL になっていると、null Dereference が発生し、これがセグメンテーション違反の原因となります。

if (ptr == null) {
        ptr->field = val;
        ...
}

例 3: 次のコードでは、プログラマが文字列 '\0' (実際は 0) または NULL を忘れたため、NULL ポインタを間接参照し、セグメンテーション違反を引き起こしています。

if (ptr == '\0') {
        *ptr = val;
        ...
}

例 4: 次のコードでは、プログラマは明示的に変数 ptr を NULL に設定しています。続いて、オブジェクトの null 値をチェックする前に ptr を間接参照しています。

*ptr = NULL;
...
ptr->field = val;
...
}

NULL ポインタエラーは通常、プログラマの想定が破られた結果として発生します。

NULL ポインタの問題点の大半は一般にソフトウェアの信頼性の問題をもたらします。しかし、攻撃者が意図的に NULL ポインタ間接参照を引き起こせる場合、その結果生じた例外を利用してセキュリティ ロジックを回避したり、アプリケーションにデバッグ情報を開示させてそれ以降の攻撃に役立てたりすることができます。

例 1: 次のコードでは、プログラマは、システムに常に「cmd」という名前の定義されたプロパティがあると前提しています。攻撃者がプログラムの環境を制御して「cmd」を未定義にできる場合、プログラムが trim() メソッドのコールを試みると NULL ポインタ例外が発生します。

String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
	val = util.translateCommand(cmd);
...
cmd = val.trim();

一般に、プログラミング言語の進化に伴い、以下の理由でメソッドが廃止されることがあります。

- 言語の進歩
- 操作の効率的で安全な実行方法に関する
理解の向上
- 特定の操作について定めた規則の変更

ある言語から削除されたステートメントは通常、より優れていると思われる別の方法で同じタスクを実行する新しい関数に置き換えられます。

特に、SAP ABAP は、ABAP Objects (ABAP のオブジェクト指向の拡張機能) を含み、Unicode 互換環境で動作するように発展したものです。その結果、クラスまたは Unicode プログラムでより厳密な構文が強制されます。古いリリースとの互換性のためだけに廃止済みのコンストラクトを現在でも使用でき、クラス外または Unicode 以外のプログラムでのみ使用できます。廃止済みのすべての言語要素のために代替コンストラクトがあり、プログラムの効率と読みやすさが向上します。廃止済みの構文内の暗黙的であいまいな多数のタイプ/長さ/メモリ仕様を、より正確で明示的な方法で新しい構文に指定する必要があります。プログラムをわかりやく、より堅牢で保守しやすくするために、新しい構文を採用することをお勧めします。


すべての関数がセキュリティリスクを招くという理由で廃止されたり、置き換えられたりするわけではありません。しかし多くの場合、廃止された関数があることは、その周辺のコードが無視されており、メンテナンスされていない状態であることを示します。ソフトウェアセキュリティは長い間、優先事項どころか検討事項ですらありませんでした。廃止予定または廃止済みの関数がプログラムで使用されていると、その周辺にセキュリティ上の問題がある可能性が浮上します。

プログラミング言語の進化に伴い、以下の理由で関数が廃止されることがあります。

- 言語の進歩
- 操作の効率的で安全な実行方法に関する理解の向上
- 特定の操作について定めた規則の変更

削除された関数は通常、より優れていると思われる別の方法で同じタスクを実行する新しい関数に置き換えられます。
例 1: 次のコードは、旧式の関数 getpw() を使用して平文のパスワードが、暗号化されたユーザー パスワードと一致するかどうかを検証しています。パスワードが有効であれば、関数は result を 1 に、それ以外の場合は 0 に設定します。

	...
	getpw(uid, pwdline);
	for (i=0; i<3; i++){
	cryptpw=strtok(pwdline, ":");
		pwdline=0;
	}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
	...

コードが正しく動作していても、セキュリティの面から getpw() 関数が問題になることがあります。これは、2 つ目のパラメーターに渡されたバッファがオーバーフローするためです。この脆弱性のために、getpw() は、getpw() と同じルックアップを実行しても、静的に割り当てられた構造体にポインタを戻す (リスクを緩和するため) getpwuid() に置き換えられてきました。

すべての関数がセキュリティリスクを招くという理由で廃止されたり、置き換えられたりするわけではありません。しかし多くの場合、廃止された関数があることは、その周辺のコードが無視されており、メンテナンスされていない状態であることを示します。ソフトウェアセキュリティは長い間、優先事項どころか検討事項ですらありませんでした。廃止予定または廃止済みの関数がプログラムで使用されていると、その周辺にセキュリティ上の問題がある可能性が浮上します。

プログラミング言語の進化に伴い、以下の理由でメソッドが廃止されることがあります。

- 言語の進歩
- 操作の効率的で安全な実行方法に関する
理解の向上
- 特定の操作について定めた規則の変更

ある言語から削除されたメソッドは通常、より優れていると思われる別の方法で同じタスクを実行する新しいメソッドに置き換えられます。


すべての関数がセキュリティリスクを招くという理由で廃止されたり、置き換えられたりするわけではありません。しかし多くの場合、廃止された関数があることは、その周辺のコードが無視されており、メンテナンスされていない状態であることを示します。ソフトウェアセキュリティは長い間、優先事項どころか検討事項ですらありませんでした。廃止予定または廃止済みの関数がプログラムで使用されていると、その周辺にセキュリティ上の問題がある可能性が浮上します。

プログラミング言語の進化に伴い、以下の理由でメソッドが廃止されることがあります。

- 言語の進歩
- 操作の効率的で安全な実行方法に関する
理解の向上
- 特定の操作について定めた規則の変更

ある言語から削除されたメソッドは通常、より優れていると思われる別の方法で同じタスクを実行する新しいメソッドに置き換えられます。
例 1: 次のコードは、各 16 ビット Unicode 文字の最初の 8 ビットを指定する値とバイトの配列からストリング オブジェクトを構築します。

...
String name = new String(nameBytes, highByte);
...

この例では、nameBytes で表される文字列のエンコードにどの文字セットが使用されているかによって、コンストラクターがバイトを文字に正しく変換できない可能性があります。文字列のエンコードに使用される文字セットの進化により、このコンストラクターは非推奨となり、パラメーターの 1 つとして、変換のためにバイトをエンコードするために使用される、charset という名前のパラメーターを受け入れるコンストラクターに置き換えられました。

すべての関数がセキュリティリスクを招くという理由で廃止されたり、置き換えられたりするわけではありません。しかし多くの場合、廃止された関数があることは、その周辺のコードが無視されており、メンテナンスされていない状態であることを示します。ソフトウェアセキュリティは長い間、優先事項どころか検討事項ですらありませんでした。廃止予定または廃止済みの関数がプログラムで使用されていると、その周辺にセキュリティ上の問題がある可能性が浮上します。

プログラミング言語の進化に伴い、以下の理由でメソッドが廃止されることがあります。

- 言語の進歩
- 操作の効率的で安全な実行方法に関する
理解の向上
- 特定の操作について定めた規則の変更

ある言語から削除されたメソッドは通常、より優れていると思われる別の方法で同じタスクを実行する新しいメソッドに置き換えられます。
例 1: 次のコードは Digest::HMAC stdlib を使用しています。これはリリース内に誤って含まれたために、ドキュメントで明示的に使用を禁止しています。

require 'digest/hmac'

hmac = Digest::HMAC.new("foo", Digest::RMD160)
...
hmac.update(buf)
...

この例の Digest::HMAC クラスは、リリース内に誤って含まれたため、追加直後に廃止されています。実験的で適切にテストされていないコードであり、期待どおりに動作しない可能性があるため、特に HMAC の暗号化機能に関する関係を考慮すると、この使用を避けることを強くお勧めします。

すべての関数がセキュリティリスクを招くという理由で廃止されたり、置き換えられたりするわけではありません。しかし多くの場合、廃止された関数があることは、その周辺のコードが無視されており、メンテナンスされていない状態であることを示します。ソフトウェアセキュリティは長い間、優先事項どころか検討事項ですらありませんでした。廃止予定または廃止済みの関数がプログラムで使用されていると、その周辺にセキュリティ上の問題がある可能性が浮上します。

通常、getlogin() 関数は、ターミナルで現在ログオン中のユーザー名を含む文字列を戻しますが、攻撃者は getlogin() を操作し、そのマシンにログオンした任意のユーザー名を戻すことができます。このため、セキュリティに関する決定を行う際に、getlogin() 関数によって戻された名前を信頼しないようにします。
例 1: 次のコードでは、getlogin() の結果を信頼し、信頼できるユーザーかどうかを判断しています。しかし、これは全く当てになりません。

 pwd = getpwnam(getlogin());
 if (isTrustedGroup(pwd->pw_gid)) {
 allow();
 } else {
 deny();
 }

多くの DNS サーバーが偽装攻撃にさらされているので、危険な状態の DNS サーバーの環境でソフトウェアが使用される可能性も想定してください。攻撃者が DNS を更新できる場合 (DNS キャッシュポイズニングとも呼ばれます)、攻撃者はネットワークトラフィックが自分のマシンを経由するようにしたり、攻撃者の IP アドレスが攻撃対象のドメインの一部であるかのように見せかけたりすることができます。システムのセキュリティが DNS 名に依存することがないようにしてください。
例 1: 次のコードは DNS ルックアップを使用して信頼できるホストからの着信リクエストかどうかを判断できます。攻撃者が DNS キャッシュをポイズニングできる場合、信頼できるというステータスを取得できます。

 String ip = request.getRemoteAddr();
 InetAddress addr = InetAddress.getByName(ip);
 if (addr.getCanonicalHostName().endsWith("trustme.com")) {
 trusted = true;
 }

IP アドレスは DNS 名よりは信頼できますが、偽装可能であることに変わりはありません。攻撃者は、送信するパケットのソース IP アドレスを容易に偽装できますが、レスポンス パケットは偽装された IP アドレスに戻されます。攻撃者はレスポンスパケットを参照するため、攻撃対象のマシンと偽装 IP アドレスの間のトラフィックを盗聴する必要があります。攻撃者は必要な盗聴を実行するため、攻撃対象のマシンと同じサブネットに入り込もうとします。攻撃者はソースルーティングを使用してこの要件を回避できる場合がありますが、今日ではインターネットでのソースルーティングは多くの場合、無効にされています。つまり、IP アドレス検証は Authentication 方式の有用な部分とすることができます。しかし、Authentication に必要な唯一の要素ではありません。

このエンコードメソッドにより挿入攻撃から保護されるように思えますが、このメソッドが正しく使用されないと、その保護効果が非常に低くなります。

例 1: 次のエンコードコールを指定すると、悪意のある JavaScript が挿入される可能性があります。

    out.println("x = " + encoder.encodeForJavaScript(input) + ";");

文字セットがオペレーティングシステムとオペレーティングシステム上のアプリケーションで一致していない場合、デフォルトの API メソッドに渡されたサポート対象外の文字を危険な文字にベストフィットマッピングすることができます。

例 1:Objective-C の場合、次の例は UTF-8 文字を含んだ NSString オブジェクトを ASCII データに変換し、その後戻します。

...
unichar ellipsis = 0x2026;
NSString *myString = [NSString stringWithFormat:@"My Test String%C", ellipsis];
NSData *asciiData = [myString dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
NSString *asciiString = [[NSString alloc] initWithData:asciiData encoding:NSASCIIStringEncoding];
NSLog(@"Original: %@ (length %d)", myString, [myString length]);
NSLog(@"Best-fit-mapped: %@ (length %d)", asciiString, [asciiString length]);
// output:
// Original: My Test String... (length 15)
// Best-fit-mapped: My Test String... (length 17)
...

出力を注意深く見ると、「...」という文字は 3 つの連続するピリオドに変換されています入力バッファに基づいて出力バッファのサイジングを行った場合、アプリケーションが Buffer Overflow に対して脆弱である可能性があります。その他の文字は、1 文字から 2 文字にマッピングすることができます。ギリシャ文字の「fi」という文字は、「f」と「i」にマッピングされます。攻撃者は、これらの文字を使用してバッファをフロントローディングすることによって、バッファをオーバーフローさせるのに使用される文字の数を完全に制御できます。

文字セットがオペレーティングシステムとオペレーティングシステム上のアプリケーションで一致していない場合、デフォルトの API メソッドに渡されたサポート対象外の文字を危険な文字にベストフィットマッピングすることができます。

例 1: Swift の場合、次の例は UTF-8 文字を含んだ NSString オブジェクトを ASCII データに変換し、その後戻します。

...
let ellipsis = 0x2026;
let myString = NSString(format:"My Test String %C", ellipsis)
let asciiData = myString.dataUsingEncoding(NSASCIIStringEncoding, allowLossyConversion:true)
let asciiString = NSString(data:asciiData!, encoding:NSASCIIStringEncoding)
NSLog("Original: %@ (length %d)", myString, myString.length)
NSLog("Best-fit-mapped: %@ (length %d)", asciiString!, asciiString!.length)

// output:
// Original: My Test String ... (length 16)
// Best-fit-mapped: My Test String ... (length 18)
...

出力を注意深く見ると、「...」という文字は 3 つの連続するピリオドに変換されています入力バッファに基づいて出力バッファのサイジングを行った場合、アプリケーションが Buffer Overflow に対して脆弱である可能性があります。その他の文字は、1 文字から 2 文字にマッピングすることができます。ギリシャ文字の「fi」という文字は、「f」と「i」にマッピングされます。攻撃者は、これらの文字を使用してバッファをフロントローディングすることによって、バッファをオーバーフローさせるのに使用される文字の数を完全に制御できます。

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。攻撃者が Web からのアクセスが可能なディレクトリにファイルをアップロードし、アップロードしたファイルをコードインタプリタ (JSP、ASPX、PHP など) に渡すことができる場合、これらのファイルに含まれている悪意あるコードがサーバーで実行される可能性があります。

例 1: 次の Spring MVC コントローラ クラスには、アップロードされたファイルの処理に使用可能なパラメーターがあります。

@Controller
public class MyFormController {
    ...
    @RequestMapping("/test")
    public String uploadFile (org.springframework.web.multipart.MultipartFile file) {
       ...
    }    ...
}

アップロードされたファイルが Web からアクセスできないディレクトリに保存された場合であっても、攻撃者はこの機能を利用してサーバー環境に悪意のあるコンテンツを持ち込み、その他の攻撃を仕掛ける可能性があります。プログラムが Path Manipulation、Command Injection、または Dangerous File Inclusion の脆弱性の危険にさらされている場合、攻撃者は悪意のあるコンテンツを含んだファイルをアップロードし、別の脆弱性を悪用することによってそのファイルをプログラムで読み取る、あるいは実行させる可能性があります。

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。攻撃者が Web からのアクセスが可能なディレクトリにファイルをアップロードし、アップロードしたファイルを PHP インタプリタに渡すことができる場合、これらのファイルに含まれている悪意あるコードがサーバーで実行される可能性があります。

例 1: 次のコードはアップロードされたファイルを処理し、処理したファイルを Web ルートの下のディレクトリに移動するものです。攻撃者は悪意ある PHP ソース ファイルをこのプログラムにアップロードし、続いてそれらのファイルをサーバーにリクエストします。その結果、それらのファイルは PHP インタープリターによって実行されます。

<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
    echo "Valid upload received\n";
} else {
    echo "Invalid upload rejected\n";
} ?>

アップロードされたファイルが Web からアクセスできないディレクトリに保存された場合であっても、攻撃者はこの機能を利用してサーバー環境に悪意のあるコンテンツを持ち込み、その他の攻撃を仕掛ける可能性があります。プログラムが Path Manipulation、Command Injection、またはリモートインクルードの脆弱性の危険にさらされている場合、攻撃者は悪意のあるコンテンツを含んだファイルをアップロードし、別の脆弱性を悪用することによってそのファイルをプログラムで読み取る、あるいは実行させる可能性があります。

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。攻撃者が Web からのアクセスが可能なディレクトリにファイルをアップロードし、アップロードしたファイルを Python インタプリタに渡すことができる場合、これらのファイルに含まれている悪意あるコードがサーバーで実行される可能性があります。

例 1: 次のコードはアップロードされたファイルを処理し、処理したファイルを Web ルートの下のディレクトリに移動するものです。攻撃者は悪意あるファイルをこのプログラムにアップロードし、続いてそれらのファイルをサーバーにリクエストします。

from django.core.files.storage import default_storage
from django.core.files.base import File
...
def handle_upload(request):
  files = request.FILES
  for f in files.values():
    path = default_storage.save('upload/', File(f))
...

アップロードされたファイルが Web からアクセスできないディレクトリに保存された場合であっても、攻撃者はこの機能を利用してサーバー環境に悪意のあるコンテンツを持ち込み、その他の攻撃を仕掛ける可能性があります。プログラムが Path Manipulation、Command Injection、またはリモートインクルードの脆弱性の危険にさらされている場合、攻撃者は悪意のあるコンテンツを含んだファイルをアップロードし、別の脆弱性を悪用することによってそのファイルをプログラムで読み取る、あるいは実行させる可能性があります。

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。一般ユーザーが実行可能なファイルが保存されるディレクトリに攻撃者がファイルをアップロードできる場合には、これらのファイルに悪意あるコードを追加して、サーバで実行する可能性があります。

アップロードされたファイルが一般ユーザーがアクセスできないディレクトリに保存された場合であっても、攻撃者はこの機能を利用してサーバー環境に悪意のあるコンテンツを持ち込み、その他の攻撃を仕掛ける可能性があります。プログラムが Path Manipulation、Command Injection、またはリモートインクルードの脆弱性の危険にさらされている場合、攻撃者は悪意のあるコンテンツを含んだファイルをアップロードし、別の脆弱性を悪用することによってそのファイルをプログラムで読み取る、あるいは実行させる可能性があります。

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。攻撃者が Web からのアクセスが可能なディレクトリにファイルをアップロードし、アップロードしたファイルをコードインタプリタ (JSP、ASPX、PHP など) に渡すことができる場合、これらのファイルに含まれている悪意あるコードがサーバーで実行される可能性があります。
アップロードされたファイルが Web からアクセスできないディレクトリに保存された場合であっても、攻撃者はこの機能を利用してサーバー環境に悪意のあるコンテンツを持ち込み、その他の攻撃を仕掛ける可能性があります。プログラムが Path Manipulation、Command Injection、または Dangerous File Inclusion の脆弱性の危険にさらされている場合、攻撃者は悪意のあるコンテンツを含んだファイルをアップロードし、別の脆弱性を悪用することによってそのファイルをプログラムで読み取る、あるいは実行させる可能性があります。

file タイプの <input> タグは、そのプログラムでファイルのアップロードが許可されていることを示します。
例 1:

<input type="file">

SMS 関連の操作は、アプリケーションのコア機能に必要でない限り実行しないでください。モバイル デバイス向けに作成されたマルウェアはしばしば、こうした機能を悪用してユーザーからお金やデータを盗みます。

例 1: 次のケースでは、アプリケーションは SMS メッセージを送信するか、SMS メッセージを事前作成して、送信するかキャンセルするかの判断を求めるメッセージをユーザーに提示します。

...
[[CTMessageCenter sharedMessageCenter] sendSMSWithText:@"Hello world!" serviceCenter:nil toAddress:@"+12345678910"];
...

// or

...
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"sms:+12345678910"]];
...

// or

...
MFMessageComposeViewController *messageComposerVC = [[MFMessageComposeViewController alloc] init];

[messageComposerVC setMessageComposeDelegate:self];
[messageComposerVC setBody:@"Hello World!"];
[messageComposerVC setRecipients:[NSArray arrayWithObject:@"+12345678910"]];

[self presentViewController:messageComposerVC animated:YES completion:nil];
...

SMS 関連の操作は、アプリケーションのコア機能に必要でない限り実行しないでください。モバイル デバイス向けに作成されたマルウェアはしばしば、こうした機能を悪用してユーザーからお金やデータを盗みます。

例 1: 次のケースでは、アプリケーションは SMS メッセージを送信するか、SMS メッセージを事前作成して、送信するかキャンセルするかの判断を求めるメッセージをユーザーに提示します。

...
UIApplication.sharedApplication().openURL(NSURL(string: "sms:+12345678910"))
...

または

...
let messageComposeVC = MFMessageComposeViewController()
messageComposeVC.messageComposeDelegate = self
messageComposeVC.body = "Hello World!"
messageComposeVC.recipients = ["+12345678910"]

presentViewController(messageComposeVC, animated: true, completion: nil)
...

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の ABAP コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターからパースされた URL を開くように命令しています。

...
DATA: str_dest TYPE c.

str_dest = request->get_form_field( 'dest' ).
response->redirect( str_dest ).
...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の ActionScript コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターから読み取られた URL を開くように命令しています。

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var strDest:String = String(params["dest"]);
        host.updateLocation(strDest);
        ...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトに使用される URL が未検証の入力によって制御されると、フィッシング攻撃を容易にしてしまう可能性があります。Web アプリケーションはリダイレクトにより、ユーザーが同一アプリケーション内の別のページまたは外部サイトにアクセスするよう方向付けます。アプリケーションでは、サイト ナビゲーションに役立てるためにリダイレクトが使用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。Open Redirect 脆弱性は、Web アプリケーションでクライアントがリダイレクトされる宛先が、攻撃者による制御が可能な任意の URL である場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の Visualforce アクション メソッドは、dest リクエスト パラメーターからの URL を含む PageReference オブジェクトを返します。

public PageReference pageAction() {
    ...
    PageReference ref = ApexPages.currentPage();
    Map<String,String> params = ref.getParameters();
    return new PageReference(params.get('dest'));
}

たとえば、攻撃対象のユーザーが "http://trusted.vf.force.com/apex/vfpage?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックするはずです。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザーは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが確実に既知の信頼できるサイトを指し示しているかどうか必ず調べるよう教えられています。しかし、攻撃者はリンク先の URL を次のようにエンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえも、だまされてリンクにアクセスしてしまうことがあります。

Web アプリケーションはリダイレクトにより、ユーザーが同一アプリケーション内の別のページまたは外部サイトにアクセスするよう方向付けます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。Open Redirect 脆弱性は、Web アプリケーションでクライアントがリダイレクトされる宛先が、攻撃者による制御が可能な任意の URL である場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の JSP コードでは、ユーザーのブラウザーに対し、ユーザーがリンクをクリックしたタイミングで、dest リクエスト パラメーターからパースされた URL を開くよう指示しています。

    ...
    final server = await HttpServer.bind(host, port);
      await for (HttpRequest request in server) {
        final response = request.response;
        final headers = request.headers;
        final strDest = headers.value('strDest');
        response.headers.contentType = ContentType.text;
        response.redirect(Uri.parse(strDest!));
        await response.close();
      }
    ...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが確実に既知の信頼できるサイトを指し示しているかどうか必ず調べるよう教えられています。しかし、攻撃者はリンク先の URL を次のように Hex エンコードする場合があります。
「http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D」

このような場合、知識の豊富なエンドユーザーでさえも、だまされてリンクにアクセスしてしまうことがあります。

Web アプリケーションはリダイレクトにより、ユーザーが同一アプリケーション内の別のページまたは外部サイトにアクセスするよう方向付けます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。Open Redirect 脆弱性は、Web アプリケーションでクライアントがリダイレクトされる宛先が、攻撃者による制御が可能な任意の URL である場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次のコードでは、ユーザーのブラウザーに対し、ユーザーがリンクをクリックしたタイミングで、dest リクエスト パラメーターからパースされた URL を開くよう指示しています。

    ...
    strDest := r.Form.Get("dest")
    http.Redirect(w, r, strDest, http.StatusSeeOther)
    ...

たとえば、攻撃対象のユーザーが「http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com」へのリンクをクリックするよう指示する電子メールを受信した場合、高い確率で、信頼されているサイトへ転送されるものと信じてこのリンクをクリックします。しかし、攻撃対象のユーザーがこのリンクをクリックすると、Example 1 のコードによって、ブラウザーは「http://www.wilyhacker.com」にリダイレクトされます。

多くのユーザーは、電子メールで受け取った URL のリンクが確実に既知の信頼できるサイトを指し示しているかどうか必ず調べるよう教えられています。しかし、攻撃者はリンク先の URL を次のように Hex エンコードする場合があります。
「http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D」

このような場合、知識の豊富なエンドユーザーでさえも、だまされてリンクにアクセスしてしまうことがあります。

Web アプリケーションはリダイレクトにより、ユーザーが同一アプリケーション内の別のページまたは外部サイトにアクセスするよう方向付けます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。Open Redirect 脆弱性は、Web アプリケーションでクライアントがリダイレクトされる宛先が、攻撃者による制御が可能な任意の URL である場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の Spring WebFlow フロー ステート定義は、ユーザーのブラウザーに対し、ユーザーがリンクをクリックしたタイミングで、dest リクエスト パラメーターからパースされた URL を開くよう指示しています。

    <end-state id="redirectView" view="externalRedirect:#{requestParameters.dest}" />

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが確実に既知の信頼できるサイトを指し示しているかどうか必ず調べるよう教えられています。しかし、攻撃者はリンク先の URL を次のように Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえも、だまされてリンクにアクセスしてしまうことがあります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の JavaScript コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエスト パラメーターから読み取られた URL を開くように命令しています。

	...
	strDest = form.dest.value;
	window.open(strDest,"myresults");
	...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の PHP コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターからパースされた URL を開くように命令しています。

    <%
        ...
        $strDest = $_GET["dest"];
        header("Location: " . $strDest);
        ...
    %>

たとえば、攻撃対象のユーザーが "http://trusted.example.com/ecommerce/redirect.php?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックするはずです。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.php?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次のプロシージャーはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターからパースされた URL を開くように命令しています。

      ...
      -- Assume QUERY_STRING looks like dest=http://www.wilyhacker.com
      dest := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 6);
      OWA_UTIL.redirect_url('dest');
      ...
  

たとえば、攻撃対象のユーザーが "http://trusted.example.com/pls/hr/showemps?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックするはずです。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/pls/hr/showemps?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の Python コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターからパースされた URL を開くように命令しています。

        ...
        strDest = request.field("dest")
        redirect(strDest)
        ...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の Ruby コードはユーザーのブラウザに対して dest リクエスト パラメーターからパースされた URL を開くように命令しています。

...
str_dest = req.params['dest']
...
res = Rack::Response.new
...
res.redirect("http://#{dest}")
...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次のプレイ コントローラー メソッドはユーザーのブラウザに対して dest リクエスト パラメーターからパースされた URL を開くように命令しています。

  def myAction = Action { implicit request =>
    ...
    request.getQueryString("dest") match {
      case Some(location) => Redirect(location)
      case None => Ok("No url found!")
    }
    ...
  }

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次のコードは、アプリケーションのカスタム URL スキームを使用するあらゆるリクエストを処理し、元の URL の "dest" パラメーター (ある場合) をポイントするように、および http:// スキームを使用して元の URL をポイントするように requestToLoad を設定し、さらにこのリクエストを WKWebView 内でロードします。

AppDelegate.swift:

...
let requestToLoad : String
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
  ...
  if let urlComponents = NSURLComponents(URL: url, resolvingAgainstBaseURL: false) {
    if let queryItems = urlComponents.queryItems as? [NSURLQueryItem]{
      for queryItem in queryItems {
        if queryItem.name == "dest" {
          if let value = queryItem.value {
            request = NSURLRequest(URL:NSURL(string:value))
            requestToLoad = request
            break
          }
        }
      }
    }
    if requestToLoad == nil {
        urlComponents.scheme = "http"
        requestToLoad = NSURLRequest(URL:urlComponents.URL)
    }
  }
  ...
}
...

ViewController.swift

...
let webView : WKWebView
let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
webView.loadRequest(appDelegate.requestToLoad)
...

被害者は、"custom_url_scheme://innocent_url?dest=www.wilyhacker.com" へのリンクに従うように指示する電子メールを受け取った場合、実行される動作に害は何もないと信じてそのリンクをクリックすることが考えられます。実際には、被害者がこのリンクをクリックすると、Example 1 のコードによって WKWebView で "http://www.wilyhacker.com" がリクエストおよびロードされます。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。

"custom_url_scheme://innocent_url?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の VB コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメータからパースされた URL を開くように命令しています。

	...
	strDest = Request.Form('dest')
	HyperLink.NavigateTo strDest
	...

たとえば、攻撃対象のユーザーが "http://www.trustedsite.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックするはずです。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://www.trustedsite.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードはプロパティ ファイルからパスワードを読み取り、そのパスワードを使用して URL リクエストのデフォルトの認証情報を設定しています。

...
var fs:FileStream = new FileStream();
fs.open(new File("config.properties"), FileMode.READ);
var password:String = fs.readMultiByte(fs.bytesAvailable, File.systemCharset);

URLRequestDefaults.setLoginCredentialsForHost(hostname, usr, password);
...

このコードは正常に動作しますが、config.properties にアクセスできる全員が passwordの値を読むことができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

アプリケーションの設定ファイルなどのデータストアにパスワードが平文で保管されるている場合、Password Management の問題が発生します。
例 1: 次のコードでは、レジストリからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

...
RegQueryValueEx(hkey,TEXT(.SQLPWD.),NULL,
                NULL,(LPBYTE)password, &size);
rc = SQLConnect(*hdbc, server, SQL_NTS, uid,
                SQL_NTS, password, SQL_NTS);
...

このコードは正常に動作しますが、パスワードの保存に使用されるレジストリ キーにアクセスできる全員が password の値を読み取ることができます。不心得な従業員がパスワード情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードはプロパティファイルからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

...
01  RECORD.
     05  UID              PIC X(10).
     05  PASSWORD         PIC X(10).
...
EXEC CICS
  READ
  FILE('CFG')
  INTO(RECORD)
  RIDFLD(ACCTNO)
  ...
END-EXEC.

EXEC SQL
  CONNECT :UID
  IDENTIFIED BY :PASSWORD
  AT :MYCONN
  USING :MYSERVER
END-EXEC.
...

このコードは正常に動作しますが、CFGにアクセスできる全員がパスワードの値を読むことができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

Password Management の問題が発生するのは、アプリケーションの設定ファイルやデータベースにパスワードが平文で保管されることが許可される場合です。
例 1: 次のコードは Web フォームからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

<cfquery name = "GetCredentials" dataSource = "master">
SELECT   Username, Password
FROM     Credentials
WHERE    DataSource="users"
</cfquery>
...
<cfquery name = "GetSSNs" dataSource = "users"
 username = "#Username#" password = "#Password#">
SELECT   SSN
FROM     Users
</cfquery>
...

このコードは正常に動作しますが、テーブル masterにアクセスできる全員が Username と Password の値を読み取ることができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードでは、JSON ファイルからパスワードを読み取り、そのパスワードを使用してリクエストの認証ヘッダーを設定します。

...
file, _ := os.Open("config.json")
decoder := json.NewDecoder(file)
decoder.Decode(&values)

request.SetBasicAuth(values.Username, values.Password)
...

このコードは正常に動作しますが、config.json にアクセスできる全員が values.Password の値を読み取ることができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードはプロパティファイルからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");

DriverManager.getConnection(url, usr, password);
...

このコードは正常に動作しますが、config.properties にアクセスできる全員が passwordの値を読むことができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

モバイル環境では、デバイスをなくす機会が高いことを考慮すると、パスワード管理は特に重要です。
例 2: 次のコードでは、Android WebView store からユーザー名とパスワードを読み取り、それらを使用して保護されたページを表示するための Authentication を設定します。

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
    String username = credentials[0];
    String password = credentials[1];
    handler.proceed(username, password);
  }
});
...

WebView 認証情報はデフォルトで平文として保存されハッシュされません。このためユーザーのデバイスがルート化されている (またはエミュレータを使用している) 場合、そのユーザーは保存されている特定サイトのパスワードを読み取ることができます。

アプリケーションにパスワードが平文で保管されている場合、Password Management の問題が発生します。
例 1: 次のコードは、ハードコーディングされたパスワードを使用してアプリケーションに接続し、アドレス帳のエントリを取得しています。

    ...
    obj = new XMLHttpRequest();
    obj.open('GET','/fetchusers.jsp?id='+form.id.value,'true','scott','tiger');
    ...

このコードは正常に実行されますが、含まれる Web ページにアクセスする全員がパスワードを閲覧できます。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードは、plist ファイルからパスワードを読み取り、読み取ったパスワードを使用してパスワードで保護されたファイルを解凍します。

...
NSDictionary *dict= [NSDictionary dictionaryWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"Config" ofType:@"plist"]];
NSString *password = [dict valueForKey:@"password"];
[SSZipArchive unzipFileAtPath:zipPath toDestination:destPath overwrite:TRUE password:password error:&error];
...

モバイル環境では、デバイスをなくす機会が高いことを考慮すると、パスワード管理は特に重要です。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードはプロパティファイルからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

...
$props = file('config.properties', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
$password = $props[0];

$link = mysql_connect($url, $usr, $password);
if (!$link) {
    die('Could not connect: ' . mysql_error());
}
...

このコードは正常に動作しますが、config.properties にアクセスできる全員が passwordの値を読むことができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。