ページのコンテンツを完全に制御できる場合を除き、ユーザーは悪意のある攻撃者が電話または FaceTime の自動呼び出しを開始するために使用するリンクをクリックできます。

たとえば、アプリケーションで、リンクを含むブログ記事やツイートを表示するとします。ユーザーがアクセスしている記事またはツイートの作成者は、それぞれのページの任意のリンクを使用できます。ユーザーが悪意のあるサイトを訪問し、だまされてまたは自動的に導かれてリンクをクリックした場合、攻撃者は FaceTime または電話の自動呼び出しを開始し、デバイスを数秒間ブロックしてユーザーが呼び出しをキャンセルできないようにする可能性があります。ランディング ページを制御する場合でも、ユーザーは最終的に別の信頼できないサイトにナビゲートされることがあります。

例 1: 次のコード スニペットは、webview を使用して信頼できないリンクを含む可能性のあるサイトをロードしますが、この webview で開始されたリクエストを検証できる委任は指定しません。

    ...
    let webUrl : NSURL = NSURL(string: "https://some.site.com/")!
    let webRequest : NSURLRequest = NSURLRequest(URL: webUrl)
    webView.loadRequest(webRequest)
    ...

ページのコンテンツを完全に制御できる場合を除き、ユーザーは悪意のある攻撃者が望ましくないアクションを開始するために使用するリンクをクリックできます。

たとえば、アプリケーションで、リンクを含むブログ記事やツイートを表示するとします。ユーザーがアクセスしている記事またはツイートの作成者は、それぞれのページの任意のリンクを使用できます。ユーザーが悪意のあるサイトを訪問し、だまされてまたは自動的に導かれてリンクをクリックした場合、特殊な URL スキームを使用して FaceTime または電話の呼び出しを開始したり、サード パーティ アプリケーションでデータを送信またはアクションを開始するなど、攻撃者は潜在的に危険なアクションを開始できます。ランディング ページを制御する場合でも、ユーザーは最終的に別の信頼できないサイトにナビゲートされることがあります。

例 1: 次のコード スニペットは、webview を使用して信頼できないリンクを含む可能性のあるサイトをロードしますが、この webview で開始されたリクエストを検証できる委任は指定しません。

    ...
    let webUrl = URL(string: "https://some.site.com/")!
    let urlRequest = URLRequest(url: webUrl)
    webView.load(webRequest)
    ...

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーション コードはリクエスト オブジェクトから値を読み込もうとします。その後、この値は記録されます。

...
DATA log_msg TYPE bal_s_msg.

val = request->get_form_field( 'val' ).

log_msg-msgid = 'XY'.
log_msg-msgty = 'E'.
log_msg-msgno = '123'.
log_msg-msgv1 = 'VAL: '.
log_msg-msgv2 = val.

CALL FUNCTION 'BAL_LOG_MSG_ADD'
  EXPORTING
    I_S_MSG          = log_msg
  EXCEPTIONS
    LOG_NOT_FOUND    = 1
    MSG_INCONSISTENT = 2
    LOG_IS_FULL      = 3
    OTHERS           = 4.
...

ユーザーが val として「FOO」という文字列を送信すると、以下のエントリが記録されます。

XY E 123 VAL: FOO

しかし、攻撃者が「FOO XY E 124 VAL: BAR」という文字列を送信すると、以下のエントリが記録されます。

XY E 123 VAL: FOO XY E 124 VAL: BAR

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var val:String = String(params["username"]);
var value:Number = parseInt(val);
if (value == Number.NaN) {
  trace("Failed to parse val = " + val);
}

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

Failed to parse val=twenty-one

しかし、攻撃者が「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

Failed to parse val=twenty-one

User logged out=badguy

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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

2.データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

...
string val = (string)Session["val"];
try {
int value = Int32.Parse(val);
}
catch (FormatException fe) {
log.Info("Failed to parse val= " + val);
}
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val=twenty-one

しかし、攻撃者が「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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

