...
lo_client = cl_apc_tcp_client_manager=>create( i_host = host
i_port = port
i_frame = lv_frame
i_protocol = protocol
i_ssl_id = ssl_id
i_event_handler = lo_event_handler ).
" initiate the connection setup, successful connect leads to execution of ON_OPEN
lo_client->connect( ).
...
範例 2：在正常條件下，以下修正會適當地關閉通訊端以及任何相關的串流。但是，如果對螢幕讀取或寫入資料時發生異常，通訊端物件就不會關閉。如果經常發生此狀況，系統就會耗盡所有通訊端，並且無法處理任何其他連線。
private void echoSocket(String host, int port) throws UnknownHostException, SocketException, IOException
{
Socket sock = new Socket(host, port);
BufferedReader reader = new BufferedReader(new InputStreamReader(sock.getInputStream()));
while ((String socketData = reader.readLine()) != null) {
System.out.println(socketData);
}
}
private void echoSocket(String host, int port) throws UnknownHostException, SocketException, IOException
{
Socket sock = new Socket(host, port);
BufferedReader reader = new BufferedReader(new InputStreamReader(sock.getInputStream()));
while ((String socketData = reader.readLine()) != null) {
System.out.println(socketData);
}
sock.close();
}
@GetMapping("/ai")
String generation(String userInput) {
return this.chatClient.prompt()
.user(userInput)
.call()
.content();
}
message 擷取回應，並顯示給使用者。
const openai = new OpenAI({
apiKey: ...,
});
const chatCompletion = await openai.chat.completions.create(...);
message = res.choices[0].message.content
console.log(chatCompletion.choices[0].message.content)
val chatCompletionRequest = ChatCompletionRequest(
model = ModelId("gpt-3.5-turbo"),
messages = listOf(...)
)
val completion: ChatCompletion = openAI.chatCompletion(chatCompletionRequest)
response.getOutputStream().print(completion.choices[0].message)
message 擷取回應，並顯示給使用者。
client = openai.OpenAI()
res = client.chat.completions.create(...)
message = res.choices[0].message.content
self.writeln(f"<p>{message}<\p>")
chatService.createCompletion(
text,
settings = CreateCompletionSettings(...)
).map(completion =>
val html = Html(completion.choices.head.text)
Ok(html) as HTML
)
...
MAX_PATH 位元組長度的緩衝區，但是你應該檢查每一個函數的文件資料。如果緩衝區不夠大，無法儲存操作的結果，就會發生 Buffer overflow。
char *createOutputDirectory(char *name) {
char outputDirectoryName[128];
if (getCurrentDirectory(128, outputDirectoryName) == 0) {
return null;
}
if (!PathAppend(outputDirectoryName, "output")) {
return null;
}
if (!PathAppend(outputDirectoryName, name)) {
return null;
}
if (SHCreateDirectoryEx(NULL, outputDirectoryName, NULL)
!= ERROR_SUCCESS) {
return null;
}
return StrDup(outputDirectoryName);
}
output\<name>」的目錄，並且回傳該名稱的堆積分配副本。對於大多數的目前目錄值和名稱參數，此函數都能夠正常執行。但是如果 name 參數特別長，第二個 PathAppend() 呼叫就可能會溢出 outputDirectoryName 緩衝區，因為這個緩衝區比 MAX_PATH 位元組小。umask() 引數指定的 mask 總是容易與 chmod() 引數混淆。umask() 線上手冊以錯誤陳述式開頭：chmod() 的用法，即使用者提供的引數指定某些位元在指定的檔案上啟用，但事實上 umask() 的行為恰恰相反： umask() 將 umask 設為 ~mask & 0777。umask() 線上手冊接下來描述了對於 umask() 的正確使用方式：open() 使用 umask 來為新建立的檔案設定初始化檔案權限。 特別是，umask 的權限關閉了傳送給 open(2) 的 mode 引數 (例如，一般的 umask 預設值 022 會讓新建立的檔案擁有 0666 & ~022 = 0644 = rw-r--r-- 權限，而在一般情況下，應將 mode 指定為 0666)。」
...
struct stat output;
int ret = stat(aFilePath, &output);
// error handling omitted for this example
struct timespec accessTime = output.st_atime;
...
umask() 引數指定的 mask 總是容易與 chmod() 引數混淆。umask() 線上手冊以錯誤指令開頭：chmod() 的用法，即使用者指定引數中某些位元值來控制檔案存取權限，但事實上 umask() 做的恰恰相反：umask() 將 umask 設為 ~mask & 0777。umask() 線上手冊接下來描述了對於 umask() 的正確使用方式：transactionId 寫入至應用程式文件目錄中的暫存檔案：
...
//get the documents directory:
let documentsPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0]
//make a file name to write the data to using the documents directory:
let fileName = NSString(format:"%@/tmp_activeTrans.txt", documentsPath)
// write data to the file
let transactionId = "TransactionId=12341234"
transactionId.writeToFile(fileName, atomically:true)
...
<SCRIPT>
var response = llm.invoke(user_prompt);
...
document.write(response);
</SCRIPT>
<a href="http://www.example.com/index.html"/>
www.example.com 來載入自己的網頁。register_globals 選項，會造成 PHP 對所有的 EGPCS (Environment、GET、POST、Cookie 和 Server) 變數進行全域註冊，使得任何使用者在任何 PHP 程式中都可存取這些變數。如果程式設計師在撰寫程式時啟用此選項，或多或少都會導致察覺不到它們所依賴的原始值，這會導致在正常的環境中產生非預期的運作方式，使程式容易遭受惡意環境中的攻擊者攻擊。由於知道 register_globals 所隱含的安全問題，在 PHP 4.2.0 中該選項的預設為關閉，且在 PHP 6 中捨棄且移除該選項。$username 的值來自伺服器控制的階段作業，但是攻擊者可能會為 $username 提供惡意值來取代要求參數。如果啟用 register_globals，此程式碼會在其所產生的動態 HTML 內容中包含由攻擊者傳遞的惡意值。
<?php
if (isset($username)) {
echo "Hello <b>$username</b>";
} else {
echo "Hello <b>Guest</b><br />";
echo "Would you like to login?";
}
?>
...
CALL FUNCTION 'FTP_VERSION'
...
IMPORTING
EXEPATH = p
VERSION = v
WORKING_DIR = dir
RFCPATH = rfcp
RFCVERSION = rfcv
TABLES
FTP_TRACE = FTP_TRACE.
WRITE: 'exepath: ', p, 'version: ', v, 'working_dir: ', dir, 'rfcpath: ', rfcp, 'rfcversion: ', rfcv.
...
string cs="database=northwind;server=mySQLServer...";
SqlConnection conn=new SqlConnection(cs);
...
Console.Writeline(cs);
Example 1 中，洩漏的資訊可能會暗示有關作業系統類型、系統上安裝的應用程式，以及管理員在配置程式時所花費的努力等資訊。
char* path = getenv("PATH");
...
fprintf(stderr, "cannot find exe on path %s\n", path);
Example 1 中，搜索路徑可能會暗示有關作業系統類型、系統上安裝的應用程式，以及管理員在配置程式時所花費的努力等資訊。
print(Platform.environment["HOME"]);
Example 1 中，洩漏的資訊可能會暗示有關作業系統類型、系統上安裝的應用程式，以及管理員在配置程式時所花費的努力等資訊。
path := os.Getenv("PATH")
...
log.Printf("Cannot find exe on path %s\n", path)
Example 1 中，搜索路徑可能會暗示有關作業系統類型、系統上安裝的應用程式，以及管理員在配置程式時所花費的努力等資訊。
try {
...
} catch (Exception e) {
e.printStackTrace();
}
Example 1 中，洩漏的資訊可能會暗示有關作業系統類型、系統上安裝的應用程式，以及管理員在配置程式時所花費的努力等資訊。
...
try {
...
} catch (Exception e) {
String exception = Log.getStackTraceString(e);
Intent i = new Intent();
i.setAction("SEND_EXCEPTION");
i.putExtra("exception", exception);
view.getContext().sendBroadcast(i);
}
...
...
public static final String TAG = "NfcActivity";
private static final String DATA_SPLITTER = "__:DATA:__";
private static final String MIME_TYPE = "application/my.applications.mimetype";
...
TelephonyManager tm = (TelephonyManager)Context.getSystemService(Context.TELEPHONY_SERVICE);
String VERSION = tm.getDeviceSoftwareVersion();
...
NfcAdapter nfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (nfcAdapter == null)
return;
String text = TAG + DATA_SPLITTER + VERSION;
NdefRecord record = new NdefRecord(NdefRecord.TNF_MIME_MEDIA,
MIME_TYPE.getBytes(), new byte[0], text.getBytes());
NdefRecord[] records = { record };
NdefMessage msg = new NdefMessage(records);
nfcAdapter.setNdefPushMessage(msg, this);
...
$log.log(exception);
try {
...
} catch (e: Exception) {
e.printStackTrace()
}
Example 1 中，洩漏的資訊可能會暗示有關作業系統類型、系統上安裝的應用程式，以及管理員在配置程式時所花費的努力等資訊。
...
try {
...
} catch (e: Exception) {
val exception = Log.getStackTraceString(e)
val intent = Intent()
intent.action = "SEND_EXCEPTION"
intent.putExtra("exception", exception)
view.context.sendBroadcast(intent)
}
...
...
companion object {
const val TAG = "NfcActivity"
private const val DATA_SPLITTER = "__:DATA:__"
private const val MIME_TYPE = "application/my.applications.mimetype"
}
...
val tm = Context.getSystemService(Context.TELEPHONY_SERVICE) as TelephonyManager
val VERSION = tm.getDeviceSoftwareVersion();
...
val nfcAdapter = NfcAdapter.getDefaultAdapter(this)
val text: String = "$TAG$DATA_SPLITTER$VERSION"
val record = NdefRecord(NdefRecord.TNF_MIME_MEDIA, MIME_TYPE.getBytes(), ByteArray(0), text.toByteArray())
val records = arrayOf(record)
val msg = NdefMessage(records)
nfcAdapter.setNdefPushMessage(msg, this)
...
...
NSString* deviceID = [[UIDevice currentDevice] name];
[deviceID writeToFile:@"/dev/stderr" atomically:NO encoding:NSUTF8StringEncoding error:nil];
...
<?php
...
echo "Server error! Printing the backtrace";
debug_print_backtrace();
...
?>
Example 1 中，洩漏的資訊可能會暗示有關作業系統類型、系統上安裝的應用程式，以及管理員在配置程式時所花費的努力等資訊。
...
begin
log = Logger.new(STDERR)
...
rescue Exception
log.info("Exception: " + $!)
...
end
Example 1 中，洩漏的資訊可能會暗示有關作業系統類型、系統上安裝的應用程式，以及管理員在配置程式時所花費的努力等資訊。當然，Example 1 中的另一個問題是救援根 Exception 而非特定類型或錯誤/異常，表示它將捕捉到會潛在造成其他不重要負面影響的所有異常。
...
public struct StderrOutputStream: OutputStreamType {
public static let stream = StderrOutputStream()
public func write(string: String) {fputs(string, stderr)}
}
public var errStream = StderrOutputStream.stream
let deviceID = UIDevice.currentDevice().name
println("Device ID: \(deviceID)", &errStream)
...
...
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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
name 的值進行明確界定時 (例如，僅英數字元)，此程式碼會正常運作，但無法檢查惡意資料。即使該值讀取自資料庫，也應該對其進行適當驗證，因為資料庫的內容可能源自於使用者提供的資料。這樣一來，攻擊者可以在使用者的網頁瀏覽器中執行惡意指令，而無需與受害者進行互動 (類似於 Reflected XSS)。此類攻擊稱為 Stored XSS (或 Persistent XSS)，可能非常難以偵測，因為資料是以間接方式提供給易受攻擊的函數，並且由於影響多個使用者的可能性，此類攻擊的影響會更強烈。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。username，並向使用者顯示。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username 包含中繼字元或來源程式碼，則會由網頁瀏覽器執行。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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1 和 Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 3 和 Example 4 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這種類型的攻擊，被稱作 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。當攻擊者有以下情況時，Stored XSS 攻擊就會出現： Example 2 所述，會直接從 HTML 表單中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
name 值正常運作時，此範例中的程式碼也會正常運作，但如果該值不正常運作時，則會完全無法避免程式碼遭受攻擊。這個程式碼之所以較不危險，是因為 name 值是從資料庫中讀取的，且顯然是由應用程式管理這些值的內容。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。eid，並將其顯示給使用者。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Example 1 所述，如果 Form.eid 只包含標準英數字元，這個程式碼會正確地執行。如果 Form.eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果沒有對所有儲存在資料庫中的資料進行適當的輸入驗證，那麼攻擊者即可在使用者的網頁瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其極其隱蔽，會因為間接的資料儲存方式而難以辨別該威脅，並會提高影響多個使用者的可能性。XSS 弱點會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所示，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由網頁瀏覽器執行時，就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。eid，並將其向使用者顯示。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
Example 1 所述，如果 eid 只包含標準英數字元，這個程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 內執行。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 內執行。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 3 所述，應用程式以外的來源會在資料庫或是其他資料儲存區中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。name 值正常運作時，此程式碼也會正常運作，但如果該值不正常運作時，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。myapp://input_to_the_application) 並呼叫之。然後 URL 中不可信賴的資料便會被用來在 UIWebView 元件中攻擊 HTML 輸出。
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從自訂 URL 架構讀取資料，並反映於 UIWebView 回應內容中。當攻擊者誘使使用者提供危險內容給易受攻擊的 iOS 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。eid，並將 ID 顯示給使用者。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
Example 1 所述，如果 eid 只包含標準英數字元，這個程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 2 中的的 Rack::Request#params()，會同時看到 GET 和 POST 參數，所以可能容易受到各種類型的攻擊，而不是只會使惡意程式碼附加到 URL 而已。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 中的文字只包含標準英數字元，這個範例中的程式碼便會正常運作而不會有問題。如果 inputTextField 中的文字包括中繼字元或原始程式碼，那麼網路瀏覽器就會像顯示 HTTP 回應那樣，可能會將輸入當成程式碼來執行。myapp://input_to_the_application) 並呼叫之。然後 URL 中不可信賴的資料便會被用來在 UIWebView 元件中攻擊 HTML 輸出。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從使用者可控制的 UI 元件讀取資料，並在 HTTP 回應中傳回資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。eid，並向使用者顯示。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
Example 1 所述，如果 eid 只包含標準英數字元，這個程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。eid，並將識別碼顯示給使用者。
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
eid 只包含標準英數字元，則這個範例中的程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。username，並向使用者顯示。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username 包含中繼字元或來源程式碼，則會由網頁瀏覽器執行。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
Example 1 所述，對 name 的值進行明確界定時 (例如，僅英數字元)，此程式碼會正常運作，但無法檢查惡意資料。即使該值讀取自資料庫，也應該對其進行適當驗證，因為資料庫的內容可能源自於使用者提供的資料。這樣一來，攻擊者可以在使用者的網頁瀏覽器中執行惡意指令，而無需與受害者進行互動 (類似於 Reflected XSS)。此類攻擊稱為 Stored XSS (或 Persistent XSS)，可能非常難以偵測，因為資料是以間接方式提供給易受攻擊的函數，並且由於影響多個使用者的可能性，此類攻擊的影響會更強烈。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 和 Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這種類型的攻擊，被稱作 Stored XSS，是特別狡詐的，因為間接的資料儲存方式使得該威脅難以辨別，而且提高了該攻擊會影響到多個使用者的可能性。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTML 表單中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。當攻擊者有以下情況時，Stored XSS 攻擊就會出現： eid，並將其顯示給使用者。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Form.eid 只包含標準英數字元，則這個範例中的程式碼會正確地執行。如果 Form.eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果沒有對所有儲存在資料庫中的資料進行適當的輸入驗證，那麼攻擊者即可在使用者的網頁瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其極其隱蔽，會因為間接的資料儲存方式而難以辨別該威脅，並會提高影響多個使用者的可能性。XSS 弱點會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所示，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由網頁瀏覽器執行時，就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所示，應用程式會將危險資料儲存在資料庫或其他可信任的資料存放區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者執行需要權限許可的操作，或者取得存取使用者專屬敏感資料的權限。eid，並將其向使用者顯示。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid 只包含標準英數字元，則這個範例中的程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 內執行。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 內執行。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 3 所述，應用程式以外的來源會在資料庫或是其他資料儲存區中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。myapp://input_to_the_application) 並呼叫之。然後 URL 中不可信賴的資料便會被用來在 UIWebView 元件中攻擊 HTML 輸出。
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從自訂 URL 架構讀取資料，並反映於 UIWebView 回應內容中。當攻擊者誘使使用者提供危險內容給易受攻擊的 iOS 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的自訂架構 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊應用程式的 URL。應用程式將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含工作階段資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。eid，並將 ID 顯示給使用者。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
eid 只包含標準英數字元，則這個範例中的程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 中的文字只包含標準英數字元，這個範例中的程式碼便會正常運作而不會有問題。如果 inputTextField 中的文字包括中繼字元或原始程式碼，那麼網路瀏覽器就會像顯示 HTTP 回應那樣，可能會將輸入當成程式碼來執行。myapp://input_to_the_application) 並呼叫之。然後 URL 中不可信賴的資料便會被用來在 UIWebView 元件中攻擊 HTML 輸出。
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
Example 2 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從使用者可控制的 UI 元件讀取資料，並在 HTTP 回應中傳回資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所述，目標應用程式以外的來源會使用目標應用程式的自訂 URL 架構提出 URL 要求，之後來自此 URL 要求的未驗證資料會被當作信賴的資料讀回到應用程式，並會包含在動態內容中。Example 3 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。eid，並向使用者顯示。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
eid 只包含標準英數字元，則這個範例中的程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。cl_http_utility=>escape_html) 可防止部分，但不是所有的 Cross-Site Scripting 攻擊。根據資料出現的內容，以 HTML 編碼的基本 <、>、& 和 "，以及以 XML 編碼的 <、>、&、" 和 ' 以外的字元，可能會有中繼意義。依賴類似編碼函數模組等同於使用安全性較差的拒絕清單來防止 Cross-Site Scripting 攻擊，並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容，所以即使套用編碼，Fortify Secure Coding Rulepack 還是會報告 Cross-Site Scripting 發現，並將其顯示為 Cross-Site Scripting: Poor Validation 問題。eid，使用 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 解析器) 剖析，因此必須進行兩次編碼。這樣一來，攻擊者可以在使用者的網頁瀏覽器中執行惡意指令，而無需與受害者進行互動 (類似於 Reflected XSS)。此類攻擊稱為 Stored XSS (或 Persistent XSS)，可能非常難以偵測，因為資料是以間接方式提供給易受攻擊的函數，並且由於影響多個使用者的可能性，此類攻擊的影響會更強烈。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。username，並向使用者顯示。
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
username 包含中繼字元或來源程式碼，則會由網頁瀏覽器執行。此外，在此範例中，使用 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 和 Example 2 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 3 和 Example 4 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。text 參數，使用 HTML 加以編碼，並將該參數顯示在 Script 標籤之間的警示方塊中。
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
text 只包含標準英數字元，則這個範例中的程式碼會正確地執行。若 text 具有單引號、小括號及分號，則會結束 alert 文字方塊，並在此後執行程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果沒有對所有儲存在資料庫中的資料進行適當的輸入驗證，那麼攻擊者即可在使用者的網頁瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其極其隱蔽，會因為間接的資料儲存方式而難以辨別該威脅，並會提高影響多個使用者的可能性。XSS 弱點會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所示，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由網頁瀏覽器執行時，就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所示，應用程式會將危險資料儲存在資料庫或其他可信任的資料存放區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者執行需要權限許可的操作，或者取得存取使用者專屬敏感資料的權限。escapeXml="true" 屬性 (預設行為) 的 <c:out/> 標籤能夠防止部分，但非全部的 Cross-Site Scripting 攻擊。根據資料出現的內容，以 HTML 編碼的基本 <、>、& 和 "，以及以 XML 編碼的 <、>、&、" 和 ' 以外的字元，可能會有中繼意義。依賴這類編碼建構等同於使用安全性較差的拒絕清單來防止 Cross-Site Scripting 攻擊，並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容，所以即使已套用編碼，Fortify Static Code Analyzer 還是會報告 Cross-site scripting 發現，並將其顯示為 Cross-Site Scripting: Poor Validation 問題。eid，並透過 <c:out/> 標籤將其向使用者顯示。
Employee ID: <c:out value="${param.eid}"/>
eid 只包含標準英數字元，則這個範例中的程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 內執行。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。escapeXml="true" 屬性 (預設行為) 的 <c:out/> 標籤能夠防止部分，但非全部的 Cross-Site Scripting 攻擊。根據資料出現的內容，以 HTML 編碼的基本 <、>、& 和 "，以及以 XML 編碼的 <、>、&、" 和 ' 以外的字元，可能會有中繼意義。依賴這類編碼建構等同於使用安全性較差的拒絕清單來防止 Cross-Site Scripting 攻擊，並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容，所以即使已套用編碼，Fortify Static Code Analyzer 還是會報告 Cross-site scripting 發現，並將其顯示為 Cross-Site Scripting: Poor Validation 問題。eid 只包含標準英數字元，則這個範例中的程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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 內執行。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 3 所述，應用程式以外的來源會在資料庫或是其他資料儲存區中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。myapp://input_to_the_application) 並呼叫之。然後 URL 中不可信賴的資料便會被用來在 UIWebView 元件中攻擊 HTML 輸出。
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
...
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
[DefaultEncoder encodeForHTML:partAfterSlashSlash],
@"')\" />"];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:htmlPage baseURL:nil];
...
Example 1 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以較不危險，是因為 name 的值是從資料庫中讀取的，且為 HTML 編碼。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。攻擊者支援的攻擊可能會略過編碼字元或將輸入置於不受 HTML 編碼影響的環境中。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從自訂 URL 架構讀取資料，並反映於 UIWebView 回應內容中。當攻擊者誘使使用者提供危險內容給易受攻擊的 iOS 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的自訂架構 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊應用程式的 URL。應用程式將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含工作階段資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。htmlspecialchars()或htmlentities()) 可防止部分，但不是所有 Cross-Site Scripting 攻擊。根據資料出現的內容，以 HTML 編碼的基本 <、>、&和"，以及以 XML 編碼的 <、>、&、"和' (僅限在設定ENT_QUOTES時) 以外的字元，可能會有中繼意義。依賴這類編碼功能等同於使用安全性較差的拒絕清單來防止 Cross-Site Scripting 攻擊，並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容，所以即使套用編碼，並以 Cross-Site Scripting 來加以顯示，Fortify Secure Coding Rulepacks 還是會報告 Cross-Site Scripting 發現：Poor Validation 問題。text 參數，使用 HTML 加以編碼並將該參數顯示在 Script 標籤之間的警示方塊中。
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
text 只包含標準英數字元，則這個範例中的程式碼會正確地執行。若 text 具有單引號、小括號及分號，則會結束 alert 文字方塊，並在此後執行程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...
Example 1 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。myapp://input_to_the_application) 並呼叫之。然後 URL 中不可信賴的資料便會被用來在 UIWebView 元件中攻擊 HTML 輸出。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以較不危險，是因為 name 的值是從資料庫中讀取的，且為 HTML 編碼。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。攻擊者支援的攻擊可能會略過編碼字元或將輸入置於不受 HTML 編碼影響的環境中。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 中的文字只包含標準英數字元，這個範例中的程式碼便會正常運作而不會有問題。如果 inputTextField 中的文字包括中繼字元或原始程式碼，那麼網路瀏覽器就會像顯示 HTTP 回應那樣，可能會將輸入當成程式碼來執行。Example 1 所述，會直接從自訂 URL 架構讀取資料，並反映於 UIWebView 回應內容中。當攻擊者誘使使用者提供危險內容給易受攻擊的 iOS 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 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 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 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 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。text/htmlMIME 類型。因此，只有回應使用此 MIME 類型或任何其他也會強制瀏覽器以 HTML 呈現回應或可能會執行指令碼 (例如 SVG 影像 (image/svg+xml)、XML 文件 (application/xml 等)) 的類型時，XSS 才會運作。 application/octet-stream) 的回應時，不會呈現 HTML 或執行指令碼。但 Internet Explorer 等部分瀏覽器會執行名為 Content Sniffing 的作業。Content Sniffing 會忽略提供的 MIME 類型，並嘗試依據回應的內容推論正確的 MIME 類型。text/html的 MIME 類型只是可能導致 XSS 弱點的一種 MIME 類型。可以執行諸如 SVG 影像 (image/svg+xml)、XML 文件 (application/xml) 等指令碼的其他文件，也可能導致 XSS 弱點，無論瀏覽器是否執行 Content Sniffing。 <html><body><script>alert(1)</script></body></html> 之類的回應可以呈現為 HTML，即使其 content-type 標頭已設為 application/octet-stream, multipart-mixed 等。application/octet-stream 回應中反映使用者資料。
@RestController
public class SomeResource {
@RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
public String response5(@RequestParam(value="name") String name){
return name;
}
}
name參數設為 <html><body><script>alert(1)</script></body></html>，則伺服器會產生以下回應：
HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed
<html><body><script>alert(1)</script></body></html>
text/html MIME 類型。因此，只有回應使用此 MIME 類型或任何其他也會強制瀏覽器以 HTML 呈現回應或可能會執行指令碼 (例如 SVG 影像 (image/svg+xml)、XML 文件 (application/xml 等)) 的類型時，XSS 才會運作。 application/json) 提供回應給大多數現代瀏覽器時，這些瀏覽器並不會呈現 HTML，也不會執行指令碼。但 Internet Explorer 等部分瀏覽器會執行名為 Content Sniffing 的作業。Content Sniffing 會忽略提供的 MIME 類型，並嘗試依據回應的內容推論正確的 MIME 類型。但要特別注意的是，text/html 的 MIME 類型只是可能導致 XSS 弱點的一種 MIME 類型。image/svg+xml)、XML 文件 (application/xml) 等指令碼的其他文件，也可能導致 XSS 弱點，無論瀏覽器是否執行 Content Sniffing。 <html><body><script>alert(1)</script></body></html> 之類的回應可以呈現為 HTML，即使其 content-type 標頭已設為 application/json。application/json 回應中反映使用者資料。
def mylambda_handler(event, context):
name = event['name']
response = {
"statusCode": 200,
"body": "{'name': name}",
"headers": {
'Content-Type': 'application/json',
}
}
return response
name 參數設為 <html><body><script>alert(1)</script></body></html>，則伺服器會產生以下回應：
HTTP/1.1 200 OK
Content-Length: 88
Content-Type: application/json
Connection: Closed
{'name': '<html><body><script>alert(1)</script></body></html>'}