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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。
...
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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。
...
CMyRecordset rs(&dbms);
rs.PrepareSQL("SELECT * FROM invoices WHERE id = ?");
rs.SetParam_int(0,atoi(r.Lookup("invoiceID").c_str()));
rs.SafeExecuteSQL();
...
id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。
...
ACCEPT ID.
EXEC SQL
DECLARE C1 CURSOR FOR
SELECT INVNO, INVDATE, INVTOTAL
FROM INVOICES
WHERE INVOICEID = :ID
END-EXEC.
...
ID 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。deleteDatabase 方法可能会允许攻击者删除任何数据库。
...
id := request.FormValue("invoiceID")
query := "SELECT * FROM invoices WHERE id = ?";
rows, err := db.Query(query, 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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。Example 1 以适应 Android 平台。
...
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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。
...
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 = $_POST['id'];
$query = "SELECT * FROM invoices WHERE id = ?";
$stmt = $mysqli->prepare($query);
$stmt->bind_param('ss',$id);
$stmt->execute();
...
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 = request.POST['id']
c = db.cursor()
stmt = c.execute("SELECT * FROM invoices WHERE id = %s", (id,))
...
id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。
...
id = req['invoiceID'].respond_to(:to_int)
query = "SELECT * FROM invoices WHERE id=?"
stmt = conn.prepare(query)
stmt.execute(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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。
...
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 = 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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。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 中的代码可以使攻击者通过修改注册表项 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从注册表中读取的值，因此如果攻击者能够控制注册表项 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
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 shell，从而可以通过调用一次 CALL 'SYSTEM' 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& 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 中的代码可以使攻击者通过修改配置文件 configStream 的内容以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从该文件读取的值，因此如果攻击者可以控制这些值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
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 shell，从而可以通过调用一次 fscommnd() 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& 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 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
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 shell，从而可以通过调用一次 Process.Start() 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& 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 权限运行的，所以也会以 root 权限来调用 system()。如果用户指定了标准的文件名，那么调用就可按照您期望的方式进行。然而，如果攻击者传递了一个 ";rm -rf /" 形式的字符串，由于缺少参数，对 system() 的调用无法成功地执行 cat，然后程序会逐层删除根分区中的内容。$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 的恶意二进制代码，并在 shell 提示符中执行 CGI 脚本。而且，因为程序已按照 setuid root 安装，所以攻击者的 make 目前会在 root 的权限下执行。_spawn() 家族中的某项函数调用 CreateProcess() 时，如果可执行文件或路径中存在空格，必须谨慎操作。
...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...
CreateProcess() 解析空格时，操作系统尝试执行的第一个可执行文件将是 Program.exe，而不是 MyApplication.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 的恶意二进制代码并通过 Shell 提示符执行 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 中的嵌入空间，仍然可能有 Shell 元字符（例如 &&）嵌入在这两者之一。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 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 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 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
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 shell，从而可以通过调用一次 Runtime.exec() 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& 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 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
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参数是否存在之外，没有对其进行任何验证。在调用该 shell 之后，就可能允许执行多个命令，并且由于该应用程序的特性，该应用程序将会使用与数据库进行交互的必要权限来运行，这就意味着攻击者注入的任何命令都会通过这些权限来运行。/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 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...
backuptype参数进行任何验证。通常情况下 Runtime.exec() 函数不会执行多条命令，但在这种情况下，程序会首先运行 cmd.exe shell，从而可以通过调用一次 Runtime.exec() 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& 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 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
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 shell，从而可以通过调用一次 Runtime.exec() 来执行多条命令。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& 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 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...
backuptype参数进行任何验证。在通过 Kernel.spawn 调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& 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 中的代码可以使攻击者通过修改系统属性 APPHOME 以指向包含恶意版本 INITCMD 的其他路径来提高自己在应用程序中的权限，继而随心所欲地执行命令。由于程序不会验证从环境中读取的值，因此如果攻击者能够控制系统属性 APPHOME 的值，他们就能欺骗应用程序去运行恶意代码，从而取得系统控制权。rman 实用程序的批处理文件封装器来启动 Oracle 数据库备份，然后运行一个 cleanup.bat 脚本来删除一些临时文件。脚本 rmanDB.bat 接受单个命令行参数，该参数指定了要执行的备份类型。由于访问数据库受限，所以应用程序执行备份需要具有较高权限的用户。
...
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参数进行任何验证。在调用该 shell 之后，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:\\dbms\\*.*" 的字符串，那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性，运行该应用程序需要具备与数据库进行交互所需的权限，这就意味着攻击者注入的任何命令都将通过这些权限得以运行。/var/yp 目录中运行 make 命令。
...
$result = shell_exec("make");
...
Runtime.exec() 调用前清除它的环境变量。如果攻击者能够修改 $PATH 变量，把它指向名为 make 恶意二进制代码，程序就会在其指定的环境下执行，然后加载该恶意二进制代码，而非原本期望的代码。由于应用程序自身的特性，运行该应用程序需要具备执行系统操作所需的权限，这意味着攻击者会利用这些权限执行自己的 make，从而可能导致攻击者完全控制系统。isSecure 参数设置为 true。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该安全标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。isSecure 参数设置为 true。
...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...
isSecure 参数，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接探查网络流量对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。Secure 标记设置为 true。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。Secure 属性的情况下，为响应添加了一个 Cookie。
...
HttpCookie cookie = new HttpCookie("emailCookie", email);
Response.AppendCookie(cookie);
...
Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接截取网络信息流对攻击者而言十分简单，因此通过 HTTP 发送 cookie（特别是具有会话 ID 的 cookie）可能会危及应用程序安全。Secure 标记设置为 true。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或会话标识符，或带有 CSRF 标记，那么该标记尤其重要。Secure 标记的情况下将 cookie 添加到响应中。
cookie := http.Cookie{
Name: "emailCookie",
Value: email,
}
http.SetCookie(response, &cookie)
...
Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。Secure 标记设置为 true。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。use-secure-cookie 属性允许 remember-me Cookie 通过未加密的传输发送出去。
<http auto-config="true">
...
<remember-me use-secure-cookie="false"/>
</http>
Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接监听网络通信对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。Secure 标记设置为 true。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。Secure 属性设置为 true 的情况下，为响应添加了一个 Cookie。
res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});
Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接截取网络信息流对攻击者而言十分简单，因此通过 HTTP 发送 cookie（特别是具有会话 ID 的 cookie）可能会危及应用程序安全。NSHTTPCookieSecure 标记设置为 TRUE。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。Secure 标记的情况下，为响应添加了一个 Cookie。
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接截取网络信息流对攻击者而言十分简单，因此通过 HTTP 发送 cookie（特别是具有会话 ID 的 cookie）可能会危及应用程序安全。Secure 标记设置为 true。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。Secure 标记的情况下将 cookie 添加到响应中。
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。Secure 标记设置为 True。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 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。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。Secure 标记的情况下，为响应添加了一个 Cookie。
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))
Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接监听网络通信对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。NSHTTPCookieSecure 标记设置为 TRUE。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。Secure 标记的情况下，为响应添加了一个 Cookie。
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接监听网络通信对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。HttpOnly 标记设置为 true。HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证令牌。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。HttpOnly 属性的情况下创建一个 Cookie。
HttpCookie cookie = new HttpCookie("emailCookie", email);
Response.AppendCookie(cookie);
HttpOnly 标记设置为 true。HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证标记。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。HttpOnly 属性的情况下创建一个 Cookie。
cookie := http.Cookie{
Name: "emailCookie",
Value: email,
}
...
HttpOnly 标记设置为 true。HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 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 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证令牌。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。httpOnly 属性的情况下创建一个 Cookie。
res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});
HttpOnly 标记设置为 true。HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 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 攻击通常会访问 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 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证令牌。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。HttpOnly 属性的情况下创建一个 Cookie。
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, httpOnly = false))
.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上部署了一个安全应用程序，当用户登录时，该应用程序将使用域“.example.com”设置会话 ID Cookie。
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Domain = ".example.com";
http://insecure.example.com/ 上部署了另一个不太安全的应用程序，并且它存在 Cross-Site Scripting 漏洞。 任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户都面临着暴露来自 http://secure.example.com 的会话 Cookie 的风险。insecure.example.com 来创建自己范围过大的 Cookie，以覆盖来自 secure.example.com 的 Cookie，从而执行 Cookie Poisoning 攻击。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域“.example.com”设置会话 ID Cookie。
cookie := http.Cookie{
Name: "sessionID",
Value: getSessionID(),
Domain: ".example.com",
}
...
http://insecure.example.com/ 上部署了另一个不太安全的应用程序，并且它存在 Cross-Site Scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户都面临着暴露来自 http://secure.example.com 的会话 Cookie 的风险。insecure.example.com 进行“Cookie Poisoning 攻击”，创建自己范围过大的 Cookie，并覆盖 Secure.example.com 中的 Cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域“.example.com”设置会话 cookie。
setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);
http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行“Cookie 篡改攻击”，创建自己范围过大的 cookie，并覆盖 secure.example.com 中的 cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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://insecure.example.com 的 http://secure.example.com 认证用户都面临着暴露来自 http://secure.example.com 的会话 Cookie 的风险。insecure.example.com 来创建自己范围过大的 Cookie，以覆盖来自 secure.example.com 的 Cookie，从而执行 Cookie Poisoning 攻击。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。/”）进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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，从而执行 Cookie Poisoning 攻击。/”，然而，这样做会使 Cookie 暴露在域名相同的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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 Poisoning 攻击”，创建自己范围过大的 Cookie，并覆盖 /MyForum 中的 Cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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 篡改攻击”，创建自己范围过大的 cookie，并覆盖 /MyForum 中的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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，从而执行 Cookie Poisoning 攻击。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。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 poisoning 攻击，创建自己范围过大的 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()。该 pageAction() 方法在访问页面 URL 时执行，且服务器不会检查是否存在反 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 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。
<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 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。
<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 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。buyItem 控制器方法的 CSRF 保护。
+ nocsrf
POST /buyItem controllers.ShopController.buyItem
shop.com 上具有活动会话时被诱骗访问了恶意网页，她会在毫不知情的情况下为攻击者购买物品。 这就是 CSRF 攻击。 正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。 任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。 攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。
<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 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。
...
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
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 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
name 的值定义明确（如仅包含字母数字字符），该代码就能正常运行，但不会执行与检查恶意数据有关的任何任务。即使从数据库中读取，也应对值进行适当的验证，因为数据库的内容可以源自用户提供的数据。这样，攻击者就可以在用户的 Web 浏览器中执行恶意命令，而无需像在 Reflected XSS 中那样与受害者进行交互。这种类型的攻击（称为 Stored XSS 或 Persistent）可能极难发现，因为数据被间接提供给易受攻击的函数；另外，由于这种攻击可能影响多个用户，因而会造成巨大的影响。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿的用户都会执行这些恶意代码。username，并将其显示给用户。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username 包含元字符或源代码，则其将由 Web 浏览器执行。Example 1 中所示，数据库或其他数据存储可能会向应用程序提供危险数据，这些数据将包含在动态内容中。从攻击者的角度看，存储恶意内容的最佳位置莫过于可供所有用户（特别是具有较高权限的用户）访问的区域，因为这些用户更有可能处理敏感信息或执行重要操作。Example 2 中所示，系统从 HTTP 请求中读取数据，并在 HTTP 响应中返回数据。如果攻击者可以将危险内容发送给易受攻击的 Web 应用程序，随后将其反馈给用户并在用户浏览器中执行，则会发生 Reflected XSS。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布的或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 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 中所示，应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 3 和Example 4 中所示，系统会从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Stored XSS，它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并且更可能使此攻击影响到多个用户。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。EID，并将其显示给用户。
...
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 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。当攻击者有以下行为时，将会发生 Stored XSS 漏洞利用： Example 2 中所示，系统从 HTML 表单中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Example 1 中所示，如果 Form.eid 只包含标准的字母数字文本，此代码将会正确运行。如果 Form.eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。user，并将其显示给用户。
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”，以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
<% 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 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
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 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并在 servlet 响应中将值显示给该用户。
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 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 3 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。myapp://input_to_the_application) 的自定义 URL 方案的文本部分。然后，该 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 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，数据会直接从自定义 URL 方案中读取，并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行，就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是，将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心，攻击者借此诱骗受害者访问指向易受攻击应用程序的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
...
-- 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 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。eid，并将其显示给用户。
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
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 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 inputTextField 中的文本包括元字符或源代码，那么可以由 Web 浏览器在显示 HTTP 响应的过程中以代码方式执行输入。myapp://input_to_the_application) 的自定义 URL 方案的文本部分。然后，该 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 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从用户可控的 UI 组件中直接读取数据，并反馈到 HTTP 响应中。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。cl_http_utility=>escape_html）能避免一部分 cross-site scripting 攻击，但不能完全避免。根据数据出现的上下文，除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外，其他字符可能具有元意。依靠此类编码函数模块等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击，并且可能允许攻击者注入恶意代码，并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文，因此即便进行了编码，Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果，并将其显示为 Cross-Site Scripting: Poor Validation 问题。eid，对其进行 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，对其进行 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent 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 解析器）进行解析，因此需要编码两次。这样，攻击者就可以在用户的 Web 浏览器中执行恶意命令，而无需像在 Reflected XSS 中那样与受害者进行交互。这种类型的攻击（称为 Stored XSS 或 Persistent）可能极难发现，因为数据被间接提供给易受攻击的函数；另外，由于这种攻击可能影响多个用户，因而会造成巨大的影响。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿的用户都会执行这些恶意代码。username，并将其显示给用户。
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
username 包含元字符或源代码，则其将由 Web 浏览器执行。同样，在此示例中，使用 HTMLENCODE 不足以防止 XSS 攻击，因为该变量由 Javascript 解析器处理。Example 1 中所示，数据库或其他数据存储可能会向应用程序提供危险数据，这些数据将包含在动态内容中。从攻击者的角度看，存储恶意内容的最佳位置莫过于可供所有用户（特别是具有较高权限的用户）访问的区域，因为这些用户更有可能处理敏感信息或执行重要操作。Example 2 中所示，系统从 HTTP 请求中读取数据，并在 HTTP 响应中返回数据。如果攻击者可以将危险内容发送给易受攻击的 Web 应用程序，随后将其反馈给用户并在用户浏览器中执行，则会发生 Reflected XSS。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布的或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 和Example 2 中所示，系统会从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 3 和Example 4 中所示，应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。text 参数，对其进行 HTML 编码，并将其显示在脚本标签之间的警报框中。
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
text 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 text 具有单引号、圆括号和分号，则会结束 alert 文本框，之后将执行代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。user，并将其显示给用户。
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”，以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。escapeXml="true" 属性（默认设置）的 <c:out/> 标签可以避免一部分 Cross-Site Scripting 攻击，但不能完全避免。根据数据出现的上下文，除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外，其他字符可能具有元意。依靠此类编码构造等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击，并且可能允许攻击者注入恶意代码，并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文，因此即便应用了编码，Fortify Static Code Analyzer（Fortify 静态代码分析器）仍会报告发现跨站点脚本攻击，并将其显示为“Cross-Site Scripting: Poor Validation”问题。eid，并通过 <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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 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 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 3 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。eid，对其进行转义并显示给用户。
<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（Fortify 静态代码分析器）仍会报告发现跨站点脚本攻击，并将其显示为“Cross-Site Scripting: Poor Validation”问题。eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 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 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 3 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。myapp://input_to_the_application) 的自定义 URL 方案的文本部分。然后，该 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 编码影响的环境中输入信息。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，数据会直接从自定义 URL 方案中读取，并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行，就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是，将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心，攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。htmlspecialchars() 或 htmlentities()）能避免一部分 cross-site scripting 攻击，但不能完全避免。根据数据出现的上下文，除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外（仅当已设置 ENT_QUOTES 时），其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击，并且可能允许攻击者注入恶意代码，并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文，因此即便进行了编码，Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果，并将其显示为 Cross-Site Scripting: Poor Validation 问题。text 参数，使用 HTML 加以编码，并将该参数显示在脚本标签之间的警报框中。
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
text 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 text 具有单引号、圆括号和分号，则会结束 alert 文本框，之后将执行代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。eid，对其进行 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，对其进行 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，对其进行 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并将其显示给用户。
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 方案的文本部分。然后，该 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 编码影响的环境中输入信息。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 inputTextField 中的文本包括元字符或源代码，那么可以由 Web 浏览器在显示 HTTP 响应的过程中以代码方式执行输入。Example 1 中所示，数据会直接从自定义 URL 方案中读取，并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行，就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是，将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心，攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 3 中所示，目标应用程序外部的源使用目标应用程序的自定义 URL 方案发出 URL 请求，该 URL 请求中未经验证的数据随后作为可信数据读回应用程序并包含在动态内容中。eid，对其进行 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并将其显示给用户。
...
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并将其显示给用户。
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent 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 的值定义明确（如仅包含字母数字字符），该代码就能正常运行，但无法检查是否存在恶意数据。即使从数据库中读取，也应对该值进行适当的验证，因为数据库的内容可能源自用户提供的数据。这样，攻击者就可以在用户的 Web 浏览器中执行恶意命令，而无需像在 Reflected XSS 中那样与受害者进行交互。这种类型的攻击称为 Stored XSS 或 Persistent XSS，它可能极其隐蔽，因为数据会被间接提供给易受攻击的函数；另外，由于这种攻击可能影响多个用户，因而会造成巨大的影响。XSS 漏洞利用首先会在网站上为访问者提供一个“留言簿”。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中读取数据，并在 HTTP 响应中返回数据。如果攻击者可以将危险内容发送给易受攻击的 Web 应用程序，随后将其反馈给用户并在用户浏览器中执行，则会发生 Reflected XSS。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布的或通过电子邮件直接发送给受害者的 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 和Example 2 中所示，系统会从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 3 和Example 4 中所示，应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。EID，并将其显示给用户。
...
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Stored XSS，它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并且更可能使此攻击影响到多个用户。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTML 表单中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。当攻击者有以下行为时，将会发生 Stored XSS 漏洞利用： eid，并将其显示给用户。
<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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。user，并将其显示给用户。
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”，以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并将其显示给用户。
<% 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 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 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 3 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。eid，并将其显示给用户。
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并在 servlet 响应中将值显示给该用户。
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 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 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 3 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。myapp://input_to_the_application) 的自定义 URL 方案的文本部分。然后，该 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，数据会直接从自定义 URL 方案中读取，并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行，就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是，将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心，攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并将其显示给用户。
<?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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并将其显示给用户。
...
-- 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并将其显示给用户。
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并将其显示给用户。
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并将其显示给用户。
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 中的文本包括元字符或源代码，那么可以由 Web 浏览器在显示 HTTP 响应的过程中以代码方式执行输入。myapp://input_to_the_application) 的自定义 URL 方案的文本部分。然后，该 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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从用户可控的 UI 组件中直接读取数据，并反馈到 HTTP 响应中。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，目标应用程序外部的源使用目标应用程序的自定义 URL 方案发出 URL 请求，该 URL 请求中未经验证的数据随后作为可信数据读回应用程序并包含在动态内容中。Example 3 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，并将其显示给用户。
...
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 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent 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 响应的 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 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 响应将被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
HttpResponse.AddHeader() 方法时将其转换为 %0d、%0a 和 %00。如果您正在使用的最新的 .NET 框架不允许使用新行字符设置头文件，则应用程序便不会容易受到 HTTP Response Splitting 攻击。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
author，并在一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并且把它设置到一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1/1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 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 响应的 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 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 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 响应将会拆分为如下形式的两个响应：
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
header() 函数时，最新版本的 PHP 将生成一个警告并停止创建头文件。如果您的 PHP 版本能够阻止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author 的名字，并在发往站点另一部分的 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 响应就会被分割成以下形式的两个响应：
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 或 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 响应将会拆分为如下形式的两个响应：
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。author，并将其置于一个 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 响应将被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
Example 1 以适应 Android 平台。Cross-User Defacement：攻击者可以向一个易受攻击的服务器发出一个请求，导致服务器创建两个响应，其中第二个响应可能会被曲解为对其他请求的响应，而这一请求很可能是与服务器共享相同 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 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
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 响应就会被分割成以下形式的两个响应：
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
IllegalArgumentException。 如果您的应用程序服务器能够防止设置带有换行符的标头，则其具备对 HTTP Response Splitting 的防御能力。 然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。IllegalArgumentException。如果您的应用程序服务器能够防止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。然而，单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击，因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author，并将其置于一个 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 响应就会被分割成以下形式的两个响应：
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），就会更安全些。
string GenerateReceiptURL(string baseUrl) {
Random Gen = new Random();
return (baseUrl + Gen.Next().toString() + ".html");
}
Random.Next() 函数为它生成的收据页面生成“唯一”的标识符。由于 Random.Next() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。
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，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器，就会更安全些。
<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>
Rand() 函数为它生成的收据页面生成“唯一”的标识符。由于 Rand() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。
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），就会更安全些。
function genReceiptURL (baseURL){
var randNum = Math.random();
var receiptURL = baseURL + randNum + ".html";
return receiptURL;
}
Math.random() 函数为它生成的收据页面生成“唯一”的标识符。由于 Math.random() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。
fun GenerateReceiptURL(baseUrl: String): String {
val ranGen = Random(Date().getTime())
return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}
Random.nextInt() 函数为它所生成的收据页面生成独特的标识符。由于 Random.nextInt() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。
function genReceiptURL($baseURL) {
$randNum = rand();
$receiptURL = $baseURL . $randNum . ".html";
return $receiptURL;
}
rand() 函数为它生成的收据页面生成“唯一”的标识符。由于 rand() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。
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，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器，就会更安全些。
def genReceiptURL(self,baseURL):
randNum = random.random()
receiptURL = baseURL + randNum + ".html"
return receiptURL
rand() 函数为它生成的收据页面生成“唯一”的标识符。由于 rand() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。
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），就会更安全些。
sqlite3_randomness(10, &reset_token)
...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...
Rnd() 函数为它生成的收据页面生成“唯一”的标识符。由于 Rnd() 是统计学的 PRNG，攻击者很容易猜到其生成的字符串。尽管收据系统的底层设计并不完善，但若使用不会生成可预测收据标识符的随机数生成器（如密码学的 PRNG），就会更安全些。CL_ABAP_RANDOM 类或其变体）使用特定常数值作为种子，则通过 GET_NEXT、INT 和通过可返回或分配值的类似方法返回的值对可以收集大量 PRNG 输出的攻击者来说是可预测的。random_gen1 来预测对象 random_gen2 生成的值。
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 = var2rand()）使用特定值作为种子（使用类似 srand(unsigned int) 的函数），则通过 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 对象 randomGen1 来预测 Random 对象 randomGen2 生成的值。
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 对象 randomGen1 来预测 Random 对象 randomGen2 生成的值。
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 对象 randomGen1 来预测 Random 对象 randomGen2 生成的值。
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)