2. アプリケーションまたはシステムのログファイルに書き込まれたデータ。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの性質により異なりますが、ログファイルは必要に応じて手動で見直すことも、重要なデータポイントや傾向を検索するツールで自動的に選別することもできます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを与えることができる場合、ログファイルのチェックが妨害されたり、ログデータに基づく結論が誤っていたりすることがあります。ログエントリの区切り文字をデータに含めることにより、攻撃者が偽りの項目をログファイルに挿入するかもしれません。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者がコードやその他のコマンドをログファイルに挿入し、ログ処理ユーティリティの脆弱性を利用する可能性もあります [2]。

例 1: CGI スクリプトからの次のコードは、ユーザーによって送信された文字列を受け取り、long 整数値に変換しようと試みます。整数として値を解析できない場合は、何が起きたかを示すエラー メッセージとともに値が記録されます。

long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
	syslog(LOG_INFO,"Illegal value = %s",val);
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

Illegal value=twenty-one

しかし、攻撃者が「twenty-one\n\nINFO: User logged out=evil」という文字列を送信すると、以下のエントリが記録されます。

	INFO: Illegal value=twenty-one

	INFO: User logged out=evil

明らかに、攻撃者は同じ仕組みを利用して任意のログ エントリを挿入できます。このタイプの Log Forging 攻撃が有効性を持つには、攻撃者はまず有効なログエントリのフォーマットを識別する必要がありますが、多くの場合、これはターゲットアプリケーションにおける System Information Leak により可能になります。

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い、不正なエントリをログ ファイルに挿入する可能性があります。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりして、ファイルを使用できなくする可能性があります。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーション コードは HTML フォームから値を読み取ろうとします。その後、この値は記録されます。

...
01  LOGAREA.
     05  VALHEADER        PIC X(50) VALUE 'VAL: '.
     05  VAL              PIC X(50).
...

EXEC CICS
  WEB READ
  FORMFIELD(NAME)
  VALUE(VAL)
  ...
END-EXEC.

EXEC DLI
  LOG
  FROM(LOGAREA)
  LENGTH(50)
END-EXEC.
...

ユーザーが VAL として「FOO」という文字列を送信すると、以下のエントリが記録されます。

VAL: FOO

しかし、攻撃者が「FOO VAL: BAR」という文字列を送信すると、以下のエントリが記録されます。

VAL: FOO VAL: BAR

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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


2. データはアプリケーションまたはシステムログファイルに書き込まれます。


アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーション コードは Web フォームから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

<cflog file="app_log" application="No" Thread="No" 
       text="Failed to parse val="#Form.val#">

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

"Information",,"02/28/01","14:50:37",,"Failed to parse val=twenty-one"

しかし、攻撃者が「twenty-one%0a%0a%22Information%22%2C%2C%2202/28/01%22%2C%2214:53:40%22%2C%2C%22User%20logged%20out:%20badguy%22」という文字列を送信すると、以下のエントリが記録されます。

"Information",,"02/28/01","14:50:37",,"Failed to parse val=twenty-one"

"Information",,"02/28/01","14:53:40",,"User logged out: badguy"

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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

2.データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントの履歴をログファイルに保管したり、トランザクションを表示したりします。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

    func someHandler(w http.ResponseWriter, r *http.Request){
        r.parseForm()
        name := r.FormValue("name")
        logout := r.FormValue("logout")
        ...
        if (logout){
            ...
        } else {
            log.Printf("Attempt to log out: name: %s logout: %s", name, logout)
        }
    }

ユーザーが logout として「twenty-one」という文字列を送信すると、「admin」という名前のユーザーを作成でき、以下のエントリが記録されます。

Attempt to log out: name: admin logout: twenty-one

しかし、攻撃者が「admin+logout:+1+++++++++++++++++++++++」というユーザー名を作成できる場合、以下のエントリが記録されます。

Attempt to log out: name: admin logout: 1                       logout: twenty-one

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーション コードはリクエスト オブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

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

function listener(request, response){
  var val = url.parse(request.url, true)['query']['val'];
  if (isNaN(val)){
    console.log("INFO: Failed to parse val = " + val);
  }
  ...
}
...
http.createServer(listener).listen(8080);
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val = twenty-one

