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 のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
...
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 のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。inputID 値は事前定義されたリストから取得されていて、バインド変数は SOQL/SOSL Injection を防止するのに役立ちます。
...
result = [SELECT Name, Phone FROM Contact WHERE (IsDeleted = false AND Id=:inputID)];
...
inputID の値の変更を防止するには不十分なことです。攻撃者がインターフェイスをバイパスし、別の値を使用してリクエストを送信できる場合は、他の連絡先情報にアクセスできてしまいます。この例のコードの場合、リクエストされた連絡先へのアクセス権限がユーザーにあるか確認しないため、ユーザーがこの連絡先を表示する権限がない場合でも、すべての連絡先が表示されます。
...
int16 id = System.Convert.ToInt16(invoiceID.Text);
var invoice = OrderSystem.getInvoices()
.Where(new Invoice { invoiceID = id });
...
id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
...
CMyRecordset rs(&dbms);
rs.PrepareSQL("SELECT * FROM invoices WHERE id = ?");
rs.SetParam_int(0,atoi(r.Lookup("invoiceID").c_str()));
rs.SafeExecuteSQL();
...
id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
...
ACCEPT ID.
EXEC SQL
DECLARE C1 CURSOR FOR
SELECT INVNO, INVDATE, INVTOTAL
FROM INVOICES
WHERE INVOICEID = :ID
END-EXEC.
...
ID に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。deleteDatabase メソッドを実行すると、攻撃者がデータベースを削除できる可能性があります。
...
id := request.FormValue("invoiceID")
query := "SELECT * FROM invoices WHERE id = ?";
rows, err := db.Query(query, id)
...
id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
...
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 のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。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});
...
...
var id = document.form.invoiceID.value;
var query = "SELECT * FROM invoices WHERE id = ?";
db.transaction(function (tx) {
tx.executeSql(query,[id]);
}
)
...
id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
...
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 のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
...
$id = $_POST['id'];
$query = "SELECT * FROM invoices WHERE id = ?";
$stmt = $mysqli->prepare($query);
$stmt->bind_param('ss',$id);
$stmt->execute();
...
id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
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 のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
...
id = request.POST['id']
c = db.cursor()
stmt = c.execute("SELECT * FROM invoices WHERE id = %s", (id,))
...
id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
...
id = req['invoiceID'].respond_to(:to_int)
query = "SELECT * FROM invoices WHERE id=?"
stmt = conn.prepare(query)
stmt.execute(id)
...
id に可能なすべての値を検討しきれていないことです。現在のユーザーに属する領収書 ID のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
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 のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
...
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 のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。
...
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 のリストがインターフェイスにより生成されますが、攻撃者はこのインターフェイスを回避して目的の領収書をリクエストする可能性があります。この例のコードの場合、リクエストされた領収書へのアクセス権限をユーザーが確保しているか確認しないため、現在のユーザーに帰属していなくても、リクエストされたとおりの領収書を表示します。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 の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。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\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。/var/yp ディレクトリでの make コマンドの実行が含まれます。
...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...
CALL 'SYSTEM' のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。
...
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 の内容を変更することにより、攻撃者はアプリケーションの任意のコマンドを高い権限で実行できます。このプログラムではファイルから読み取った値の検証が実行されないため、攻撃者がこの値を制御できる場合、アプリケーションを操って悪意のあるコードを実行し、システムを制御できます。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\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。/var/yp ディレクトリでの make コマンドの実行が含まれます。
...
fscommand("exec", "make");
...
fscommand() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。
...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...
Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。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\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。update.exe コマンドの実行が含まれます。
...
Process.Start("update.exe");
...
Process.start() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、update.exe という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の update.exe もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。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 パーティションの内容を回帰的に削除してしまいます。$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 の悪意ある改変版が置かれた別のパスを指定することができます。プログラムでは環境から読み取った値を検証しないため、攻撃者は環境変数を制御することでアプリケーションを操って悪意あるコードを実行させることができます。/var/yp ディレクトリでの make の実行も含まれます。プログラムはパスワードレコードも更新するので setuid root にインストールされている、ということに注意してください。make を呼び出します。
system("cd /var/yp && make &> /dev/null");
system() に渡される引数を制御できません。ただし、プログラムでは make の絶対パスが指定されておらず、コマンドを呼び出す前にすべての環境変数がチェックされません。このため、攻撃者は $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、シェル プロンプトから CGI スクリプトを実行させることができます。また、プログラムが setuid root にインストールされているため、攻撃者の make は root 権限で実行されます。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() といった関数は、自身をコールするプログラムの環境を使用するため、攻撃者はそれらのコールの動作を変更できる可能性があります。$PATH やその他の要素を変えることで、攻撃者がプログラムを利用して悪意のあるバイナリを実行することが可能になる場合があります。/var/yp ディレクトリでの make の実行も含まれます。プログラムはパスワード レコードを更新するため、setuid root にインストールされていることに注意してください。make を次のように呼び出します。
MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
length of command-line
run-unit-id
stack-size
flags
CBL_EXEC_RUN_UNIT に渡す引数を制御できません。しかしプログラムは make の絶対パスを指定せず、コマンド呼出しの前に環境変数をスクラブしないため、攻撃者は $PATH 変数が make という名前の悪意のあるバイナリをポイントするように変更して、シェル プロンプトから CGI スクリプトを実行できます。さらに、プログラムは setuid root にインストールされているため、攻撃者バージョンの make は root 権限で実行されるようになります。pdfprint コマンドを使用して印刷するファイルを含む一時ディレクトリを決定します。
DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
ws-temp-dir DELIMITED SPACE
"/" DELIMITED SIZE
ws-pdf-filename DELIMITED SPACE
x"00" DELIMITED SIZE
INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer
pdfprint の絶対パスを指定しないため、攻撃者は $PATH 変数が悪意のあるバイナリをポイントするように変更できます。さらに、DELIMITED SPACE フレーズが ws-temp-dir および ws-pdf-filename における埋め込みスペースを防止する一方で、シェル メタ文字 (&& など) が埋め込まれている可能性もあります。cmd リクエストパラメーターを介して任意のコマンドを指定できてしまいます。
...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
arguments = "/c #var#"
timeout = "1"
variable="mycmd">
</cfexecute>
...
APPHOME を使用してインストール先ディレクトリを特定し、指定されたディレクトリからの相対パスに基づいて初期化スクリプトを実行します。
...
final cmd = String.fromEnvironment('APPHOME');
await Process.run(cmd);
...
Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。
cmdName := request.FormValue("Command")
c := exec.Command(cmdName)
c.Run()
APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。
...
String home = System.getProperty("APPHOME");
String cmd = home + INITCMD;
java.lang.Runtime.getRuntime().exec(cmd);
...
Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。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\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。/var/yp ディレクトリでの make コマンドの実行が含まれます。
...
System.Runtime.getRuntime().exec("make");
...
Runtime.exec() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。
...
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();
...
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 の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。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パラメーターを、その存在を除いて検証しないことです。シェルが呼び出されると、複数のコマンドの実行が許可され、アプリケーションの特性により、データベースとの対話に必要な権限を使用して実行されるので、攻撃者が挿入する任意のコマンドもそれらの権限を使用して実行されることになります。/var/yp ディレクトリでの make コマンドの実行が含まれます。
...
require('child_process').exec("make", function(error, stdout, stderr){
...
});
...
make の絶対パスを指定しておらず、child_process.exec() の呼び出しを実行する前に環境をクリーニングできないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。
...
$home = $_ENV['APPHOME'];
$cmd = $home . $INITCMD;
system(cmd);
...
Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。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\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。/var/yp ディレクトリでの make コマンドの実行が含まれます。
...
$result = shell_exec("make");
...
Runtime.exec() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。
...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS
DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path
exec xp_cmdshell @cmd
GO
...
APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。
...
home = os.getenv('APPHOME')
cmd = home.join(INITCMD)
os.system(cmd);
...
Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。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\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。/var/yp ディレクトリでの make コマンドの実行が含まれます。
...
result = os.system("make");
...
os.system() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。
...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...
Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。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\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。/var/yp ディレクトリでの make コマンドの実行が含まれます。
...
system("make")
...
Kernel.system() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。
def changePassword(username: String, password: String) = Action { request =>
...
s'echo "${password}" | passwd ${username} --stdin'.!
...
}
APPHOME を使用してインストール先ディレクトリが決定され、指定されたディレクトリからの相対パスに基づいて初期化スクリプトが実行されます。
...
Dim cmd
Dim home
home = Environ$("AppHome")
cmd = home & initCmd
Shell cmd, vbNormalFocus
...
Example 1 のコードでは、悪意ある INITCMD を含んだ別のパスを参照するようにシステムプロパティ APPHOME を変更することにより、攻撃者はアプリケーションの任意のコマンドを昇格した権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、システムプロパティ APPHOME の値を制御できれば、攻撃者はアプリケーションを操作して悪意のあるコードを実行させ、システムを支配下に置くことができます。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\\*.*" という形式の文字列を渡すと、アプリケーションは、プログラムにより指定された他のコマンドとともにこのコマンドを実行します。アプリケーションはその性質上、データベースとのやり取りに必要な権限で実行されています。このため、攻撃者が挿入したコマンドも、その権限で実行されます。/var/yp ディレクトリでの make コマンドの実行が含まれます。
...
$result = shell_exec("make");
...
Runtime.exec() のコールを実行する前に環境をクリーンにできていないことです。攻撃者が $PATH 変数を変更して、make という名前の悪意あるバイナリを参照させ、攻撃者の環境でプログラムが実行されるようにすると、本来のバイナリでなく悪意あるバイナリがロードされます。アプリケーションの性質上、このバイナリはシステム操作の実行に必要な権限で実行されます。つまり、攻撃者の make もその権限で実行されるため、攻撃者がシステムを完全に制御してしまう可能性があります。isSecure パラメーターを true に設定しないで作成されます。Secure フラグをサポートします。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークがスニッフィングされる可能性がありますが、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。isSecure パラメーターを true に設定せずに cookie が作成されています。
...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...
isSecure パラメーターが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はそれ以降の HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックをスニッフィングするのは攻撃者にとって簡単です。また、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。Secure フラグが true に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。Secure プロパティを設定せずにレスポンスに cookie が追加されています。
...
HttpCookie cookie = new HttpCookie("emailCookie", email);
Response.AppendCookie(cookie);
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。Secure フラグを true に設定せずに cookie を作成します。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報またはセッション ID が保存されている場合や、cookie によって CSRF トークンが送信される場合、特に重要です。Secure フラグを設定せずに cookie がレスポンスに追加されています。
cookie := http.Cookie{
Name: "emailCookie",
Value: email,
}
http.SetCookie(response, &cookie)
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックをスニッフィングすることによって cookie を危険にさらすことがあります。特に無線ネットワークの場合、ネットワーク トラフィックのスニッフィングは非常に簡単です。Secure フラグが true に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。use-secure-cookie 属性によって remember-me cookie が有効化され、暗号化されていない転送によって送信されます。
<http auto-config="true">
...
<remember-me use-secure-cookie="false"/>
</http>
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。Secure フラグが true に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。Secure プロパティを true に設定せずにレスポンスに cookie が追加されています。
res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。NSHTTPCookieSecure フラグが TRUE に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。Secure フラグを設定せずにレスポンスに cookie が追加されています。
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッションIDが格納されているcookie)をHTTP経由で送信すると、アプリケーションが危険にさらされる可能性があります。Secure フラグを true に設定せずに cookie を作成します。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合に特に重要になります。Secure フラグを設定せずに cookie がレスポンスに追加されています。
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックを盗聴することによって cookie を入手できます。特に無線ネットワークの場合はネットワーク トラフィックを盗聴することは非常に簡単です。Secure フラグを True に設定せずに cookie を作成します。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。cookie に個人情報またはセッション ID が保存されている場合や、cookie によって CSRF トークンが送信される場合に特に重要になります。Secure フラグを設定せずに cookie がレスポンスに追加されています。
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("emailCookie", email)
return res
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。すると攻撃者は、暗号化されていないネットワーク トラフィックを盗聴することによって cookie を入手できます。特に無線ネットワークの場合はネットワーク トラフィックを盗聴することは非常に簡単です。Secure フラグが true に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。Secure フラグを設定せずにレスポンスに cookie が追加されています。
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。NSHTTPCookieSecure フラグが TRUE に設定されていない cookie が作成されます。Secure フラグがサポートされています。このフラグが設定されていると、ブラウザーは HTTPS 経由でのみ cookie を送信します。暗号化されていないチャネルで cookie を送信すると、ネットワークが盗聴される可能性があります。したがって、secure フラグを使用することで cookie の値の機密性を保護できます。これは、cookie に個人情報が保存されている場合や、cookie によってセッション ID が送信される場合、特に重要になります。Secure フラグを設定せずにレスポンスに cookie が追加されています。
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
Secure フラグが設定されていないアプリケーションでは、HTTPS リクエストで送信された cookie はその後に続く HTTP リクエストでも送信されてしまいます。暗号化されていない無線接続でネットワークトラフィックを盗聴するのは攻撃者にとって簡単です。つまり、cookie (特にセッション ID が格納されている cookie) を HTTP 経由で送信すると、アプリケーションが危険にさらされる可能性があります。HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
HttpCookie cookie = new HttpCookie("emailCookie", email);
Response.AppendCookie(cookie);
HttpOnly フラグを true に設定していません。HttpOnly を設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie へアクセスします。HttpOnly を有効にしないと、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
cookie := http.Cookie{
Name: "emailCookie",
Value: email,
}
...
HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
javax.servlet.http.Cookie cookie = new javax.servlet.http.Cookie("emailCookie", email);
// Missing a call to: cookie.setHttpOnly(true);
HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。httpOnly プロパティが設定されずに cookie が作成されています。
res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});
HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE); //Missing 7th parameter to set HttpOnly
HttpOnly フラグを True に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("emailCookie", email)
return res
...
HttpOnly フラグを true に設定していません。HttpOnly cookie プロパティを設定すると、クライアント側のスクリプトが cookie にアクセスすることを防止できます。 Cross-Site Scripting 攻撃では多くの場合、セッション ID や Authentication トークンを盗み出すために cookie にアクセスします。 HttpOnly が有効に設定されていない場合、攻撃者は容易にユーザーの cookie にアクセスできます。HttpOnly プロパティが設定されずに cookie が作成されています。
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, httpOnly = false))
.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Domain = ".example.com";
http://insecure.example.com/ に配置されていて、このアプリケーションにクロスサイト スクリプティングの脆弱性が存在するとします。 http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://secure.example.com/ に安全なアプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが「.example.com」であるセッション ID の cookie が設定されます。
cookie := http.Cookie{
Name: "sessionID",
Value: getSessionID(),
Domain: ".example.com",
}
...
http://insecure.example.com/ に配置されていて、このアプリケーションにクロスサイト スクリプティングの脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。insecure.example.com を使用して、パスがあまりに広範にわたっている cookie を独自に作成し、Secure.example.com からの cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。
Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setDomain(".example.com");
http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。
cookie_options = {};
cookie_options.domain = '.example.com';
...
res.cookie('important_cookie', info, cookie_options);
http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。
setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);
http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
return res
...
http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, domain = Some(".example.com")))
http://insecure.example.com/ に配置されていて、このアプリケーションにCross-site Scriptingの脆弱性が存在するとします。 http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。.example.com" などのベース ドメインにわたってアクティブになるように cookie を設定する傾向にあります。 この方法では同じベースドメインおよびサブドメイン上にあるすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://secure.example.com/ に安全なアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがログインすると、ドメインが ".example.com" であるセッション ID の cookie が設定されます。
...
let properties = [
NSHTTPCookieDomain: ".example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
http://insecure.example.com/ に配置されていて、このアプリケーションに Cross-Site Scripting の脆弱性が存在するとします。http://secure.example.com に認証されているユーザーが http://insecure.example.com にアクセスすると、http://secure.example.com から送信されるセッション cookie が漏洩する可能性があります。insecure.example.com を使用してパスが広範にわたる cookie を独自に作成し、secure.example.com から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。例：
...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...
http://communitypages.example.com/EvilSite に別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスしたフォーラム ユーザーのアカウントであれば、危険にさらされることがあります。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/" に設定する傾向にありますが、この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Path = "/";
http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置していると考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、「/」というパスを持つセッション ID の cookie が設定されます。
cookie := http.Cookie{
Name: "sessionID",
Value: sID,
Expires: time.Now().AddDate(0, 0, 1),
Path: "/",
}
...
http://communitypages.example.com/EvilSite に別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。フォーラム ユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションへ送信します。攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスしたフォーラム ユーザーのアカウントであれば、危険にさらされることがあります。/EvilSite を使用して、パスがあまりに広範にわたっている cookie を独自に作成し、/MyForum からの cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://communitypages.example.com/MyForum にフォーラムアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。
Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setPath("/");
http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。
cookie_options = {};
cookie_options.path = '/';
...
res.cookie('important_cookie', info, cookie_options);
http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://communitypages.example.com/MyForum にフォーラムアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://communitypages.example.com/MyForum にフォーラムアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。
setcookie("mySessionId", getSessionID(), 0, "/", "communitypages.example.com", true, true);
http://communitypages.example.com/EvilSite に別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("sessionid", value) # Path defaults to "/"
return res
...
http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://communitypages.example.com/MyForum にフォーラム アプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))
http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。/") からアクセスできるように設定する傾向にあります。 この方法ではドメイン名を同じくするすべての Web アプリケーションがその cookie にアクセスできてしまいます。 cookie にはセッション ID などの重要な情報が保存されていることが多いため、アプリケーション間で cookie を共有すると、1 個のアプリケーションの脆弱性が別のアプリケーションに影響を及ぼす可能性があります。http://communitypages.example.com/MyForum にフォーラムアプリケーションを配置している例を考えてみましょう。このアプリケーションでは、ユーザーがフォーラムにログインすると、"/" というパスを持つセッション ID の cookie が設定されます。
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
http://communitypages.example.com/EvilSiteに別のアプリケーションを作成し、このサイトへのリンクをフォーラムに掲載したとします。 フォーラムのユーザーがこのリンクをクリックすると、ユーザーのブラウザーは /MyForum によって設定された cookie を /EvilSite で実行されているアプリケーションに送信することになります。 攻撃者はセッション ID を盗むことにより、/EvilSite にアクセスした任意のフォーラム ユーザーのアカウントを乗っ取ることができます。/EvilSite を使用してパスが広範にわたる cookie を独自に作成し、/MyForum から送信される cookie を上書きします。
...
Integer maxAge = 60*60*24*365*10;
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, true, 'Strict');
...
HttpCookie cookie = new HttpCookie("emailCookie", email);
cookie.Expires = DateTime.Now.AddYears(10);;
Cookie cookie = new Cookie("emailCookie", email);
cookie.setMaxAge(60*60*24*365*10);
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:[[NSDate date] dateByAddingTimeInterval:(60*60*24*365*10)] forKey:NSHTTPCookieExpires];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
setcookie("emailCookie", $email, time()+60*60*24*365*10);
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("emailCookie", email, expires=time()+60*60*24*365*10, secure=True, httponly=True)
return res
...
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, maxAge = Some(60*60*24*365*10)))
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true,
NSHTTPCookieExpires : NSDate(timeIntervalSinceNow: (60*60*24*365*10))
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
MyAccountActions とページ アクション メソッド pageAction() を宣言しています。ページの URL にアクセスすると、pageAction() メソッドが実行され、サーバーは CSRF 防止トークンをチェックしません。
<apex:page controller="MyAccountActions" action="{!pageAction}">
...
</apex:page>
public class MyAccountActions {
...
public void pageAction() {
Map<String,String> reqParams = ApexPages.currentPage().getParameters();
if (params.containsKey('id')) {
Id id = reqParams.get('id');
Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
delete acct;
}
}
...
}
<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
rb.sendRequest(body, new NewAccountCallback(callback));
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
body = addToPost(body, "attacker";
body = addToPost(body, "haha");
rb.sendRequest(body, new NewAccountCallback(callback));
example.com の管理者が、サイトでセッションを行っているときに、悪意あるページにアクセスすると、攻撃者にアカウントを作成してしまいますが、本人はそのことに気づきません。これが CSRF 攻撃です。アプリケーションには、リクエストの生成元を検証する方法がないために、この攻撃が可能となっています。リクエストはユーザーによって選択された正当なアクションにも、攻撃者が準備した不正なアクションにもなりえます。攻撃者は偽のリクエストを生成する Web ページを見ることができません。そのため、この攻撃方法は、アプリケーションの状態を変更するリクエストにのみ有効です。
<http auto-config="true">
...
<csrf disabled="true"/>
</http>
var req = new XMLHttpRequest();
req.open("POST", "/new_user", true);
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
req.send(body);
var req = new XMLHttpRequest();
req.open("POST", "http://www.example.com/new_user", true);
body = addToPost(body, "attacker");
body = addToPost(body, "haha");
req.send(body);
example.com の管理者が、サイトでセッションを行っているときに、悪意あるページにアクセスすると、攻撃者にアカウントを作成してしまいますが、本人はそのことに気づきません。これが CSRF 攻撃です。アプリケーションには、リクエストの生成元を検証する方法がないために、この攻撃が可能となっています。リクエストはユーザによって選択された正当なアクションにも、攻撃者が準備した不正なアクションにもなりえます。攻撃者は偽のリクエストを生成する Web ページを見ることができません。そのため、この攻撃方法は、アプリケーションの状態を変更するリクエストにのみ有効です。
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com の管理者が、サイトでセッションを行っているときに、悪意あるページにアクセスすると、攻撃者にアカウントを作成してしまいますが、本人はそのことに気づきません。これが CSRF 攻撃です。アプリケーションには、リクエストの生成元を検証する方法がないために、この攻撃が可能となっています。リクエストはユーザによって選択された正当なアクションにも、攻撃者が準備した不正なアクションにもなりえます。攻撃者は偽のリクエストを生成する Web ページを見ることができません。そのため、この攻撃方法は、アプリケーションの状態を変更するリクエストにのみ有効です。buyItem コントローラー メソッドの CSRF 保護を無効にします。
+ nocsrf
POST /buyItem controllers.ShopController.buyItem
shop.com のアクティブ セッション実行時に、ユーザーは意図せずに悪意あるページに誘導され、気づかないうちに攻撃者にアイテムを購入してしまいます。 これが CSRF 攻撃です。 アプリケーションには、リクエストの生成元を検証する方法がないために、この攻撃が可能となっています。 リクエストはユーザーによって選択された正当なアクションにも、攻撃者が準備した不正なアクションにもなりえます。 攻撃者は偽のリクエストを生成する Web ページを見ることができません。そのため、この攻撃方法は、アプリケーションの状態を変更するリクエストにのみ有効です。
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com の管理者が、サイトでセッションを行っているときに、悪意あるページにアクセスすると、攻撃者にアカウントを作成してしまいますが、本人はそのことに気づきません。これが CSRF 攻撃です。アプリケーションには、リクエストの生成元を検証する方法がないために、この攻撃が可能となっています。リクエストはユーザによって選択された正当なアクションにも、攻撃者が準備した不正なアクションにもなりえます。攻撃者は偽のリクエストを生成する Web ページを見ることができません。そのため、この攻撃方法は、アプリケーションの状態を変更するリクエストにのみ有効です。
...
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 を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取り、ユーザーに表示します。
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
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 を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。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 レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
...
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 を含め、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。username を読み取って、ユーザーに表示します。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username にメタ文字またはソース コードが含まれている場合、コードは Web ブラウザで実行されます。Example 1 に示すように、データベースなどのデータ ストアからアプリケーションに危険なデータが提供され、動的コンテンツに追加されることがあります。攻撃者の立場からすると、悪意のあるコンテンツを保存するのに最適な場所は、すべてのユーザー (特に、高い権限を持つ、機密情報の処理や重要な操作を実行する可能性の高いユーザー) がアクセスできる領域です。Example 2 に示すように、データが HTTP リクエストから読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS は、攻撃者が脆弱な Web アプリケーションに危険なコンテンツを配信し、それをユーザーに反映して、ユーザーのブラウザで実行するように設定できる場合に発生します。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は攻撃対象者をこの URL に誘い込みます。コンテンツがユーザーに戻されてサイトに反映されると、コンテンツが実行され、攻撃対象者のコンピュータから個人の機密情報を転送する、不正な操作を実行する、などの複数の操作が実行可能になります。
<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 は、次のように定義されるフォーム コントロールです。例 2: 次の ASP.NET コードセグメントは、
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
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 を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login および EmployeeID は、次のように定義されるフォーム コントロールです。例 4: 次の ASP.NET コードセグメントは、
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
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 レスポンスを表示する際にコードが実行されます。Example 1 および Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 や Example 4 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
ENAME の値の動作が適切であれば、この例のコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。ENAME の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、ENAME の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。ストアド XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。EID を HTML フォームから読み取り、ユーザーに表示します。
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
Example 1 と同様に、このコードは、EID に標準の英数字テキストだけが含まれている場合に正しく動作します。EID の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。攻撃者が以下を行う場合に、保存された XSS の悪用が発生します Example 2 に示すように、データが HTML フォームから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
<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 を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を Web フォームから読み取りユーザーに表示します。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Example 1 と同様に、このコードは、Form.eid に標準の英数字テキストだけが含まれている場合に正しく動作します。Form.eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。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 レスポンスを表示する際にコードが実行されます。
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 を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険なコンテンツを入力させられてしまい、それがユーザーに送り返されて Web ブラウザーにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意あるコンテンツを実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりすることがあります。
<%...
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 を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取ってユーザーに表示します。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
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 ページのコンテキストから実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP 要求から読み取ってユーザーに表示します。
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
...
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP サーブレット リクエストから読み取ってから、サーブレットのレスポンスでユーザーに値を表示します。
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url の値が javascript: から始まる場合、それに続く JavaScript コードが WebView 内の Web ページのコンテキストから実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。myapp://input_to_the_application)。URL の中の信頼できないデータは、その後 UIWebView コンポーネントで HTML 出力を処理するために使用されます。
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示したように、カスタムの URL スキームからデータが直接読み取られ、UIWebView レスポンスの内容に反映されます。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある iOS アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信されるカスタムスキーム URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるアプリケーションの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてアプリケーションに反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取り、ユーザーに表示します。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取ってユーザーに表示します。
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。eid を HTTP リクエストから読み取り、ユーザーに表示します。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取り、ユーザーに表示します。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
Example 1 のコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 2 のように Rack::Request#params() を利用した場合、GET パラメーターと POST パラメーターの両方が表示されます。そのため、悪意のあるコードが URL に追加されるだけでなく、さまざまな種類の攻撃に対して脆弱になる可能性があります。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。eid をデータベース クエリから読み取ってユーザーに表示します。
def getEmployee = Action { implicit request =>
val employee = getEmployeeFromDB()
val eid = employee.id
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 内のテキストに標準の英数字テキストのみが含まれる場合は問題なく動作します。inputTextField 内のテキストにメタ文字またはソースコードが含まれる場合、入力は HTTP レスポンスを表示するときに Web ブラウザによってコードとして実行されます。myapp://input_to_the_application)。URL の中の信頼できないデータは、その後 UIWebView コンポーネントで HTML 出力を処理するために使用されます。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 では、ユーザー制御可能な UI コンポーネントからデータを直接読み取り、HTTP レスポンスに反映します。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 では、ターゲット アプリケーション外部のソースが、ターゲット アプリケーションのカスタム URL スキームを使用して URL リクエストを作成し、続いて URL リクエストによる未検証のデータが信頼されるデータとしてアプリケーションに再び読み込まれ、動的コンテンツに含まれます。
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。eid を HTTP リクエストから読み取ってユーザーに表示します。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
Example 1 と同様に、このコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。cl_http_utility=>escape_html などの特定のエンコーディング関数モジュールを使用すると、ある程度は攻撃を防ぐことができますが、すべての Cross-Site Scripting 攻撃を防ぐことはできません。データが出現するコンテキストによっては、HTML としてエンコードされた基本的な <、>、&、'、および " 以外の文字や、XML としてエンコードされた <、>、&、"、および ' 以外の文字も、メタ的な意味を持つ場合があります。このようなエンコーディング関数モジュールに頼ることは、脆弱な拒否リストを使用して Cross-Site Scripting を阻止しようとするのと同じことであるため、攻撃者が悪意あるコードを挿入してブラウザーで実行することを許してしまう可能性があります。データが静的に出現するコンテキストを正確に毎回特定することは不可能であるため、Fortify Secure Coding Rulepack では、エンコーディングが適用されている場合でも Cross-Site Scripting を検知して報告し、Cross-Site Scripting: Poor Validation の問題として表示します。eid を HTTP リクエストから読み取り、HTML でエンコードしてユーザーに表示します。
...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = eid
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_eid ).
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
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.
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = itab_employees-name
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_name ).
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、HTML でエンコードしてユーザーに表示します。
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + escape(eid);
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
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: " + escape(name);
}
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>
HTMLENCODE を使用しているかどうかに関係なく、データベースから提供されたデータを適切に検証しないため、XSS に対して脆弱です。この原因は、variable の内容が複数のメカニズム (HTML と Javascript パーサー) で解析されることにより、エンコードを 2 回行う必要があるためです。このように、攻撃者はリフレクト XSS でのように攻撃対象者とやり取りしなくても、ユーザーの Web ブラウザ内で悪意のあるコマンドを実行することができます。このタイプの攻撃はストアド XSS (または持続型 XSS) と呼ばれていて、データが脆弱な関数に間接的に提供されるため、検出するのが非常に困難な場合があります。また、複数のユーザーに影響する可能性があるため、影響が大きくなることもあります。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含め、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。username を読み取って、ユーザーに表示します。
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
username にメタ文字またはソース コードが含まれている場合、コードは Web ブラウザで実行されます。また、この例では HTMLENCODE は Javascript パーサーで処理されるため、この変数を使用しても XSS 攻撃を十分に防ぐことはできません。Example 1 に示すように、データベースなどのデータ ストアからアプリケーションに危険なデータが提供され、動的コンテンツに追加されることがあります。攻撃者の立場からすると、悪意のあるコンテンツを保存するのに最適な場所は、すべてのユーザー (特に、高い権限を持つ、機密情報の処理や重要な操作を実行する可能性の高いユーザー) がアクセスできる領域です。Example 2 に示すように、データが HTTP リクエストから読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS は、攻撃者が脆弱な Web アプリケーションに危険なコンテンツを配信し、それをユーザーに反映して、ユーザーのブラウザで実行するように設定できる場合に発生します。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は攻撃対象者をこの URL に誘い込みます。コンテンツがユーザーに戻されてサイトに反映されると、コンテンツが実行され、攻撃対象者のコンピュータから個人の機密情報を転送する、不正な操作を実行する、などの複数の操作が実行可能になります。
<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
...
</script>
Login および EmployeeID は、次のように定義されるフォーム コントロールです。例 2: 次の ASP.NET コードセグメントは、プログラミングとしては
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1 と同じ機能を実装します。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
Login に標準の英数字テキストだけが含まれている場合に正しく動作します。Login の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
<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 = Server.HtmlEncode(name);
</script>
EmployeeName は、次のように定義されるフォーム コントロールです。例 4: 同様に、次の ASP.NET コードセグメントは、
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3 と機能的には同じですが、すべてのフォーム要素をプログラム的に実装しています。
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 = Server.HtmlEncode(name);
Example 1 と Example 2 に示したように、name の値の動作が適切であればこれらのコード セグメントは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、これらのコード セグメントはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 や Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 および Example 4 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。text パラメーターを HTTP リクエストから読み取り、HTML でエンコードして、スクリプトタグ間の警告ボックスに表示します。
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
text に標準の英数字テキストだけが含まれている場合に正しく動作します。text に単一引用符、丸カッコ、セミコロンが含まれている場合、実行後に、コードは alert テキストボックスで終了します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。user を HTTP リクエストから読み取り、ユーザーに表示します。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(user))
}
user に標準の英数字テキストだけが含まれている場合に正しく動作します。user の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
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: ", html.EscapeString(name))
}
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザーで攻撃者が悪意あるコマンドを実行することがあります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターに「ゲストブック」を提供している Web サイトで、次のような形式で開始されます。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険なコンテンツを入力させられてしまい、それがユーザーに送り返されて Web ブラウザーにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意あるコンテンツを実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりすることがあります。escapeXml="true" 属性とともに <c:out/> タグを使用する (デフォルトの動作) など、特定のエンコーディング構造体を使用すると、すべてではありませんが一部の Cross-Site Scripting 攻撃を未然に防ぐことができます。データが出現するコンテキストによっては、HTML としてエンコードされた基本的な <、>、&、'、および " 以外の文字や、XML としてエンコードされた <、>、&、"、および ' 以外の文字も、メタ的な意味を持つ可能性があります。このようなエンコーディング構造体に頼ることは、脆弱な拒否リストを使用して Cross-Site Scripting を阻止しようとするのと同じことであるため、攻撃者が悪意あるコードを挿入してブラウザーで実行することを許容してしまう可能性があります。データが静的に出現するコンテキストを正確に毎回特定することは不可能であるため、Fortify Static Code Analyzer は、エンコーディングが適用されている場合でも Cross-Site Scripting を検知して報告し、Cross-Site Scripting: Poor Validation の問題。eid を HTTP リクエストから読み取り、<c:out/> タグを介してユーザーに表示します。
Employee ID: <c:out value="${param.eid}"/>
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。<c:out/> タグを介して対応する従業員の名前を出力します。
<%...
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: <c:out value="${name}"/>
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(URLEncoder.encode(url));
...
url の値が javascript: から始まる場合、それに続く JavaScript コードが WebView 内の Web ページのコンテキストから実行されます。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。eid を HTTP リクエストから読み取り、エスケープして、ユーザーに表示します。
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。escapeXml="true" 属性とともに <c:out/> タグを使用する (デフォルトの動作) など、特定のエンコーディング構造体を使用すると、すべてではありませんが一部の Cross-Site Scripting 攻撃を未然に防ぐことができます。データが出現するコンテキストによっては、HTML としてエンコードされた基本的な <、>、&、'、および " 以外の文字や、XML としてエンコードされた <、>、&、"、および ' 以外の文字も、メタ的な意味を持つ可能性があります。このようなエンコーディング構造体に頼ることは、脆弱な拒否リストを使用して Cross-Site Scripting を阻止しようとするのと同じことであるため、攻撃者が悪意あるコードを挿入してブラウザーで実行することを許容してしまう可能性があります。データが静的に出現するコンテキストを正確に毎回特定することは不可能であるため、Fortify Static Code Analyzer は、エンコーディングが適用されている場合でも Cross-Site Scripting を検知して報告し、Cross-Site Scripting: Poor Validation の問題。eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(URLEncoder.encode(url))
...
url の値が javascript: から始まる場合、それに続く JavaScript コードが WebView 内の Web ページのコンテキストから実行されます。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。myapp://input_to_the_application)。URL の中の信頼できないデータは、その後 UIWebView コンポーネントで HTML 出力を処理するために使用されます。
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
...
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
[DefaultEncoder encodeForHTML:partAfterSlashSlash],
@"')\" />"];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:htmlPage baseURL:nil];
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値がデータベースから読み込まれていて、HTML エンコードされているからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。攻撃者が指定した攻撃コードは、エンコードされた文字を迂回すること、あるいは HTML エンコーディングに影響を受けないコンテキストに入力を配置することが可能です。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示したように、カスタムの URL スキームからデータが直接読み取られ、UIWebView レスポンスの内容に反映されます。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある iOS アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信されるカスタムスキーム URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるアプリケーションの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてアプリケーションに反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。htmlspecialchars() や htmlentities() などの特定のエンコーディング関数を使用すると、ある程度は攻撃を防ぐことができますが、すべての Cross-Site Scripting 攻撃を防ぐことはできません。データが出現するコンテキストによっては、HTML としてエンコードされた基本的な <、>、&、'、および " 以外の文字や、XML としてエンコードされた <、>、&、"、および ' (ENT_QUOTES が設定されている場合のみ) 以外の文字も、メタ的な意味を持つ場合があります。このようなエンコーディング関数に頼ることは、脆弱な拒否リストを使用して Cross-Site Scripting を阻止しようとするのと同じことであるため、攻撃者が悪意あるコードを挿入してブラウザーで実行することを許容してしまう可能性があります。データが静的に出現するコンテキストを正確に毎回特定することは不可能であるため、Fortify Secure Coding Rulepack では、エンコーディングが適用されている場合でも Cross-Site Scripting を検知して報告し、Cross-Site Scripting: Poor Validation の問題として表示します。text パラメーターを HTTP リクエストから読み取り、HTML でエンコードして、スクリプトタグ間の警告ボックスに表示します。
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
text に標準の英数字テキストだけが含まれている場合に正しく動作します。text に単一引用符、丸カッコ、セミコロンが含まれている場合、実行後に、コードは alert テキストボックスで終了します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。eid を HTTP リクエストから読み取り、URL でエンコードしてユーザーに表示します。
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || HTMLDB_UTIL.url_encode(eid) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || HTMLDB_UTIL.url_encode(name) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、HTML でエンコードしてユーザーに表示します。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + escape(eid))
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、HTML でエンコードしてユーザーに表示します。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 のように Rack::Request#params() を利用した場合、GET パラメーターと POST パラメーターの両方が表示されます。そのため、悪意のあるコードが URL に追加されるだけでなく、さまざまな種類の攻撃に対して脆弱になる可能性があります。
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行することができます。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取ってユーザーに表示します。
def getEmployee = Action { implicit request =>
var eid = request.getQueryString("eid")
eid = StringEscapeUtils.escapeHtml(eid); // insufficient validation
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。myapp://input_to_the_application)。URL の中の信頼できないデータは、その後 UIWebView コンポーネントで HTML 出力を処理するために使用されます。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値がデータベースから読み込まれていて、HTML エンコードされているからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。攻撃者が指定した攻撃コードは、エンコードされた文字を迂回すること、あるいは HTML エンコーディングに影響を受けないコンテキストに入力を配置することが可能です。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 内のテキストに標準の英数字テキストのみが含まれる場合は問題なく動作します。inputTextField 内のテキストにメタ文字またはソースコードが含まれる場合、入力は HTTP レスポンスを表示するときに Web ブラウザによってコードとして実行されます。Example 1 に示したように、カスタムの URL スキームからデータが直接読み取られ、UIWebView レスポンスの内容に反映されます。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある iOS アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信されるカスタムスキーム URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるアプリケーションの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてアプリケーションに反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 では、ターゲット アプリケーション外部のソースが、ターゲット アプリケーションのカスタム URL スキームを使用して URL リクエストを作成し、続いて URL リクエストによる未検証のデータが信頼されるデータとしてアプリケーションに再び読み込まれ、動的コンテンツに含まれます。eid を HTTP リクエストから読み取り、HTML でエンコードしてユーザーに表示します。
...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
..
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & Server.HTMLEncode(objADORecordSet("name"))
objADORecordSet.MoveNext
Wend
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、ユーザーに表示します。
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
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 ).
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。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;
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
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;
}
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。username を読み取って、ユーザーに表示します。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username にメタ文字またはソース コードが含まれている場合、コードは Web ブラウザで実行されます。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
Example 1 に示すように、name の値が単なる英数字のように適切に定義されている場合はこのコードが正しく動作しますが、悪意のあるデータのチェックは行われません。データベースの内容はユーザー指定のデータから取得されることがあるため、データベースから読み取る場合でも値を適切に検証する必要があります。このように、攻撃者はリフレクト XSS でのように攻撃対象者とやり取りしなくても、ユーザーの Web ブラウザ内で悪意のあるコマンドを実行することができます。このタイプの攻撃はストアド XSS (または持続型 XSS) と呼ばれていて、データが脆弱な関数に間接的に提供されるため、検出するのが非常に困難な場合があります。また、複数のユーザーに影響する可能性があるため、影響が大きくなることもあります。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS は、攻撃者が脆弱な Web アプリケーションに危険なコンテンツを配信し、それをユーザーに反映して、ユーザーのブラウザで実行するように設定できる場合に発生します。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は攻撃対象者をこの URL に誘い込みます。コンテンツがユーザーに戻されてサイトに反映されると、コンテンツが実行され、攻撃対象者のコンピュータから個人の機密情報を転送する、不正な操作を実行する、などの複数の操作が実行可能になります。Example 2 に示すように、データベースなどのデータ ストアからアプリケーションに危険なデータが提供され、動的コンテンツに追加されることがあります。攻撃者の立場からすると、悪意のあるコンテンツを保存するのに最適な場所は、すべてのユーザー (特に、高い権限を持つ、機密情報の処理や重要な操作を実行する可能性の高いユーザー) がアクセスできる領域です。
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login および EmployeeID は、次のように定義されるフォーム コントロールです。例 2: 次の ASP.NET コードセグメントは、
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1 をプログラミングで実装する方法を示しています。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Login に標準の英数字テキストだけが含まれている場合に正しく動作します。Login の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
<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 は、次のように定義されるフォーム コントロールです。例 4: 次の ASP.NET コードセグメントは、
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3 と機能的には同じですが、すべてのフォーム要素をプログラミングによって実装しています。
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;
Example 1 と Example 2 に示したように、name の値の動作が適切であればこれらのコード例は正しく機能しますが、値が適切ではない場合は悪用を阻止できません。この場合も、これらのコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースの内容はアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 や Example 2 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 3 および Example 4 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。EID を HTML フォームから読み取り、ユーザーに表示します。
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
EID に標準の英数字テキストだけが含まれている場合に正しく動作します。EID の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
Example 1 に示すように、ENAME の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。ENAME の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、ENAME の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。ストアド XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTML フォームから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。攻撃者が以下を行う場合に、保存された XSS の悪用が発生します eid を Web フォームから読み取りユーザーに表示します。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Form.eid に標準の英数字テキストだけが含まれている場合に正しく動作します。Form.eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。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 レスポンスを表示する際にコードが実行されます。
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 を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険なコンテンツを入力させられてしまい、それがユーザーに送り返されて Web ブラウザーにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意あるコンテンツを実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりすることがあります。eid を HTTP リクエストから読み取ってユーザーに表示します。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
<%...
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 %>
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
...
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 ページのコンテキストから実行されます。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。eid を HTTP 要求から読み取ってユーザーに表示します。
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP サーブレット リクエストから読み取ってから、サーブレットのレスポンスでユーザーに値を表示します。
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url の値が javascript: から始まる場合、それに続く JavaScript コードが WebView 内の Web ページのコンテキストから実行されます。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。myapp://input_to_the_application)。URL の中の信頼できないデータは、その後 UIWebView コンポーネントで HTML 出力を処理するために使用されます。
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示したように、カスタムの URL スキームからデータが直接読み取られ、UIWebView レスポンスの内容に反映されます。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある iOS アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信されるカスタムスキーム URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるアプリケーションの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてアプリケーションに反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、ユーザーに表示します。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取ってユーザーに表示します。
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、ユーザーに表示します。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取り、ユーザーに表示します。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。Example 1 のように Rack::Request#params() を利用した場合、GET パラメーターと POST パラメーターの両方が表示されます。そのため、悪意のあるコードが URL に追加されるだけでなく、さまざまな種類の攻撃に対して脆弱になる可能性があります。
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取ってユーザーに表示します。
def getEmployee = Action { implicit request =>
val eid = request.getQueryString("eid")
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 内のテキストに標準の英数字テキストのみが含まれる場合は問題なく動作します。inputTextField 内のテキストにメタ文字またはソースコードが含まれる場合、入力は HTTP レスポンスを表示するときに Web ブラウザによってコードとして実行されます。myapp://input_to_the_application)。URL の中の信頼できないデータは、その後 UIWebView コンポーネントで HTML 出力を処理するために使用されます。
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
Example 2 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 では、ユーザー制御可能な UI コンポーネントからデータを直接読み取り、HTTP レスポンスに反映します。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 では、ターゲット アプリケーション外部のソースが、ターゲット アプリケーションのカスタム URL スキームを使用して URL リクエストを作成し、続いて URL リクエストによる未検証のデータが信頼されるデータとしてアプリケーションに再び読み込まれ、動的コンテンツに含まれます。Example 3 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。eid を HTTP リクエストから読み取ってユーザーに表示します。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
NSString *regex = @"^(e+)+$";
NSPredicate *pred = [NSPRedicate predicateWithFormat:@"SELF MATCHES %@", regex];
if ([pred evaluateWithObject:mystring]) {
//do something
}
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
let regex : String = "^(e+)+$"
let pred : NSPredicate = NSPRedicate(format:"SELF MATCHES \(regex)")
if (pred.evaluateWithObject(mystring)) {
//do something
}
Example 1 を踏まえると、攻撃者が "eeeeZ" という一致文字列を指定した場合、正規表現パーサーが一致を特定するまでに実行しなくてはならない内部評価は 16 件あります。攻撃者が 16 個の "e" ("eeeeeeeeeeeeeeeeZ") を一致文字列として指定した場合には、正規表現パーサーは 65536 (2^16) 回の評価を実行する必要があります。攻撃者は、連続する一致文字の数を増やすことによって、容易にコンピューティング リソースを消費できます。この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーション サーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。
@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();
RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}
author と Jane Smith で構成されると想定した場合、このヘッダーを含む HTTP レスポンスは次のような形式になります。
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo や bar などの悪意のある名前と値のペアを送信し、HTTP レスポンスが次の形式の 2 つのレスポンスに分割される場合があります。
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
HttpResponse.AddHeader() メソッドに送信されるときに、CR、LF、および NULL 文字が %0d、%0a、および %00 に変換されます。最新の .NET フレームワークを使用しており、改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではない可能性があります。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
Author.Text として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
author を HTML フォームから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.
EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を Web フォームから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1/1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーション サーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。
final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});
author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。name と value が攻撃者によって制御される可能性がある場合を想定します。このコードは、名前と値が攻撃者によって制御される可能性のある HTTP ヘッダーを設定します。
...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...
author と Jane Smith で構成されると想定すると、このヘッダーを含む HTTP レスポンスは次の形式をとります。
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo や bar などの悪意のある名前/値のペアを送信する可能性があり、その場合 HTTP レスポンスは次の形式の 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
header() 関数に渡されると、警告を生成し、ヘッダーの作成を中止します。使用している PHP のバージョンが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。
<?php
$location = $_GET['some_location'];
...
header("location: $location");
?>
HTTP/1.1 200 OK
...
location: index.html
...
some_location として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「index.html\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
location = req.field('some_location')
...
response.addHeader("location",location)
HTTP/1.1 200 OK
...
location: index.html
...
some_location として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「index.html\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、サイトの別の部分への get リクエストに使用します。
author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n...」といった悪意のある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker
POST /index.php HTTP/1.1
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。name と value が攻撃者によって制御される可能性がある場合を想定します。このコードは、名前と値が攻撃者によって制御される可能性のある HTTP ヘッダーを設定します。
...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...
author と Jane Smith で構成されると想定すると、このヘッダーを含む HTTP レスポンスは次の形式をとります。
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo や bar などの悪意のある名前/値のペアを送信する可能性があり、その場合 HTTP レスポンスは次の形式の 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーション サーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーに設定します。
...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
author として送信された値に CR 文字や LF 文字が含まれていない場合のみです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは次の形式で 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーション サーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合のみです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは次の形式で 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
Example 1 を応用しています。クロスユーザー改竄: 攻撃者は脆弱なサーバーに対して、2 つのレスポンスを作成させる単一のリクエストを行います。その 2 番目のレスポンスは、別のリクエスト、おそらくはサーバーとの TCP 接続を共有している別のユーザーが行ったリクエストに対する回答と誤って解釈される可能性があります。この攻撃は、攻撃者とユーザーがサーバー (共通のプロキシサーバーなど) との TCP 接続を共有している状況で、悪意あるリクエストをユーザー自身で、またはリモートから送信するよう誘導します。最も良心的な場合でも、攻撃者はこの能力を活用して、ユーザーにアプリケーションがハッキングされていると思わせ、アプリケーションのセキュリティに対する信頼を失わせる可能性があります。最悪の場合、攻撃者はアプリケーションの動作を模倣し、口座番号やパスワードなどの個人情報を攻撃者にリダイレクトするよう設計されたコンテンツを用意しています。
...
CookieManager webCookieManager = CookieManager.getInstance();
String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
webCookieManager.setCookie(url, setCookie);
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
<?php
$author = $_GET['AUTHOR_PARAM'];
...
header("author: $author");
?>
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
location = req.field('some_location')
...
response.addHeader("location",location)
HTTP/1.1 200 OK
...
location: index.html
...
some_location として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「index.html\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
IllegalArgumentException が発生します。 使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。 しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。IllegalArgumentException が発生します。使用しているアプリケーションサーバーが改行文字を含むヘッダーの設定を防ぐようになっている場合には、アプリケーションは HTTP Response Splitting に対して脆弱ではありません。しかし、改行文字だけを単にフィルタしても、アプリケーションは Cookie Manipulation (Cookie の不正操作) や Open Redirects (オープンリダイレクト) に対して脆弱なままとなります。そのため、ユーザー入力が関連する HTTP ヘッダーを設定するときには、注意が必要となります。author を HTTP リクエストから読み取り、HTTP レスポンスの cookie ヘッダーにセットします。
...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM として送信された値に CR 文字や LF 文字が含まれていない場合だけです。攻撃者が「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」といった悪意ある文字列を送信すると、HTTP レスポンスは、次のような 2 つのレスポンスに分割されます。
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
Response.AppendHeader("Access-Control-Allow-Origin", "*");
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
<websocket:handlers allowed-origins="*">
<websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、任意のドメインで実行されている JavaScript がアプリケーションのデータにアクセスできます。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
<?php
header('Access-Control-Allow-Origin: *');
?>
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
response.addHeader("Access-Control-Allow-Origin", "*")
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
play.filters.cors {
pathPrefixes = ["/some/path", ...]
allowedOrigins = ["*"]
allowedHttpMethods = ["GET", "POST"]
allowedHttpHeaders = ["Accept"]
preflightMaxAge = 3 days
}
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。
Response.AddHeader "Access-Control-Allow-Origin", "*"
* を Access-Control-Allow-Origin ヘッダーの値として使用すると、アプリケーションのデータが、任意のドメインで実行される JavaScript にアクセスできることになります。
FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
DATA: r TYPE REF TO cl_abap_random,
var1 TYPE i,
var2 TYPE i,
var3 TYPE n.
GET TIME.
var1 = sy-uzeit.
r = cl_abap_random=>create( seed = var1 ).
r->int31( RECEIVING value = var2 ).
var3 = var2.
CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.
CL_ABAP_RANDOM->INT31 関数を使用して、領収書ページの一意の識別子を生成します。CL_ABAP_RANDOM は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
string GenerateReceiptURL(string baseUrl) {
Random Gen = new Random();
return (baseUrl + Gen.Next().toString() + ".html");
}
Random.Next() 関数を使用して、領収書ページの一意の識別子を生成します。Random.Next() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
char* CreateReceiptURL() {
int num;
time_t t1;
char *URL = (char*) malloc(MAX_URL);
if (URL) {
(void) time(&t1);
srand48((long) t1); /* use time to set seed */
sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
}
return URL;
}
lrand48() 関数を使用して、領収書ページの一意の識別子を生成します。lrand48() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>
Rand() 関数を使用して、領収書ページの一意の識別子を生成します。Rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)
rand.New() 関数を使用して、RSA 鍵の乱数を生成します。rand.New() は統計的 PRNG なので、生成される値の推測は攻撃者にとってはたやすいことです。
String GenerateReceiptURL(String baseUrl) {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return (baseUrl + ranGen.nextInt(400000000) + ".html");
}
Random.nextInt() 関数を使用して、領収書ページの一意の識別子を生成します。Random.nextInt() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
function genReceiptURL (baseURL){
var randNum = Math.random();
var receiptURL = baseURL + randNum + ".html";
return receiptURL;
}
Math.random() 関数を使用して、領収書ページの一意の識別子を生成します。Math.random() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
fun GenerateReceiptURL(baseUrl: String): String {
val ranGen = Random(Date().getTime())
return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}
Random.nextInt() 関数を使用して、領収書ページの「一意の」識別子を生成します。Random.nextInt() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
function genReceiptURL($baseURL) {
$randNum = rand();
$receiptURL = $baseURL . $randNum . ".html";
return $receiptURL;
}
rand() 関数を使用して、領収書ページの一意の識別子を生成します。rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
RETURN VARCHAR2
AS
rnum VARCHAR2(48);
time TIMESTAMP;
url VARCHAR2(MAX_URL)
BEGIN
time := SYSTIMESTAMP;
DBMS_RANDOM.SEED(time);
rnum := DBMS_RANDOM.STRING('x', 48);
url := 'http://test.com/' || rnum || '.html';
RETURN url;
END
DBMS_RANDOM.SEED() 関数を使用して、領収書ページの一意の識別子を生成します。DBMS_RANDOM.SEED() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
def genReceiptURL(self,baseURL):
randNum = random.random()
receiptURL = baseURL + randNum + ".html"
return receiptURL
rand() 関数を使用して、領収書ページの一意の識別子を生成します。rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
def generateReceiptURL(baseUrl) {
randNum = rand(400000000)
return ("#{baseUrl}#{randNum}.html");
}
Kernel.rand() 関数を使用して、領収書ページの一意の識別子を生成します。Kernel.rand() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。
def GenerateReceiptURL(baseUrl : String) : String {
val ranGen = new scala.util.Random()
ranGen.setSeed((new Date()).getTime())
return (baseUrl + ranGen.nextInt(400000000) + ".html")
}
Random.nextInt() 関数を使用して、領収書ページの一意の識別子を生成します。Random.nextInt() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。
sqlite3_randomness(10, &reset_token)
...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...
Rnd() 関数を使用して、領収書ページの一意の識別子を生成します。Rnd() は統計的 PRNG なので、生成される文字列の推測は攻撃者にとってはたやすいことです。領収書システムの基礎設計にも欠陥がありますが、暗号的 PRNG など、予測可能な領収書 ID を生成しない乱数ジェネレータを使えば安全性が高まります。CL_ABAP_RANDOM クラスまたはそのバリアントなど) が特定の定数値を使用してシードされると、値を返すかまたは割り当てる GET_NEXT、INT および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。random_gen2 で生成される値は、オブジェクト random_gen1 から予想できます。
DATA: random_gen1 TYPE REF TO cl_abap_random,
random_gen2 TYPE REF TO cl_abap_random,
var1 TYPE i,
var2 TYPE i.
random_gen1 = cl_abap_random=>create( seed = '1234' ).
DO 10 TIMES.
CALL METHOD random_gen1->int
RECEIVING
value = var1.
WRITE:/ var1.
ENDDO.
random_gen2 = cl_abap_random=>create( seed = '1234' ).
DO 10 TIMES.
CALL METHOD random_gen2->int
RECEIVING
value = var2.
WRITE:/ var2.
ENDDO.
random_gen1 と random_gen2 が同じようにシードされたため、var1 = var2 となりますsrand(unsigned int) のような関数を使用) 疑似ランダム数値の生成機能 (rand() など) をシードすると、値を返すかまたは割り当てる rand() および類似のメソッドによって返される値は、攻撃者にとって予想可能になり、攻撃者が複数の PRNG 出力を収集できるようになります。
srand(2223333);
float randomNum = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum);
randomNum = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum);
srand(2223333);
float randomNum2 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum2);
randomNum2 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum2);
srand(1231234);
float randomNum3 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum3);
randomNum3 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum3);
randomNum1 と randomNum2 の結果は同一の方法でシードされているので、擬似ランダム数値の生成機能 srand(2223333) をシードするコール後の rand() への各コールは、結果的に同じコール実行順序で同じ出力になります。たとえば、出力は以下のようになります。
Random: 32.00
Random: 73.00
Random: 32.00
Random: 73.00
Random: 15.00
Random: 75.00
math.Rand.New(Source) のような関数を使用) してシードされると、値を返すかまたは割り当てる math.Rand.Int() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。
randomGen := rand.New(rand.NewSource(12345))
randomInt1 := randomGen.nextInt()
randomGen.Seed(12345)
randomInt2 := randomGen.nextInt()
randomGen.Seed(12345)) の後に nextInt() をコールすると、同じ出力が同じ順序で得られます。Random など) が特定の値を使用 (Random.setSeed() のような関数を使用) してシードされると、値を返すかまたは割り当てる Random.nextInt() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。Random オブジェクト randomGen2 によって生成される値は、Random オブジェクト randomGen1 から予想できます。
Random randomGen1 = new Random();
randomGen1.setSeed(12345);
int randomInt1 = randomGen1.nextInt();
byte[] bytes1 = new byte[4];
randomGen1.nextBytes(bytes1);
Random randomGen2 = new Random();
randomGen2.setSeed(12345);
int randomInt2 = randomGen2.nextInt();
byte[] bytes2 = new byte[4];
randomGen2.nextBytes(bytes2);
randomGen1 と randomGen2 は同一の方法でシードされるので、randomInt1 == randomInt2、および対応する配列 bytes1[] と bytes2[] の値は等しくなります。Random など) が特定の値を使用 (Random(Int) のような関数を使用) してシードされると、値を返すかまたは割り当てる Random.nextInt() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。Random オブジェクト randomGen2 によって生成される値は、Random オブジェクト randomGen1 から予想できます。
val randomGen1 = Random(12345)
val randomInt1 = randomGen1.nextInt()
val byteArray1 = ByteArray(4)
randomGen1.nextBytes(byteArray1)
val randomGen2 = Random(12345)
val randomInt2 = randomGen2.nextInt()
val byteArray2 = ByteArray(4)
randomGen2.nextBytes(byteArray2)
randomGen1 と randomGen2 は同一の方法でシードされるので、randomInt1 == randomInt2、および対応する配列 byteArray1 と byteArray2 の値は等しくなります。
...
import random
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
...
random.seed(123456)) をシードするコールの後の randint() への各コールの結果、同じものが同じ順序で出力されます。たとえば、出力は以下のようになります。
Random: 81
Random: 80
Random: 3
Random: 81
Random: 80
Random: 3
Random など) が特定の値を使用 (Random.setSeed() のような関数を使用) してシードされると、値を返すかまたは割り当てる Random.nextInt() および類似のメソッドによって返される値を攻撃者が予測できるようになり、攻撃者は複数の PRNG 出力を収集できるようになります。Random オブジェクト randomGen2 によって生成される値は、Random オブジェクト randomGen1 から予想できます。
val randomGen1 = new Random()
randomGen1.setSeed(12345)
val randomInt1 = randomGen1.nextInt()
val bytes1 = new byte[4]
randomGen1.nextBytes(bytes1)
val randomGen2 = new Random()
randomGen2.setSeed(12345)
val randomInt2 = randomGen2.nextInt()
val bytes2 = new byte[4]
randomGen2.nextBytes(bytes2)
randomGen1 と randomGen2 は同一の方法でシードされるので、randomInt1 == randomInt2、および対応する配列 bytes1[] と bytes2[] の値は等しくなります。CL_ABAP_RANDOM (またはそのバリアント) を、汚染された引数を使用して初期化しないでください。そのような初期化を行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、以下のようなメソッド (これらに限りません) へのコールによって作成された値のシーケンスを攻撃者が予測できるようになります。 GET_NEXT, INT, FLOAT, PACKED.rand() など) を生成する関数 (シード (srand() など) が渡される) を、汚染された引数を使用してコールしないでください。このようなコールを行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、擬似乱数生成機能へのコールによって作成された値のシーケンス (通常は整数) を攻撃者が予測できるようになります。ed25519.NewKeyFromSeed()) を、汚染された引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似乱数ジェネレータのシードに使用する値を制御できるようになるため、疑似乱数ジェネレータを呼び出したときに生成される一連の値を予測することができるようになります。Random.setSeed() を、汚染された整数引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は擬似ランダム数値生成機能のシードに使用する値を制御できるようになるため、Random.nextInt()、Random.nextShort()、Random.nextLong() へのコールにより生成されるか、Random.nextBoolean() により返されるか、または Random.nextBytes(byte[]) で設定される値 (通常は整数) のシーケンスを予想できるようになります。Random.setSeed() を、汚染された整数引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似ランダム数値生成機能のシードに使用する値を制御できるようになるため、Random.nextInt()、Random.nextLong()、Random.nextDouble() へのコールにより生成されるか、Random.nextBoolean() により返されるか、または Random.nextBytes(ByteArray) で設定される値 (通常は整数) のシーケンスを予想できるようになります。random.randint() など) を、汚染された引数を使用してコールしないでください。このようなコールを行うと、攻撃者が疑似ランダム数値の生成機能のシードに使用される値を制御できるようになります。したがって、疑似ランダム数値生成機能へのコールによって作成された値のシーケンス (通常は整数) を攻撃者が予測できるようになります。Random.setSeed() を、汚染された整数引数を使用してコールしないでください。そのようなコールを行うと、攻撃者は疑似ランダム数値生成機能のシードに使用する値を制御できるようになるため、Random.nextInt()、Random.nextShort()、Random.nextLong() へのコールにより生成されるか、Random.nextBoolean() により返されるか、または Random.nextBytes(byte[]) で設定される値 (通常は整数) のシーケンスを予想できるようになります。
...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...
HttpResponse オブジェクトである res は、暗号化も認証もされていないチャネルを介して送信されるため、危険にさらされる可能性があります。
var account = new CloudStorageAccount(storageCredentials, false);
...
String url = 'http://10.0.2.2:11005/v1/key';
Response response = await get(url, headers: headers);
...
response は、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。
helloHandler := func(w http.ResponseWriter, req *http.Request) {
io.WriteString(w, "Hello, world!\n")
}
http.HandleFunc("/hello", helloHandler)
log.Fatal(http.ListenAndServe(":8080", nil))
URL url = new URL("http://www.android.com/");
HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
try {
InputStream in = new BufferedInputStream(urlConnection.getInputStream());
readStream(in);
...
}
instream は、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。
var http = require('http');
...
http.request(options, function(res){
...
});
...
http.IncomingMessage オブジェクトの res は、暗号化されていない未認証のチャネルを介して配信されるので危険にさらされています。
NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];
...
stream_socket_enable_crypto($fp, false);
...
require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...
in は、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。
val url = Uri.from(scheme = "http", host = "192.0.2.16", port = 80, path = "/")
val responseFuture: Future[HttpResponse] = Http().singleRequest(HttpRequest(uri = url))
responseFutureは、暗号化されていない、未認証のチャネルから受け取るため、危険に晒されています。
let USER_URL = "http://localhost:8080/igoat/user"
let request : NSMutableURLRequest = NSMutableURLRequest(URL:NSURL(string:USER_URL))
let conn : NSURLConnection = NSURLConnection(request:request, delegate:self)