HttpOnly 属性设置为 true。HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证标记。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。withHttpOnlyFalse() 方法时，无需设置 HttpOnly 属性即可生成 CSRF Cookie。
...
CookieCsrfTokenRepository c = CookieCsrfTokenRepository.withHttpOnlyFalse();
...
HttpOnly 标记设置为 true。HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证令牌。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。django.middleware.csrf.CsrfViewMiddleware Django 中间件时，即使未设置 HttpOnly 属性也可发送 CSRF cookie。
...
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',
...
)
...
HttpOnly 标记设置为 true。HttpOnly Cookie 属性，以阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证标记。如果未启用 HttpOnly 标记，攻击者就能更容易地访问用户 Cookie。HttpOnly 标记设置为 true 的情况下创建会话 Cookie。
server.servlet.session.cookie.http-only=false
HttpOnly 标记设置为 true。HttpOnly Cookie 属性，以阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证标记。如果未启用 HttpOnly 标记，攻击者就能更容易地访问用户 Cookie。HttpOnly 标记设置为 true 的情况下创建会话 Cookie。
session_set_cookie_params(0, "/", "www.example.com", true, false);
HttpOnly 标记设置为 true。HttpOnly Cookie 属性，可阻止客户端脚本访问 Cookie。Cross-Site Scripting 攻击通常会访问 Cookie，以试图窃取会话标识符或身份验证令牌。如果未启用 HttpOnly，攻击者就能更容易地访问用户 Cookie。HttpOnly 属性的情况下显式设置会话 Cookie。
...
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',
...
)
...
SESSION_COOKIE_HTTPONLY = False
...
SameSite 属性。SameSite 参数限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。SameSite 参数可以有以下三个值：Strict 时，Cookie 仅在顶级导航时与请求一起发送。Lax 时，Cookie 会在顶级导航时与从第三方站点发送到主机的 GET 请求一起从同一主机发送。例如，假设第三方站点拥有链接到主机站点的 iframe 或 href 标签。如果用户点击链接，请求将包含 Cookie。SameSite 属性设置为 None。
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'None');
...
SameSite 属性。SameSite 属性限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。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 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。SameSite 属性可以有以下三个值：Strict 时，Cookie 仅在顶级导航时与请求一起发送。Lax 时，Cookie 随顶级导航与从第三方站点发送到主机的 GET 请求一起从同一主机发送。例如，假设第三方站点拥有链接到主机站点的 iframe 或 href 标签。如果用户点击链接，请求将包含 Cookie。SameSite 属性。
c := &http.Cookie{
Name: "cookie",
Value: "samesite-none",
SameSite: http.SameSiteNoneMode,
}
SameSite 属性。SameSite 属性限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。SameSite 属性可以有以下三个值：Strict 时，Cookie 仅在顶级导航时与请求一起发送。Lax 时，Cookie 随同一主机顶级导航时的请求以及来自第三方站点的 GET 请求一起发送，包括那些具有链接到主机站点的 iframe 或 href 标签的请求。例如，假设第三方站点拥有链接到主机站点的 iframe 或 href 标签。如果用户点击链接，请求将包含 Cookie。SameSite 属性。
ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
...
.sameSite("None")
...
SameSite 属性。SameSite 属性限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。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 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。SameSite 属性可以有以下三个值：Strict 时，Cookie 仅在顶级导航时与请求一起发送。Lax 时，Cookie 随顶级导航与从第三方站点发送到主机的 GET 请求一起从同一主机发送。例如，假设第三方站点拥有链接到主机站点的 iframe 或 href 标签。如果用户点击链接，请求将包含 Cookie。SameSite 属性。
ini_set("session.cookie_samesite", "None");
SameSite 属性。samesite 参数限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。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://insecure.example.com 的 http://secure.example.com 认证用户都面临着暴露来自 http://secure.example.com 的会话 Cookie 的风险。insecure.example.com 来创建自己范围过大的 Cookie，以覆盖来自 secure.example.com 的 Cookie，从而执行 Cookie Poisoning 攻击。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域 ".example.com" 设置会话 ID Cookie。
cookie := http.Cookie{
Name: "sessionID",
Value: getSessionID(),
Domain: ".example.com",
}
...
http://insecure.example.com/ 上部署了另一个不太安全的应用程序，并且它存在 Cross-Site Scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户都面临着暴露来自 http://secure.example.com 的会话 Cookie 的风险。insecure.example.com 进行“Cookie Poisoning 攻击”，创建自己范围过大的 Cookie，并覆盖 Secure.example.com 中的 Cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域 ".example.com" 设置会话 ID Cookie。
Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setDomain(".example.com");
http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域 ".example.com" 设置会话 ID Cookie。
cookie_options = {};
cookie_options.domain = '.example.com';
...
res.cookie('important_cookie', info, cookie_options);
http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域 ".example.com" 设置会话 ID Cookie。
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域 ".example.com" 设置会话 ID Cookie。
setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);
http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域 ".example.com" 设置会话 ID Cookie。
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
return res
...
http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行“Cookie 篡改攻击”，创建自己范围过大的 cookie，并覆盖 secure.example.com 中的 cookie。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域 ".example.com" 设置会话 ID Cookie。
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, domain = Some(".example.com")))
http://insecure.example.com/ 上部署了另一个不太安全的应用程序，并且它存在 Cross-Site Scripting 漏洞。 任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户都面临着暴露来自 http://secure.example.com 的会话 Cookie 的风险。insecure.example.com 来创建自己范围过大的 Cookie，以覆盖来自 secure.example.com 的 Cookie，从而执行 Cookie Poisoning 攻击。.example.com”的基本域中处于活动状态。这会使 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域 ".example.com" 设置会话 ID Cookie。
...
let properties = [
NSHTTPCookieDomain: ".example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。insecure.example.com 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 secure.example.com 的 cookie。/”）进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID Cookie。例如：
...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...
http://communitypages.example.com/EvilSite 上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。/EvilSite 来创建自己范围过大的 Cookie，以覆盖来自 /MyForum 的 Cookie，从而执行 Cookie Poisoning 攻击。/"，然而，这样做会使 Cookie 暴露在同一域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID Cookie。
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Path = "/";
http://communitypages.example.com/EvilSite上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。/EvilSite 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径 "/" 设置会话 ID Cookie。
cookie := http.Cookie{
Name: "sessionID",
Value: sID,
Expires: time.Now().AddDate(0, 0, 1),
Path: "/",
}
...
http://communitypages.example.com/EvilSite 上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。/EvilSite 进行“Cookie Poisoning 攻击”，创建自己范围过大的 Cookie，并覆盖 /MyForum 中的 Cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID Cookie。
Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setPath("/");
http://communitypages.example.com/EvilSite上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。/EvilSite 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID Cookie。
cookie_options = {};
cookie_options.path = '/';
...
res.cookie('important_cookie', info, cookie_options);
http://communitypages.example.com/EvilSite上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。/EvilSite 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID Cookie。
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
http://communitypages.example.com/EvilSite上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。/EvilSite 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID Cookie。
setcookie("mySessionId", getSessionID(), 0, "/", "communitypages.example.com", true, true);
http://communitypages.example.com/EvilSite 上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。/EvilSite 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID Cookie。
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("sessionid", value) # Path defaults to "/"
return res
...
http://communitypages.example.com/EvilSite上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。/EvilSite 进行“Cookie 篡改攻击”，创建自己范围过大的 cookie，并覆盖 /MyForum 中的 cookie。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID Cookie。
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))
http://communitypages.example.com/EvilSite上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。/EvilSite 来创建自己范围过大的 Cookie，以覆盖来自 /MyForum 的 Cookie，从而执行 Cookie Poisoning 攻击。/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 Cookie 通常包含敏感信息（如会话标识符），因此在应用程序之间共享 Cookie 可能会导致其中一个应用程序的漏洞危及其他应用程序安全。http://communitypages.example.com/MyForum 上部署了一个论坛应用程序，当用户登录该论坛时，该应用程序将使用路径“/”设置会话 ID Cookie。
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
http://communitypages.example.com/EvilSite上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户点击该链接时，浏览器会将 /MyForum 设置的 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 ID 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。/EvilSite 进行 cookie poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。.example.com" 的基本域。然而，这样会使会话 Cookie 暴露在基本域名和任何子域中的所有 Web 应用程序下。泄露会话 Cookie 会危及帐户安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域 ".example.com" 设置会话 Cookie。
server.servlet.session.cookie.domain=.example.com
http://insecure.example.com/ 上部署了另一个不太安全的应用程序，并且其存在 Cross-Site Scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户都面临着暴露来自 http://secure.example.com 的会话 Cookie 的风险。.example.com" 的基本域。这会使会话 Cookie 暴露在基本域和任何子域中的所有 Web 应用程序下。在应用程序之间共享会话 Cookie 可能会导致其中一个应用程序的漏洞危及另一个应用程序的安全。http://secure.example.com/ 上，当用户登录时，该应用程序将使用域 ".example.com" 设置会话 Cookie。
session_set_cookie_params(0, "/", ".example.com", true, true);
http://insecure.example.com/ 上有另一个不太安全的应用程序，它包含 cross-site scripting 漏洞。任何浏览到 http://insecure.example.com 的 http://secure.example.com 认证用户面临着暴露来自 http://secure.example.com 的会话 cookie 的风险。/")。这样会使 Cookie 暴露在同一域中的所有 Web 应用程序下。泄露会话 Cookie 会危及帐户安全，因为攻击者可能利用域中任何应用程序的漏洞来窃取会话 Cookie。http://communitypages.example.com/MyForum 上，当用户登录该论坛时，该应用程序将使用路径 "/" 设置会话 Cookie。例如：
server.servlet.session.cookie.path=/
http://communitypages.example.com/EvilSite 上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户单击该链接时，浏览器会将 /MyForum 设置的会话 Cookie 发送到在 /EvilSite 上运行的应用程序。通过使用用户在 /MyForum 上提供的会话 Cookie 后，攻击者就会危及浏览 /EvilSite 的任何论坛用户的帐户安全。/")。这样会使 Cookie 暴露在同一域中的所有 Web 应用程序下。泄露会话 Cookie 会危及帐户安全，因为攻击者可能利用域中任何应用程序的漏洞来窃取会话 Cookie。http://communitypages.example.com/MyForum 上，当用户登录该论坛时，该应用程序将使用路径 "/" 设置会话 Cookie。
session_set_cookie_params(0, "/", "communitypages.example.com", true, true);
http://communitypages.example.com/EvilSite 上创建了另一个应用程序，并在论坛上发布了该站点的链接。当论坛用户单击该链接时，浏览器会将 /MyForum 设置的会话 Cookie 发送到在 /EvilSite 上运行的应用程序。通过这种方式窃取会话 Cookie 后，攻击者就能够危及浏览到 /EvilSite 的任何论坛用户的帐户安全。SameSite 属性未设置为 Strict。SameSite 参数限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。SameSite 参数可以有以下三个值：Strict 时，Cookie 仅在顶级导航时与请求一起发送。Lax 时，Cookie 会在顶级导航时与从第三方站点发送到主机的 GET 请求一起从同一主机发送。例如，假设第三方站点拥有链接到主机站点的 iframe 或 href 标签。如果用户点击链接，请求将包含 Cookie。SameSite 参数设置为 Lax。
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'Lax');
...
SameSite 属性未设置为 Strict。SameSite 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 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 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 Cookie 代表用户访问站点，以便用户可以执行授权操作。但是，浏览器会自动将 Cookie 与请求一起发送，因此用户和网站会隐式信任浏览器进行授权。攻击者可以滥用此信任，通过在攻击者控制的第三方网站页面中的 link 和 iframe 等标签的 href 和 src 属性中嵌入链接，代表用户向站点发出请求。如果攻击者能够将一位毫无戒备的用户引诱到他们控制的第三方站点，则攻击者可以发出自动包含用于授权该用户的会话 Cookie 的请求，从而可以使攻击者获取有效授权，就像他们是用户一样。SameSite 属性的 SameSiteStrictMode，这将限制浏览器仅将 Cookie 附加到顶级导航时的请求或来自同一站点的请求。来自第三方站点的请求（通过 iframe、img 和 form 等各种标签中的链接）不含这些 Cookie，因此能阻止站点采取用户可能未授权的操作。SameSite 属性中的 SameSiteLaxMode。
c := &http.Cookie{
Name: "cookie",
Value: "samesite-lax",
SameSite: http.SameSiteLaxMode,
}
SameSite 属性未设置为 Strict。SameSite 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 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 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 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 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 Cookie 代表用户访问站点，以便用户可以执行授权操作。但是，浏览器会自动将 Cookie 与请求一起发送，因此用户和网站会隐式信任浏览器进行授权。攻击者可以滥用此信任，通过在攻击者控制的第三方网站页面中的 link 和 iframe 等标签的 href 和 src 属性中嵌入链接，代表用户向站点发出请求。如果攻击者能够将一位毫无戒备的用户引诱到他们控制的第三方站点，则攻击者可以发出自动包含用于授权该用户的会话 Cookie 的请求，从而可以使攻击者获取有效授权，就像他们是用户一样。SameSite 属性的 Strict，这将限制浏览器仅将 Cookie 附加到顶级导航时的请求或来自同一站点的请求。来自第三方站点的请求（通过 iframe、img 和 form 等各种标签中的链接）不含这些 Cookie，因此能阻止站点采取用户可能未授权的操作。SameSite 属性中的 Lax 模式。
ini_set("session.cookie_samesite", "Lax");
SameSite 属性未设置为 Strict。SameSite 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 Cookie 代表用户访问站点，以便用户可以执行授权操作。但是，浏览器会自动将 Cookie 与请求一起发送，因此用户和网站会隐式信任浏览器进行授权。攻击者可以滥用此信任，通过在攻击者控制的第三方网站页面中的 link 和 iframe 等标签的 href 和 src 属性中嵌入链接，代表用户向站点发出请求。如果攻击者将毫无戒备的用户引诱到他们控制的第三方站点，则攻击者可以发出自动包含具有用户授权的会话 Cookie 的请求。从而可通过用户授权使攻击者获得有效权限。SameSite 参数的 Strict，这将限制浏览器仅将 Cookie 附加到顶级导航时的请求或来自同一站点的请求。来自第三方站点的请求（通过 iframe、img 和 form 等各种标签中的链接）不含这些 Cookie，因此能阻止站点采取用户可能未授权的操作。samesite 属性中的 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)
...
server.servlet.session.cookie.persistent=true
session_set_cookie_params(time()+60*60*24*365*10, "/", "www.example.com", false, true);
Secure 标记设置为 true。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。Secure 标记的情况下将会话 Cookie 添加到响应中。
...
<configuration>
<system.web>
<authentication mode="Forms">
<forms requireSSL="false" loginUrl="login.aspx">
</forms>
</authentication>
</system.web>
</configuration>
...
Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接监听网络通信对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。Secure 标记。
server.servlet.session.cookie.secure=false
Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。Secure 标记设置为 true。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。Secure 标记的情况下将 cookie 添加到响应中。
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。SESSION_COOKIE_SECURE 属性设置为 True 或将其设置为 False。Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 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 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。
...
<cfquery name = "GetSSNs" dataSource = "users"
username = "scott" password = "tiger">
SELECT SSN
FROM Users
</cfquery>
...
...
Credentials.basic("hardcoded-username", password);
...
MyAccountActions 和一个页面操作方法 pageAction()。该 pageAction() 方法在访问页面 URL 时执行，且服务器不会检查是否存在反 CSRF 令牌。
<apex:page controller="MyAccountActions" action="{!pageAction}">
...
</apex:page>
public class MyAccountActions {
...
public void pageAction() {
Map<String,String> reqParams = ApexPages.currentPage().getParameters();
if (params.containsKey('id')) {
Id id = reqParams.get('id');
Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
delete acct;
}
}
...
}
<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
rb.sendRequest(body, new NewAccountCallback(callback));
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
body = addToPost(body, "attacker";
body = addToPost(body, "haha");
rb.sendRequest(body, new NewAccountCallback(callback));
example.com 的管理员在网站上具有活动会话时访问了恶意页面，则他们会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。
<http auto-config="true">
...
<csrf disabled="true"/>
</http>
var req = new XMLHttpRequest();
req.open("POST", "/new_user", true);
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
req.send(body);
var req = new XMLHttpRequest();
req.open("POST", "http://www.example.com/new_user", true);
body = addToPost(body, "attacker");
body = addToPost(body, "haha");
req.send(body);
example.com 的管理员在网站上具有活动会话时访问了恶意页面，则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com 的管理员在网站上具有活动会话时访问了恶意页面，则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。buyItem 控制器方法的 CSRF 保护。
+ nocsrf
POST /buyItem controllers.ShopController.buyItem
shop.com 上具有活动会话时被诱骗访问了恶意网页，她会在毫不知情的情况下为攻击者购买物品。 这就是 CSRF 攻击。 正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。 任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。 攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com 的管理员在网站上具有活动会话时访问了恶意页面，则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。
@GetMapping("/ai")
String generation(String userInput) {
return this.chatClient.prompt()
.user(userInput)
.call()
.content();
}
message 检索响应，并将其显示给用户。
const openai = new OpenAI({
apiKey: ...,
});
const chatCompletion = await openai.chat.completions.create(...);
message = res.choices[0].message.content
console.log(chatCompletion.choices[0].message.content)
val chatCompletionRequest = ChatCompletionRequest(
model = ModelId("gpt-3.5-turbo"),
messages = listOf(...)
)
val completion: ChatCompletion = openAI.chatCompletion(chatCompletionRequest)
response.getOutputStream().print(completion.choices[0].message)
message 检索响应，并将其显示给用户。
client = openai.OpenAI()
res = client.chat.completions.create(...)
message = res.choices[0].message.content
self.writeln(f"<p>{message}<\p>")
chatService.createCompletion(
text,
settings = CreateCompletionSettings(...)
).map(completion =>
val html = Html(completion.choices.head.text)
Ok(html) as HTML
)
...
text/htmlMIME 类型。因此，仅当响应使用此 MIME 类型或者使用的任何其他类型同样强制浏览器将响应呈现为 HTML 或可执行 SVG 图像 (image/svg+xml) 和 XML 文档 (application/xml) 等脚本的其他文档时，才有可能使用 XSS。 application/octet-stream 等 MIME 类型时执行脚本。但是，Internet Explorer 等某些浏览器可执行称为 Content Sniffing 的内容。Content Sniffing 涉及到忽略提供的 MIME 类型并尝试根据响应的内容推断正确的 MIME 类型。text/html是可能导致 XSS 漏洞的唯一 MIME 类型。可执行 SVG 图像 (image/svg+xml) 和 XML 文档 (application/xml) 等脚本的其他文档可能导致 XSS 漏洞，无论浏览器是否执行 Content Sniffing 都是如此。 <html><body><script>alert(1)</script></body></html> 等响应可能呈现为 HTML，即使其 content-type 标头设置为 application/octet-stream, multipart-mixed 等也是如此。application/octet-stream 响应中的用户数据。
@RestController
public class SomeResource {
@RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
public String response5(@RequestParam(value="name") String name){
return name;
}
}
name参数设置为 <html><body><script>alert(1)</script></body></html>，则服务器将生成以下响应：
HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed
<html><body><script>alert(1)</script></body></html>
text/html MIME 类型。因此，仅当响应使用此 MIME 类型或者使用的任何其他类型同样强制浏览器将响应呈现为 HTML 或可执行 SVG 图像 (image/svg+xml) 和 XML 文档 (application/xml) 等脚本的其他文档时，才有可能使用 XSS。 application/json 等 MIME 类型时执行脚本。但是，Internet Explorer 等某些浏览器可执行称为 Content Sniffing 的内容。Content Sniffing 涉及到忽略提供的 MIME 类型并尝试根据响应的内容推断正确的 MIME 类型。text/html 是可能导致 XSS 漏洞的唯一 MIME 类型。可执行 SVG 图像 (image/svg+xml) 和 XML 文档 (application/xml) 等脚本的其他文档可能导致 XSS 漏洞，无论浏览器是否执行 Content Sniffing 都是如此。 <html><body><script>alert(1)</script></body></html> 等响应可能呈现为 HTML，即使其 content-type 标头设置为 application/json 也是如此。application/json 响应中的用户数据。
def mylambda_handler(event, context):
name = event['name']
response = {
"statusCode": 200,
"body": "{'name': name}",
"headers": {
'Content-Type': 'application/json',
}
}
return response
name 参数设置为 <html><body><script>alert(1)</script></body></html>，则服务器将生成以下响应：
HTTP/1.1 200 OK
Content-Length: 88
Content-Type: application/json
Connection: Closed
{'name': '<html><body><script>alert(1)</script></body></html>'}
eid），并将其显示给用户。
String queryString = Window.Location.getQueryString();
int pos = queryString.indexOf("eid=")+4;
HTML output = new HTML();
output.setHTML(queryString.substring(pos, queryString.length()));
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。eid，并将其显示给用户。示例 2：考虑使用 HTML 表单：
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<div id="myDiv">
Employee ID: <input type="text" id="eid"><br>
...
<button>Show results</button>
</div>
<div id="resultsDiv">
...
</div>
$(document).ready(function(){
$("#myDiv").on("click", "button", function(){
var eid = $("#eid").val();
$("resultsDiv").append(eid);
...
});
});
eid 的雇员 ID 仅包含标准字母数字文本，则这些代码示例可正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
let element = JSON.parse(getUntrustedInput());
ReactDOM.render(<App>
{element}
</App>);
Example 3 中，如果攻击者可以控制从 getUntrustedInput() 检索到的整个 JSON 对象，他们可能就能够使 React 将 element 呈现为一个组件，从而可以使用他们自己控制的值传递具有 dangerouslySetInnerHTML 的对象，这是一种典型的 Cross-Site Scripting 攻击。
<attribute name="href" onInvalid="filterTag">
<regexp-list>
<regexp name="onsiteURL"/>
<regexp name="offsiteURL"/>
</regexp-list>
</attribute>
eid，并将其显示给用户。
String eid = Request["eid"];
...
EmployeeID.Text = eid;
EmployeeID 为服务器端 ASP.NET 控件，定义如下：
<form runat="server">
...
<asp:Label id="EmployeeID" runat="server"/>
...
</form>
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 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 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。user，并将其显示给用户。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 user 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者便能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”，以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url 的值以 javascript: 开头，则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。eid，并将其显示给用户。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
Example 2，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 3 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 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 中的 Web 页面上下文内部执行。eid，并在 servlet 响应中将值显示给该用户。
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
Example 2，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 3 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 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 中的文本包括元字符或源代码，那么可以由 Web 浏览器在显示 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 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，目标应用程序外部的源使用目标应用程序的自定义 URL 方案发出 URL 请求，该 URL 请求中未经验证的数据随后作为可信数据读回应用程序并包含在动态内容中。Example 2 中所示，系统从用户可控的 UI 组件中直接读取数据，并反馈到 HTTP 响应中。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 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 中的文本包括元字符或源代码，那么可以由 Web 浏览器在显示 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 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，目标应用程序外部的源使用目标应用程序的自定义 URL 方案发出 URL 请求，该 URL 请求中未经验证的数据随后作为可信数据读回应用程序并包含在动态内容中。Example 2 中所示，系统从用户可控的 UI 组件中直接读取数据，并反馈到 HTTP 响应中。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 3 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 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 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}
name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
name 的值定义明确（如仅包含字母数字字符），该代码就能正常运行，但不会执行与检查恶意数据有关的任何任务。即使从数据库中读取，也应对值进行适当的验证，因为数据库的内容可以源自用户提供的数据。这样，攻击者就可以在用户的 Web 浏览器中执行恶意命令，而无需像在 Reflected XSS 中那样与受害者进行交互。这种类型的攻击（称为 Stored XSS 或 Persistent）可能极难发现，因为数据被间接提供给易受攻击的函数；另外，由于这种攻击可能影响多个用户，因而会造成巨大的影响。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿的用户都会执行这些恶意代码。username，并将其显示给用户。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username 包含元字符或源代码，则其将由 Web 浏览器执行。Example 1 中所示，数据库或其他数据存储可能会向应用程序提供危险数据，这些数据将包含在动态内容中。从攻击者的角度看，存储恶意内容的最佳位置莫过于可供所有用户（特别是具有较高权限的用户）访问的区域，因为这些用户更有可能处理敏感信息或执行重要操作。Example 2 中所示，系统从 HTTP 请求中读取数据，并在 HTTP 响应中返回数据。如果攻击者可以将危险内容发送给易受攻击的 Web 应用程序，随后将其反馈给用户并在用户浏览器中执行，则会发生 Reflected XSS。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布的或通过电子邮件直接发送给受害者的 URL 中。以这种方式构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者可以借此诱骗受害者访问该 URL。站点将该内容反馈给用户后，便会执行这些内容，并可执行多项操作，例如转发私人敏感信息、在受害者计算机上执行未经授权的操作等。
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>
EmployeeName 为表单控件，定义如下：示例 2：下面的 ASP.NET 代码片段实现的功能与
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 1 等效，但会以编程方式实现所有表单元素。
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
name 的值处理得当，这些代码示例就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login 和 EmployeeID 为表单控件，定义如下：示例 4：下面的 ASP.NET 代码片段显示了如何以编程方式实现
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 3.的功能的方法。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Example 1 和Example 2 中所示，如果 Login 只包含标准字母数字文本，则这些示例将正常运行。如果 Login 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 和Example 2 中所示，应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 3 和Example 4 中所示，系统会从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
ENAME 的值处理得当，该示例中的代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。同样，这段代码看似没那么危险，因为 ENAME 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 ENAME 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Stored XSS，它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并且更可能使此攻击影响到多个用户。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。EID，并将其显示给用户。
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
Example 1 中所示，如果 EID 只包含标准的字母数字文本，此代码将会正确运行。如果 EID 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。当攻击者有以下行为时，将会发生 Stored XSS 漏洞利用： Example 2 中所示，系统从 HTML 表单中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
name 的值处理得当，该示例中的代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Example 1 中所示，如果 Form.eid 只包含标准的字母数字文本，此代码将会正确运行。如果 Form.eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。user，并将其显示给用户。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 user 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者便能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”，以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url 的值以 javascript: 开头，则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 3 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。
...
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并在 servlet 响应中将值显示给该用户。
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url 的值以 javascript: 开头，则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 3 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。myapp://input_to_the_application) 的自定义 URL 方案的文本部分。然后，该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，数据会直接从自定义 URL 方案中读取，并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行，就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是，将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心，攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。eid，并将其显示给用户。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
Example 1 中所示，如果 eid 仅包含标准的字母数字文本，则此示例中的代码将正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 2 所示使用 Rack::Request#params()，则会看到 GET 和 POST 这两个参数，因此可能很容易受到各种类型的攻击，而不仅仅是将恶意代码附加到 URL 中。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。eid），并将其显示给用户。
def getEmployee = Action { implicit request =>
val employee = getEmployeeFromDB()
val eid = employee.id
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 inputTextField 中的文本包括元字符或源代码，那么可以由 Web 浏览器在显示 HTTP 响应的过程中以代码方式执行输入。myapp://input_to_the_application) 的自定义 URL 方案的文本部分。然后，该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从用户可控的 UI 组件中直接读取数据，并反馈到 HTTP 响应中。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 3 中所示，目标应用程序外部的源使用目标应用程序的自定义 URL 方案发出 URL 请求，该 URL 请求中未经验证的数据随后作为可信数据读回应用程序并包含在动态内容中。
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。这段代码暴露出的危险较小，因为 name 的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid，并将其显示给用户。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
Example 1 中所示，如果 eid 只包含标准的字母数字文本，此代码将会正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 2 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。cl_http_utility=>escape_html）能避免一部分 cross-site scripting 攻击，但不能完全避免。根据数据出现的上下文，除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外，其他字符可能具有元意。依靠此类编码函数模块等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击，并且可能允许攻击者注入恶意代码，并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文，因此即便进行了编码，Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果，并将其显示为 Cross-Site Scripting: Poor Validation 问题。eid，对其进行 HTML 编码，并将其显示给用户。
...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = eid
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_eid ).
...
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = itab_employees-name
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_name ).
...
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，对其进行 HTML 编码，并将其显示给用户。
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + escape(eid);
...
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + escape(name);
}
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>
HTMLENCODE，但仍未正确验证数据库提供的数据，因而易受 XSS 攻击。发生这种情况的原因是，variable 内容通过不同的机制（HTML 和 Javascript 解析器）进行解析，因此需要编码两次。这样，攻击者就可以在用户的 Web 浏览器中执行恶意命令，而无需像在 Reflected XSS 中那样与受害者进行交互。这种类型的攻击（称为 Stored XSS 或 Persistent）可能极难发现，因为数据被间接提供给易受攻击的函数；另外，由于这种攻击可能影响多个用户，因而会造成巨大的影响。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿的用户都会执行这些恶意代码。username，并将其显示给用户。
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
username 包含元字符或源代码，则其将由 Web 浏览器执行。同样，在此示例中，使用 HTMLENCODE 不足以防止 XSS 攻击，因为该变量由 Javascript 解析器处理。Example 1 中所示，数据库或其他数据存储可能会向应用程序提供危险数据，这些数据将包含在动态内容中。从攻击者的角度看，存储恶意内容的最佳位置莫过于可供所有用户（特别是具有较高权限的用户）访问的区域，因为这些用户更有可能处理敏感信息或执行重要操作。Example 2 中所示，系统从 HTTP 请求中读取数据，并在 HTTP 响应中返回数据。如果攻击者可以将危险内容发送给易受攻击的 Web 应用程序，随后将其反馈给用户并在用户浏览器中执行，则会发生 Reflected XSS。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布的或通过电子邮件直接发送给受害者的 URL 中。以这种方式构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者可以借此诱骗受害者访问该 URL。站点将该内容反馈给用户后，便会执行这些内容，并可执行多项操作，例如转发私人敏感信息、在受害者计算机上执行未经授权的操作等。
<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
...
</script>
Login 和 EmployeeID 为表单控件，定义如下：示例 2：下面的 ASP.NET 代码片段实现的功能与
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1 相同，不过采用的是编程方式。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
Login 只包含标准的字母或数字文本，上面两个示例中的代码就能正确运行。如果 Login 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
</script>
EmployeeName 为表单控件，定义如下：示例 4：同样，下面的 ASP.NET 代码片段在功能上等效于
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3，不过是以编程方式实现所有表单元素。
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
Example 1 和Example 2 中所示，如果 name 的值正常，则这些代码片段可以正确运行，但如果这些值不正常，则这些代码片段将无法阻止漏洞利用。另外，这些代码示例可能会看起来不太危险，因为 name 的值是从数据库中读取的，而数据库的内容明显由应用程序管理。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 和Example 2 中所示，系统会从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 3 和Example 4 中所示，应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。text 参数，对其进行 HTML 编码，并将其显示在脚本标签之间的警报框中。
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
text 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 text 具有单引号、圆括号和分号，则会结束 alert 文本框，之后将执行代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。user，并将其显示给用户。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(user))
}
user 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 user 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(name))
}
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者便能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”，以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。escapeXml="true" 属性（默认设置）的 <c:out/> 标签可以避免一部分 Cross-Site Scripting 攻击，但不能完全避免。根据数据出现的上下文，除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外，其他字符可能具有元意。依靠此类编码构造等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击，并且可能允许攻击者注入恶意代码，并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文，因此即便应用了编码，Fortify Static Code Analyzer（Fortify 静态代码分析器）仍会报告发现跨站点脚本攻击，并将其显示为“Cross-Site Scripting: Poor Validation”问题。eid，并通过 <c:out/> 标签将其显示给用户。
Employee ID: <c:out value="${param.eid}"/>
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。<c:out/> 标签输出相应雇员姓名。
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <c:out value="${name}"/>
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(URLEncoder.encode(url));
...
url 的值以 javascript: 开头，则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 3 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。eid），对其进行转义并显示给用户。
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。escapeXml="true" 属性（默认设置）的 <c:out/> 标签可以避免一部分 Cross-Site Scripting 攻击，但不能完全避免。根据数据出现的上下文，除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外，其他字符可能具有元意。依靠此类编码构造等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击，并且可能允许攻击者注入恶意代码，并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文，因此即便应用了编码，Fortify Static Code Analyzer（Fortify 静态代码分析器）仍会报告发现跨站点脚本攻击，并将其显示为“Cross-Site Scripting: Poor Validation”问题。eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(URLEncoder.encode(url))
...
url 的值以 javascript: 开头，则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 3 中所示，应用程序外部的源会将危险数据存储在数据库或其他数据存储中，随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。myapp://input_to_the_application) 的自定义 URL 方案的文本部分。然后，该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
...
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
[DefaultEncoder encodeForHTML:partAfterSlashSlash],
@"')\" />"];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:htmlPage baseURL:nil];
...
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，此代码可能看起来不太危险，因为 name 的值是从数据库中读取的，而且采用了 HTML 编码。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。攻击者提供的漏洞可能会绕过编码的字符或在不受 HTML 编码影响的环境中输入信息。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，数据会直接从自定义 URL 方案中读取，并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行，就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是，将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心，攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。htmlspecialchars() 或 htmlentities()）能避免一部分 cross-site scripting 攻击，但不能完全避免。根据数据出现的上下文，除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外（仅当已设置 ENT_QUOTES 时），其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击，并且可能允许攻击者注入恶意代码，并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文，因此即便进行了编码，Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果，并将其显示为 Cross-Site Scripting: Poor Validation 问题。text 参数，使用 HTML 加以编码，并将该参数显示在脚本标签之间的警报框中。
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
text 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 text 具有单引号、圆括号和分号，则会结束 alert 文本框，之后将执行代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。eid，对其进行 URL 编码，并将其显示给用户。
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || HTMLDB_UTIL.url_encode(eid) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || HTMLDB_UTIL.url_encode(name) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，对其进行 HTML 编码，并将其显示给用户。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + escape(eid))
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid，对其进行 HTML 编码，并将其显示给用户。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1 所示使用 Rack::Request#params()，则会看到 GET 和 POST 这两个参数，因此可能很容易受到各种类型的攻击，而不仅仅是将恶意代码附加到 URL 中。
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行适当的输入验证，那么攻击者就可能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。eid），并将其显示给用户。
def getEmployee = Action { implicit request =>
var eid = request.getQueryString("eid")
eid = StringEscapeUtils.escapeHtml(eid); // insufficient validation
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。myapp://input_to_the_application) 的自定义 URL 方案的文本部分。然后，该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，此代码可能看起来不太危险，因为 name 的值是从数据库中读取的，而且采用了 HTML 编码。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。攻击者提供的漏洞可能会绕过编码的字符或在不受 HTML 编码影响的环境中输入信息。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 inputTextField 中的文本包括元字符或源代码，那么可以由 Web 浏览器在显示 HTTP 响应的过程中以代码方式执行输入。Example 1 中所示，数据会直接从自定义 URL 方案中读取，并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行，就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是，将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心，攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。Example 3 中所示，目标应用程序外部的源使用目标应用程序的自定义 URL 方案发出 URL 请求，该 URL 请求中未经验证的数据随后作为可信数据读回应用程序并包含在动态内容中。eid，对其进行 HTML 编码，并将其显示给用户。
...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
..
eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 中的某个值包含元字符或源代码，则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & Server.HTMLEncode(objADORecordSet("name"))
objADORecordSet.MoveNext
Wend
...
Example 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的漏洞利用行为无能为力。同样，这段代码看似没那么危险，因为 name 的值是从数据库中读取的，而且这些内容显然是由应用程序管理的。然而，如果 name 的值来自用户提供的数据，数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS（或 Stored XSS），它极其隐蔽，因为数据存储导致的间接行为会增大辨别威胁的难度，并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1 中所示，系统从 HTTP 请求中直接读取数据，并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容，而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时，就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是，将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心，攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后，便会执行这些内容，接下来会将用户计算机中的各种私密信息（比如可能包含会话信息的 Cookie）传输给攻击者，或者执行其他恶意活动。Example 2 中所示，应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中，并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用：攻击者将危险内容注入到数据存储中，而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看，注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权，或者可以与敏感数据交互，这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容，攻击者就有可能以该用户的名义执行某些需要特权的操作，或者获得该用户个人敏感数据的访问权。