しかし、攻撃者が「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの性質により異なりますが、ログファイルは必要に応じて手動で見直すことも、重要なデータポイントや傾向を検索するツールで自動的に選別することもできます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを与えることができる場合、ログファイルのチェックが妨害されたり、ログデータに基づく結論が誤っていたりすることがあります。ログエントリの区切り文字をデータに含めることにより、攻撃者が偽りの項目をログファイルに挿入するかもしれません。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者がコードやその他のコマンドをログファイルに挿入し、ログ処理ユーティリティの脆弱性を利用する可能性もあります [2]。

例 1: CGI スクリプトからの次のコードは、ユーザーによって送信された文字列を受け取り、long 整数値に変換しようと試みます。整数として値を解析できない場合は、何が起きたかを示すエラーメッセージとともに値が記録されます。

long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
	NSLog("Illegal value = %s",val);
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

    INFO: Illegal value=twenty-one

しかし、攻撃者が「twenty-one\n\nINFO: User logged out=evil」という文字列を送信すると、以下のエントリが記録されます。

	INFO: Illegal value=twenty-one

	INFO: User logged out=evil

明らかに、攻撃者は同じ仕組みを利用して任意のログ エントリを挿入できます。このタイプのログ偽装攻撃が有効性を持つには、攻撃者はまず有効なログ エントリのフォーマットを識別する必要がありますが、多くの場合、これはターゲット アプリケーションにおけるシステム情報漏洩により可能になります。

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

<?php
    $name   =$_GET['name'];
    ...
    $logout =$_GET['logout'];

    if(is_numeric($logout))
    {
        ...
    }
    else
    {
        trigger_error("Attempt to log out: name: $name logout: $val");
    }
?>

ユーザーが logout として「twenty-one」という文字列を送信すると、「admin」という名前のユーザーを作成でき、以下のエントリが記録されます。

PHP Notice: Attempt to log out: name: admin logout: twenty-one

しかし、攻撃者が「admin+logout:+1+++++++++++++++++++++++」というユーザー名を作成できる場合、以下のエントリが記録されます。

PHP Notice: Attempt to log out: name: admin logout: 1                       logout: twenty-one

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

    name = req.field('name')
    ...
    logout = req.field('logout')

    if (logout):
        ...
    else:
        logger.error("Attempt to log out: name: %s logout: %s" % (name,logout))

ユーザーが logout として「twenty-one」という文字列を送信すると、「admin」という名前のユーザーを作成でき、以下のエントリが記録されます。

Attempt to log out: name: admin logout: twenty-one

しかし、攻撃者が「admin+logout:+1+++++++++++++++++++++++」というユーザー名を作成できる場合、以下のエントリが記録されます。

Attempt to log out: name: admin logout: 1                       logout: twenty-one

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

...
val = req['val']
unless val.respond_to?(:to_int)
  logger.info("Failed to parse val")
  logger.info(val)
end
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val
INFO: twenty-one

しかし、攻撃者が「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val
INFO: twenty-one

INFO: User logged out=badguy

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの性質により異なりますが、ログファイルは必要に応じて手動で見直すことも、重要なデータポイントや傾向を検索するツールで自動的に選別することもできます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを与えることができる場合、ログファイルのチェックが妨害されたり、ログデータに基づく結論が誤っていたりすることがあります。ログエントリの区切り文字をデータに含めることにより、攻撃者が偽りの項目をログファイルに挿入するかもしれません。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者がコードやその他のコマンドをログファイルに挿入し、ログ処理ユーティリティの脆弱性を利用する可能性もあります [2]。

例 1: 次のコードは、ユーザーによって送信された文字列を受け取り、整数値に変換しようと試みます。整数として値を解析できない場合は、何が起きたかを示すエラーメッセージとともに値が記録されます。

...
let num = Int(param)
if num == nil {
    NSLog("Illegal value = %@", param)
}
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

    INFO: Illegal value = twenty-one

しかし、攻撃者が「twenty-one\n\nINFO: User logged out=evil」という文字列を送信すると、以下のエントリが記録されます。

	INFO: Illegal value=twenty-one

	INFO: User logged out=evil

明らかに、攻撃者は同じ仕組みを利用して任意のログ エントリを挿入できます。このタイプのログ偽装攻撃が有効性を持つには、攻撃者はまず有効なログ エントリのフォーマットを識別する必要がありますが、多くの場合、これはターゲット アプリケーションにおけるシステム情報漏洩により可能になります。

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

...
Dim Val As Variant
Dim Value As Integer
Set Val = Request.Form("val")
If IsNumeric(Val) Then
	Set Value = Val
Else
	App.EventLog "Failed to parse val=" & Val, 1
End If
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

Failed to parse val=twenty-one

しかし、攻撃者が「twenty-one%0a%0a+User+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

Failed to parse val=twenty-one

User logged out=badguy

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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



2.データはアプリケーションまたはシステムログファイルに書き込まれます。



アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の REST エンドポイントは、リクエスト オブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

@HttpGet
global static void doGet() {
    RestRequest req = RestContext.request;
    String val = req.params.get('val');
    try {
        Integer i = Integer.valueOf(val);
        ...
    } catch (TypeException e) {
        System.Debug(LoggingLevel.INFO, 'Failed to parse val: '+val);
    }
}

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

Failed to parse val: twenty-one

しかし、攻撃者が「twenty-one%0a%0aUser+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

Failed to parse val: twenty-one

User logged out=badguy

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。 アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。 最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。 ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。 より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。 偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。 最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。 値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

  ...
          String val = request.Params["val"];
          try {
                  int value = Int.Parse(val);
          }
          catch (FormatException fe) {
                  log.Info("Failed to parse val = " + val);
          }
  ...
  

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

  INFO: Failed to parse val=twenty-one
  

しかし、攻撃者が「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

  INFO: Failed to parse val=twenty-one

  INFO: User logged out=badguy
  

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

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

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

  ...
          String val = this.Intent.Extras.GetString("val");
          try {
                  int value = Int.Parse(val);
          }
          catch (FormatException fe) {
                  Log.E(TAG, "Failed to parse val = " + val);
          }
  ...
  

次の場合に、Log Forging の脆弱性が発生します。

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

2.データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

...
    var idValue string

    idValue = req.URL.Query().Get("id")
    num, err := strconv.Atoi(idValue)

    if err != nil {
        sysLog.Debug("Failed to parse value: " + idValue)
    }
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val=twenty-one

しかし、攻撃者が「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy

明らかに、攻撃者はこれと同じメカニズムを使って任意のログエントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーション コードはリクエスト オブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

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

function listener(request, response){
  var val = url.parse(request.url, true)['query']['val'];
  if (isNaN(val)){
    console.error("INFO: Failed to parse val = " + val);
  }
  ...
}
...
http.createServer(listener).listen(8080);
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val=twenty-one

しかし、攻撃者が「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1:次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

...
val = request.GET["val"]
try:
  int_value = int(val)
except:
  logger.debug("Failed to parse val = " + val)
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val=twenty-one

しかし、攻撃者が「twenty-one%0a%0aINFO:+User+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

次の場合に、Log Forging の脆弱性が発生します。

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

2. データはアプリケーションまたはシステムログファイルに書き込まれます。

アプリケーションは通常、後でレビュー、統計情報収集、デバッグを行う場合に備え、イベントやトランザクションの履歴をログファイルに保管しています。アプリケーションの内容により、ログファイルをレビューするタスクは必要に応じて手動で実行するか、重要なイベントやトレンド情報のログを自動的に選び出すツールを使って自動的に実行できます。

後で逐語的に記録されるアプリケーションに攻撃者がデータを供給できる場合、ログファイルの解釈が妨害されたり誤っていたりすることがあります。最も害のない場合でも、攻撃者はアプリケーションに適切な文字が含まれる入力を行い不正なエントリをログファイルに挿入することができます。ログ ファイルが自動処理される場合、攻撃者はファイル形式を破損させたり、想定外の文字を挿入したりしてファイルを使用できなくすることができます。より巧妙な攻撃では、ログファイルの統計情報が歪曲されます。偽造などの方法でログファイルを不正にし、攻撃者の痕跡を覆い隠したり、悪意ある行為の実行に第三者を巻き込んだりすることができます [1]。最悪の場合、攻撃者はコードやその他のコマンドをログファイルに挿入してログ処理ユーティリティの脆弱性を利用することができます [2]。

例 1: 次の Web アプリケーションコードはリクエストオブジェクトから整数値を読み込もうとします。値が整数としてパースできない場合、入力はエラー内容を示すエラーメッセージと共に記録されます。

...
val = req['val']
unless val.respond_to?(:to_int)
  logger.debug("Failed to parse val")
  logger.debug(val)
end
...

ユーザーが val として「twenty-one」という文字列を送信すると、以下のエントリが記録されます。

DEBUG: Failed to parse val
DEBUG: twenty-one

しかし、攻撃者が「twenty-one%0a%DEBUG:+User+logged+out%3dbadguy」という文字列を送信すると、以下のエントリが記録されます。

DEBUG: Failed to parse val
DEBUG: twenty-one

DEBUG: User logged out=badguy

明らかに、攻撃者はこれと同じメカニズムを使って任意のログ エントリを挿入できます。

このようなタイプの脆弱性は、次の場合に発生する可能性があります。SMTP Command Injection の脆弱性は、攻撃者が SMTP メール サーバーに送信されるコマンドに影響を与える可能性がある場合に発生します。
1.信頼できないソースからアプリケーションにデータが入力された場合。

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

3.攻撃者は、SMTP コマンドを実行することで、スパムの送信などの悪意のあるアクションを実行するようにサーバーに指示できます。
例 1: 次のコードは、HTTP リクエスト パラメーターを使用して、SMTP サーバーに送信される VRFY コマンドを作成します。攻撃者はこのパラメーターを使用して、サーバーに送信されるコマンドを変更し、CRLF 文字を使用して新しいコマンドを挿入する可能性があります。

  ...
    c, err := smtp.Dial(x)
	if err != nil {
		log.Fatal(err)
	}
	user := request.FormValue("USER")
	c.Verify(user)
  ...
  

SMTP コマンド インジェクションの脆弱性は、攻撃者が SMTP メール サーバーに送信されるコマンドに影響を与えることができる場合に発生します。

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

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

3. SMTP コマンドを実行することで、攻撃者がサーバーに対してスパムの送信など悪意のあるアクションを実行するように指示できる場合。

例 1: The following code uses an HTTP request parameter to craft a VRFY command that is sent to the SMTP server.攻撃者はこのパラメーターを使用して、サーバーに送信されるコマンドを変更し、CRLF 文字を使用して新しいコマンドを挿入します。

...
user = request.GET['user']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
session.docmd("VRFY", user)
...

開発を容易にして生産性を高めるために、最も新しいフレームワークにより、オブジェクトが自動的にインスタンス化され、バインドするクラスの属性と名前が一致する HTTP リクエスト パラメーターが入力されます。自動インスタンス化およびオブジェクトの入力は開発速度を向上させますが、注意せずに実装した場合は深刻な問題を引き起こす可能性があります。バインド クラスまたはネスト化されたクラス内の属性は、自動的に HTTP リクエスト パラメーターにバインドされます。したがって、悪意のあるユーザーが、バインドまたはネスト化されたクラス内の任意の属性に (それらが Web フォームや API 契約を通してクライアントに開示されていない場合でも) 値を割り当てることができるようになります。

例 1: 追加構成なしで、次の ASP.NET MVC コントローラー メソッドが HTTP リクエスト パラメーターを RegisterModel または Details クラス内の属性にバインドします。

public ActionResult Register(RegisterModel model)
{
    if (ModelState.IsValid)
    {
        try
        {
            return RedirectToAction("Index", "Home");
        }
        catch (MembershipCreateUserException e)
        {
            ModelState.AddModelError("", "");
        }
    }
    return View(model);
}

ここで RegisterModel クラスは次のように定義されます。

public class RegisterModel
{
    [BindRequired]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [BindRequired]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    public string ConfirmPassword { get; set; }

    public Details Details { get; set; }

    public RegisterModel()
    {
        Details = new Details();
    }
}

また、Details クラスは次のように定義されます。

public class Details
{
    public bool IsAdmin { get; set; }
    ...
}

例 2:TryUpdateModel() または UpdateModel() を ASP.NET MVC または Web API アプリケーションで使用するとき、モデル バインダーはデフォルトで、自動的にすべての HTTP リクエスト パラメーターをバインドするように試みます。

public ViewResult Register()
{
    var model = new RegisterModel();
    TryUpdateModel<RegisterModel>(model);
    return View("detail", model);
}

例 3: ASP.NET Web Form アプリケーションでは、モデル バインダーは、IValueProvider インターフェイスで TryUpdateModel() または UpdateModel() を使用する際にすべての HTTP リクエスト パラメーターを自動的にバインドしようとします。

Employee emp = new Employee();
TryUpdateModel(emp, new System.Web.ModelBinding.FormValueProvider(ModelBindingExecutionContext)); 
if (ModelState.IsValid)
{
    db.SaveChanges();
}

また、Employee クラスは次のように定義されます。

 public class Employee
    {
        public Employee()
        {
            IsAdmin = false;
            IsManager = false;
        }
        public string Name { get; set; }
        public string Email { get; set; }
        public bool IsManager { get; set; }
        public bool IsAdmin { get; set; }
    }

モデルオブジェクトは、データベースエンティティをオブジェクト指向で表現したものです。これにより、関連するデータベースエンティティのロード、保存、更新、および削除が容易になります。
Hibernate、Microsoft .NET Entity Framework、および LINQ は、オブジェクトリレーショナルマッピング (ORM) フレームワークの例です。ORM フレームワークは、データベースを使用したモデルオブジェクトの構築に役立ちます。

多くの Web フレームワークは、モデルオブジェクトの属性名とリクエストパラメーター名の一致に基づいてリクエストバインドオブジェクトにリクエストパラメーターを、バインドする方法を提供することによって、開発を容易にしようと努力しています (一致する public の getter メソッドと setter メソッドに基づきます)。

アプリケーションで ORM クラスがリクエストバインドオブジェクトとして使用される場合、リクエストパラメーターによって、対応しているモデルオブジェクトの任意のフィールドやオブジェクト属性のネスト化されている任意のフィールドが変更される可能性が高くなります。

例 1:Order、Customer、および Profile は、Microsoft .NET Entity の永続的なクラスです。

public class Order {
	public string ordered { get; set; }
	public List<LineItem> LineItems { get; set; }
	pubilc virtual Customer Customer { get; set; }
...
}
public class Customer {
	public int CustomerId { get; set; }
	...
	public virtual Profile Profile { get; set; }
...
}
public class Profile {
	public int profileId { get; set; }
	public string username { get; set; }
	public string password { get; set; }
	...
}

OrderController は、リクエストを処理する ASP.NET MVC コントローラーのクラスです。

public class OrderController : Controller{
	StoreEntities db = new StoreEntities();
...

	public String updateOrder(Order order) {
		...
		db.Orders.Add(order);
		db.SaveChanges();
	}
}

モデル エンティティ クラスは、自動的にリクエストにバインドされるため、攻撃者は、この脆弱性を使用し、次のリクエスト パラメーターをこのリクエストに追加して、別のユーザーのパスワードを更新できます: "http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"

最近のフレームワークにより、開発者は、容易に開発し生産性を高めるために HTTP リクエスト パラメーターをリクエスト クエリーと本文の両方からモデル オブジェクトに自動的にバインドすることができます。バインダーで HTTP リクエスト パラメータとモデル属性のバインドの制御が適切に設定されていない場合、攻撃者によってモデル バインド プロセスが悪用され、ユーザー コントロールに開示してはいけない他の属性が設定されてしまう可能性があります。モデル属性が Web フォームまたは API コントラクトに表示されなくても、このバインドは可能です。

例 1: 次の ASP.NET MVC コントローラー メソッド (Register) が、ユーザーに名前とパスワードを入力してアカウントを登録することを求める Web フォームからアクセスされました。

public ActionResult Register(RegisterModel model)
{
    if (ModelState.IsValid)
    {
        try
        {
            return RedirectToAction("Index", "Home");
        }
        catch (MembershipCreateUserException e)
        {
            ModelState.AddModelError("", "");
        }
    }
    return View(model);
}

ここで RegisterModel クラスは次のように定義されます。

public class RegisterModel
{
    [BindRequired]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [BindRequired]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    public string ConfirmPassword { get; set; }

    public Details Details { get; set; }

    public RegisterModel()
    {
        Details = new Details();
    }
}

また、Details クラスは次のように定義されます。

public class Details
{
    public bool IsAdmin { get; set; }
    ...
}

Example 1 のシナリオの場合、攻撃者がアプリケーションを調べて、RegisterModel モデル内に Details 属性があることを発見する可能性があります。その場合、攻撃者が、属性に割り当てられた現在の値を上書きしようとする可能性があります。
攻撃者がこれらの内部属性をみつけ、フレームワーク バインダーがこれらの属性のバインドを許可しないように正しく設定されていない場合、攻撃者は次のリクエストを送信して、管理者アカウントを登録することができます。

name=John&password=****&details.is_admin=true

次の場合に Memcached Injection エラーが発生します。

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



2. データが Memcached の鍵または値の動的な構築に使用された場合。

例 1: 次のコードは Memcached 鍵を動的に構築します。

...
def store(request):
    id = request.GET['id']
    result = get_page_from_somewhere()
    response = HttpResponse(result)
    cache_time = 1800
    cache.set("req-" % id, response, cache_time)
    return response
...

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

set req-1233 0 0 n
<serialized_response_instance>

ただし、この操作は定数の鍵プレフィックスとユーザー入力の文字列を連結して動的に構築されるため、攻撃者は文字列 ignore 0 0 1\r\n1\r\nset injected 0 3600 10\r\n0123456789\r\nset req- を送信できます。その後、操作は次のようになります。

set req-ignore 0 0 1
1
set injected 0 3600 10
0123456789
set req-1233 0 0 n
<serialized_response_instance>

上記の鍵はキャッシュ injected=0123456789 に鍵と値の新しいペアを追加します。ペイロードにもよりますが、攻撃者はキャッシュをポイズニングしたり、Pickle でシリアライズしたペイロードを挿入し、デシリアライゼーションのときに任意にコードを実行したりできます。

メモリ リークには、2 つの共通する、時には重複する原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がメモリを解放するかに関する混乱。

ほとんどのメモリ リークは、ソフトウェアの全般的な信頼性の問題を引き起こしますが、攻撃者による意図的なリソース リークが可能な場合、攻撃者は Denial of Service 攻撃を起こす (プログラムをクラッシュすることで) か、低メモリの状況の結果として起きるプログラムによるその他の想定外の振る舞いを悪用することができる可能性があります [1]。

例 1: 以下の Micro Focus COBOL プログラムは、エラーが発生した場合に、割り当て済みのメモリのブロックをリークします。

  CALL "CBL_ALLOC_MEM"
      USING mem-pointer
      BY VALUE mem-size
      BY VALUE flags
      RETURNING status-code
  END-CALL

  IF status-code NOT = 0
      DISPLAY "Error!"
      GOBACK
  ELSE
      SET ADDRESS OF mem TO mem-pointer
  END-IF

  PERFORM write-data
  IF ws-status-code NOT = 0
      DISPLAY "Error!"
      GOBACK
  ELSE
      DISPLAY "Success!"
  END-IF

  CALL "CBL_FREE_MEM"
      USING BY VALUE mem-pointer
      RETURNING status-code
  END-CALL

  GOBACK
  .

Memory Leak には 2 つの一般的な原因があり、これらが重なっていることもあります。

- エラー条件などの例外的状況。

- プログラムのどの部分でメモリを解放するかに関して混乱が発生している。

大部分の Memory Leak は一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者が意図的に Memory Leak を引き起こせる場合、攻撃者は (プログラムをクラッシュさせて) Denial of Service 攻撃を仕掛けたり、メモリ不足により引き起こされるプログラムの予測不能な動作を利用したりすることができます [1]。

例 1: Objective-C オブジェクトは、init() メソッドでメモリを割り当てますが、deallocate() メソッドでメモリの解放に失敗するため、Memory Leak が発生します。

- (void)init
{
    myVar = [NSString alloc] init];
    ...
}

- (void)dealloc
{
    [otherVar release];
}

メモリ リークには、2 つの共通する、時には重複する原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がメモリを解放するかに関する混乱。

ほとんどのメモリ リークは、ソフトウェアの全般的な信頼性の問題を引き起こしますが、攻撃者による意図的なリソース リークが可能な場合、攻撃者は Denial of Service 攻撃を起こす (プログラムをクラッシュすることで) か、低メモリの状況の結果として起きるプログラムによるその他の想定外の振る舞いを悪用することができる可能性があります [1]。

例 1: 以下の Micro Focus COBOL プログラムは、realloc() の呼び出しが元の割り当てのサイズ変更に失敗した場合に、割り当て済みメモリのブロックをリークします。

CALL "malloc" USING
    BY VALUE mem-size
    RETURNING mem-pointer
END-CALL

ADD 1000 TO mem-size

CALL "realloc" USING
    BY VALUE mem-pointer
    BY VALUE mem-size
    RETURNING mem-pointer
END-CALL

IF mem-pointer <> null
    CALL "free" USING
        BY VALUE mem-pointer
    END-CALL
END-IF

ソフトウェアシステムに対する重大な攻撃は、ほぼすべて、プログラマにとって想定外の事態から始まります。実際に攻撃を受けた後にはプログラマの仮定は脆弱で根拠薄弱に思われます。しかし、攻撃以前は多くのプログラマがその仮定を情熱的に弁護するものです。

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「この関数コールは決して失敗しない」、および「この関数コールが失敗するかどうかは重要ではない」です。プログラマが関数の戻り値を無視しているのであれば、それはいずれかの仮定に基づいて作業していると暗黙のうちに認めていることを意味します。
例 1: 次のコードは、Item プロパティによって戻される文字列が null かどうかを、メンバー関数 Equals() をコールする前にチェックしないので、null Dereference の原因になる可能性があります。

string itemName = request.Item(ITEM_NAME);
	if (itemName.Equals(IMPORTANT_ITEM)) {
		...
	}
	...

このコーディングエラーに対しては通常、次のような弁解がなされます。

「これこれの理由で、リクエストされた値が常に存在することはわかっています。値が存在しなければプログラムは目的の動作を実行できないので、エラーをプログラマが処理しても、null 値を間接参照してプログラムが異常終了するのにまかせても同じことです。」

しかし攻撃者は、特に例外に関しては、プログラム内にある想定外のパスを巧妙に見つけ出します。

ソフトウェアシステムに対する重大な攻撃は、ほぼすべて、プログラマにとって想定外の事態から始まります。実際に攻撃を受けた後にはプログラマの仮定は脆弱で根拠薄弱に思われます。しかし、攻撃以前は多くのプログラマがその仮定を情熱的に弁護するものです。

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「この関数コールは決して失敗しない」、および「この関数コールが失敗するかどうかは重要ではない」です。プログラマが関数の戻り値を無視しているのであれば、それはいずれかの仮定に基づいて作業していると暗黙のうちに認めていることを意味します。
例 1: 次のコードでは、malloc() で戻されたポインタを使用する前に、メモリの割り当てが正しく行われたかチェックしていません。

    buf = (char*) malloc(req_size);
    strncpy(buf, xfer, req_size);

このコーディングエラーに対しては通常、次のような弁解がなされます。

「記述したプログラムでメモリ不足になったら、プログラムの実行に失敗するだろう。エラー処理をするか、NULL ポインタへの間接参照を試行して単にプログラムをセグメンテーション違反で異常終了させるかは、さほど重要な問題ではない。」

この主張では、次の重要な 3 つの問題点を考慮していません。

- アプリケーションのタイプとサイズによっては、他の場所で使用中のメモリを解放してプログラムの実行を継続できる可能性もあります。

- 必要な場合にプログラムが安全な終了を実行するのは不可能です。プログラムが自動操作を実行すると、システムは不整合な状態になる可能性があります。

- プログラマは、診断データを記録する機会を失います。malloc() のコールが失敗に終わった理由が、req_size の超過によるものか、許容範囲外の同時処理によるものか定かではありません。時間の経過とともに蓄積された Memory Leak によるものかも不明です。エラー処理を怠ると、原因を究明する術はありません。