MyAccountActions
和一个页面操作方法 pageAction()
。该 pageAction()
方法在访问页面 URL 时执行,且服务器不会检查是否存在反 CSRF 令牌。
<apex:page controller="MyAccountActions" action="{!pageAction}">
...
</apex:page>
public class MyAccountActions {
...
public void pageAction() {
Map<String,String> reqParams = ApexPages.currentPage().getParameters();
if (params.containsKey('id')) {
Id id = reqParams.get('id');
Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
delete acct;
}
}
...
}
<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
rb.sendRequest(body, new NewAccountCallback(callback));
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
body = addToPost(body, "attacker";
body = addToPost(body, "haha");
rb.sendRequest(body, new NewAccountCallback(callback));
example.com
的管理员在网站上具有活动会话时访问了恶意页面,则他们会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源,才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作,也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页,因此,这种攻击技术仅适用于篡改应用程序状态的请求。
<http auto-config="true">
...
<csrf disabled="true"/>
</http>
var req = new XMLHttpRequest();
req.open("POST", "/new_user", true);
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
req.send(body);
var req = new XMLHttpRequest();
req.open("POST", "http://www.example.com/new_user", true);
body = addToPost(body, "attacker");
body = addToPost(body, "haha");
req.send(body);
example.com
的管理员在网站上具有活动会话时访问了恶意页面,则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源,才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作,也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页,因此,这种攻击技术仅适用于篡改应用程序状态的请求。
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com
的管理员在网站上具有活动会话时访问了恶意页面,则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源,才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作,也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页,因此,这种攻击技术仅适用于篡改应用程序状态的请求。buyItem
控制器方法的 CSRF 保护。
+ nocsrf
POST /buyItem controllers.ShopController.buyItem
shop.com
上具有活动会话时被诱骗访问了恶意网页,她会在毫不知情的情况下为攻击者购买物品。 这就是 CSRF 攻击。 正是由于该应用程序无法确定请求的来源,才有可能受到 CSRF 攻击。 任何请求都有可能是用户选定的合法操作,也有可能是攻击者设置的伪操作。 攻击者无法查看伪请求生成的网页,因此,这种攻击技术仅适用于篡改应用程序状态的请求。
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com
的管理员在网站上具有活动会话时访问了恶意页面,则会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源,才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作,也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页,因此,这种攻击技术仅适用于篡改应用程序状态的请求。
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...
name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。这段代码暴露出的危险较小,因为 name
的值是从数据库中读取的,而且显然这些内容是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid
,并将其显示给用户。
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
Example 1
中所示,如果 eid
只包含标准的字母数字文本,此代码将会正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}
name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。这段代码暴露出的危险较小,因为 name
的值是从数据库中读取的,而且显然这些内容是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid
,并将其显示给用户。
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...
Example 1
中所示,如果 eid
只包含标准的字母数字文本,此代码将会正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
name
的值定义明确(如仅包含字母数字字符),该代码就能正常运行,但不会执行与检查恶意数据有关的任何任务。即使从数据库中读取,也应对值进行适当的验证,因为数据库的内容可以源自用户提供的数据。这样,攻击者就可以在用户的 Web 浏览器中执行恶意命令,而无需像在 Reflected XSS 中那样与受害者进行交互。这种类型的攻击(称为 Stored XSS 或 Persistent)可能极难发现,因为数据被间接提供给易受攻击的函数;另外,由于这种攻击可能影响多个用户,因而会造成巨大的影响。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿的用户都会执行这些恶意代码。username
,并将其显示给用户。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username
包含元字符或源代码,则其将由 Web 浏览器执行。Example 1
中所示,数据库或其他数据存储可能会向应用程序提供危险数据,这些数据将包含在动态内容中。从攻击者的角度看,存储恶意内容的最佳位置莫过于可供所有用户(特别是具有较高权限的用户)访问的区域,因为这些用户更有可能处理敏感信息或执行重要操作。Example 2
中所示,系统从 HTTP 请求中读取数据,并在 HTTP 响应中返回数据。如果攻击者可以将危险内容发送给易受攻击的 Web 应用程序,随后将其反馈给用户并在用户浏览器中执行,则会发生 Reflected XSS。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布的或通过电子邮件直接发送给受害者的 URL 中。以这种方式构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者可以借此诱骗受害者访问该 URL。站点将该内容反馈给用户后,便会执行这些内容,并可执行多项操作,例如转发私人敏感信息、在受害者计算机上执行未经授权的操作等。
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>
EmployeeName
为表单控件,定义如下:示例 2:下面的 ASP.NET 代码片段实现的功能与
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 1
等效,但会以编程方式实现所有表单元素。
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
name
的值处理得当,这些代码示例就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。这段代码暴露出的危险较小,因为 name
的值是从数据库中读取的,而且显然这些内容是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login
和 EmployeeID
为表单控件,定义如下:示例 4:下面的 ASP.NET 代码片段显示了如何以编程方式实现
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 3
.的功能的方法。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Example 1
和Example 2
中所示,如果 Login
只包含标准字母数字文本,则这些示例将正常运行。如果 Login
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
和Example 2
中所示,应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 3
和Example 4
中所示,系统会从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
ENAME
的值处理得当,该示例中的代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。同样,这段代码看似没那么危险,因为 ENAME
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 ENAME
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Stored XSS,它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并且更可能使此攻击影响到多个用户。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。EID
,并将其显示给用户。
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
Example 1
中所示,如果 EID
只包含标准的字母数字文本,此代码将会正确运行。如果 EID
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。当攻击者有以下行为时,将会发生 Stored XSS 漏洞利用: Example 2
中所示,系统从 HTML 表单中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
name
的值处理得当,该示例中的代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。这段代码暴露出的危险较小,因为 name
的值是从数据库中读取的,而且显然这些内容是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid
,并将其显示给用户。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Example 1
中所示,如果 Form.eid
只包含标准的字母数字文本,此代码将会正确运行。如果 Form.eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。user
,并将其显示给用户。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 user
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者便能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”,以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。这段代码暴露出的危险较小,因为 name
的值是从数据库中读取的,而且显然这些内容是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid
,并将其显示给用户。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
Example 1
中所示,如果 eid
只包含标准的字母数字文本,此代码将会正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url
的值以 javascript:
开头,则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 3
中所示,应用程序外部的源会将危险数据存储在数据库或其他数据存储中,随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。这段代码暴露出的危险较小,因为 name
的值是从数据库中读取的,而且显然这些内容是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid
,并将其显示给用户。
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
Example 1
中所示,如果 eid
只包含标准的字母数字文本,此代码将会正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。
...
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。这段代码暴露出的危险较小,因为 name
的值是从数据库中读取的,而且显然这些内容是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid
,并在 servlet 响应中将值显示给该用户。
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
Example 1
中所示,如果 eid
只包含标准的字母数字文本,此代码将会正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url
的值以 javascript:
开头,则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 3
中所示,应用程序外部的源会将危险数据存储在数据库或其他数据存储中,随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。myapp://input_to_the_application
) 的自定义 URL 方案的文本部分。然后,该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,数据会直接从自定义 URL 方案中读取,并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行,就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是,将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心,攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。这段代码暴露出的危险较小,因为 name
的值是从数据库中读取的,而且显然这些内容是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid
,并将其显示给用户。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
Example 1
中所示,如果 eid
只包含标准的字母数字文本,此代码将会正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。这段代码暴露出的危险较小,因为 name
的值是从数据库中读取的,而且显然这些内容是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid
,并将其显示给用户。
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1
中所示,如果 eid
只包含标准的字母数字文本,此代码将会正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。eid
,并将其显示给用户。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid
,并将其显示给用户。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
Example 1
中所示,如果 eid
仅包含标准的字母数字文本,则此示例中的代码将正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 2
所示使用 Rack::Request#params()
,则会看到 GET
和 POST
这两个参数,因此可能很容易受到各种类型的攻击,而不仅仅是将恶意代码附加到 URL 中。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。eid
,并将其显示给用户。
def getEmployee = Action { implicit request =>
val employee = getEmployeeFromDB()
val eid = employee.id
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 inputTextField
中的文本包括元字符或源代码,那么可以由 Web 浏览器在显示 HTTP 响应的过程中以代码方式执行输入。myapp://input_to_the_application
) 的自定义 URL 方案的文本部分。然后,该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从用户可控的 UI 组件中直接读取数据,并反馈到 HTTP 响应中。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 3
中所示,目标应用程序外部的源使用目标应用程序的自定义 URL 方案发出 URL 请求,该 URL 请求中未经验证的数据随后作为可信数据读回应用程序并包含在动态内容中。
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的盗取行为无能为力。这段代码暴露出的危险较小,因为 name
的值是从数据库中读取的,而且显然这些内容是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。eid
,并将其显示给用户。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
Example 1
中所示,如果 eid
只包含标准的字母数字文本,此代码将会正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 2
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。cl_http_utility=>escape_html
)能避免一部分 cross-site scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数模块等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。eid
,对其进行 HTML 编码,并将其显示给用户。
...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = eid
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_eid ).
...
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = itab_employees-name
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_name ).
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,对其进行 HTML 编码,并将其显示给用户。
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + escape(eid);
...
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + escape(name);
}
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>
HTMLENCODE
,但仍未正确验证数据库提供的数据,因而易受 XSS 攻击。发生这种情况的原因是,variable
内容通过不同的机制(HTML 和 Javascript 解析器)进行解析,因此需要编码两次。这样,攻击者就可以在用户的 Web 浏览器中执行恶意命令,而无需像在 Reflected XSS 中那样与受害者进行交互。这种类型的攻击(称为 Stored XSS 或 Persistent)可能极难发现,因为数据被间接提供给易受攻击的函数;另外,由于这种攻击可能影响多个用户,因而会造成巨大的影响。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿的用户都会执行这些恶意代码。username
,并将其显示给用户。
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
username
包含元字符或源代码,则其将由 Web 浏览器执行。同样,在此示例中,使用 HTMLENCODE
不足以防止 XSS 攻击,因为该变量由 Javascript 解析器处理。Example 1
中所示,数据库或其他数据存储可能会向应用程序提供危险数据,这些数据将包含在动态内容中。从攻击者的角度看,存储恶意内容的最佳位置莫过于可供所有用户(特别是具有较高权限的用户)访问的区域,因为这些用户更有可能处理敏感信息或执行重要操作。Example 2
中所示,系统从 HTTP 请求中读取数据,并在 HTTP 响应中返回数据。如果攻击者可以将危险内容发送给易受攻击的 Web 应用程序,随后将其反馈给用户并在用户浏览器中执行,则会发生 Reflected XSS。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布的或通过电子邮件直接发送给受害者的 URL 中。以这种方式构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者可以借此诱骗受害者访问该 URL。站点将该内容反馈给用户后,便会执行这些内容,并可执行多项操作,例如转发私人敏感信息、在受害者计算机上执行未经授权的操作等。
<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
...
</script>
Login
和 EmployeeID
为表单控件,定义如下:示例 2:下面的 ASP.NET 代码片段实现的功能与
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1
相同,不过采用的是编程方式。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
Login
只包含标准的字母或数字文本,上面两个示例中的代码就能正确运行。如果 Login
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
</script>
EmployeeName
为表单控件,定义如下:示例 4:同样,下面的 ASP.NET 代码片段在功能上等效于
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3
,不过是以编程方式实现所有表单元素。
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
Example 1
和Example 2
中所示,如果 name
的值正常,则这些代码片段可以正确运行,但如果这些值不正常,则这些代码片段将无法阻止漏洞利用。另外,这些代码示例可能会看起来不太危险,因为 name
的值是从数据库中读取的,而数据库的内容明显由应用程序管理。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
和Example 2
中所示,系统会从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 3
和Example 4
中所示,应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。text
参数,对其进行 HTML 编码,并将其显示在脚本标签之间的警报框中。
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
text
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 text
具有单引号、圆括号和分号,则会结束 alert
文本框,之后将执行代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。user
,并将其显示给用户。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(user))
}
user
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 user
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(name))
}
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者便能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”,以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。escapeXml="true"
属性(默认设置)的 <c:out/>
标签可以避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码构造等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便应用了编码,Fortify Static Code Analyzer(Fortify 静态代码分析器)仍会报告发现跨站点脚本攻击,并将其显示为“Cross-Site Scripting: Poor Validation”问题。eid
,并通过 <c:out/>
标签将其显示给用户。
Employee ID: <c:out value="${param.eid}"/>
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。<c:out/>
标签输出相应雇员姓名。
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <c:out value="${name}"/>
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(URLEncoder.encode(url));
...
url
的值以 javascript:
开头,则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 3
中所示,应用程序外部的源会将危险数据存储在数据库或其他数据存储中,随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。eid
,对其进行转义并显示给用户。
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。escapeXml="true"
属性(默认设置)的 <c:out/>
标签可以避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码构造等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便应用了编码,Fortify Static Code Analyzer(Fortify 静态代码分析器)仍会报告发现跨站点脚本攻击,并将其显示为“Cross-Site Scripting: Poor Validation”问题。eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(URLEncoder.encode(url))
...
url
的值以 javascript:
开头,则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 3
中所示,应用程序外部的源会将危险数据存储在数据库或其他数据存储中,随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。myapp://input_to_the_application
) 的自定义 URL 方案的文本部分。然后,该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
...
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
[DefaultEncoder encodeForHTML:partAfterSlashSlash],
@"')\" />"];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:htmlPage baseURL:nil];
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,此代码可能看起来不太危险,因为 name
的值是从数据库中读取的,而且采用了 HTML 编码。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。攻击者提供的漏洞可能会绕过编码的字符或在不受 HTML 编码影响的环境中输入信息。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,数据会直接从自定义 URL 方案中读取,并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行,就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是,将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心,攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。htmlspecialchars()
或 htmlentities()
)能避免一部分 cross-site scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外(仅当已设置 ENT_QUOTES
时),其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。text
参数,使用 HTML 加以编码,并将该参数显示在脚本标签之间的警报框中。
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
text
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 text
具有单引号、圆括号和分号,则会结束 alert
文本框,之后将执行代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。eid
,对其进行 URL 编码,并将其显示给用户。
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || HTMLDB_UTIL.url_encode(eid) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || HTMLDB_UTIL.url_encode(name) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,对其进行 HTML 编码,并将其显示给用户。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + escape(eid))
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,对其进行 HTML 编码,并将其显示给用户。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
所示使用 Rack::Request#params()
,则会看到 GET
和 POST
这两个参数,因此可能很容易受到各种类型的攻击,而不仅仅是将恶意代码附加到 URL 中。
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行适当的输入验证,那么攻击者就可能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并将其显示给用户。
def getEmployee = Action { implicit request =>
var eid = request.getQueryString("eid")
eid = StringEscapeUtils.escapeHtml(eid); // insufficient validation
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。myapp://input_to_the_application
) 的自定义 URL 方案的文本部分。然后,该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,此代码可能看起来不太危险,因为 name
的值是从数据库中读取的,而且采用了 HTML 编码。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。攻击者提供的漏洞可能会绕过编码的字符或在不受 HTML 编码影响的环境中输入信息。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 inputTextField
中的文本包括元字符或源代码,那么可以由 Web 浏览器在显示 HTTP 响应的过程中以代码方式执行输入。Example 1
中所示,数据会直接从自定义 URL 方案中读取,并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行,就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是,将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心,攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 3
中所示,目标应用程序外部的源使用目标应用程序的自定义 URL 方案发出 URL 请求,该 URL 请求中未经验证的数据随后作为可信数据读回应用程序并包含在动态内容中。eid
,对其进行 HTML 编码,并将其显示给用户。
...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
..
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & Server.HTMLEncode(objADORecordSet("name"))
objADORecordSet.MoveNext
Wend
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并将其显示给用户。
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并将其显示给用户。
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。username
,并将其显示给用户。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username
包含元字符或源代码,则其将由 Web 浏览器执行。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
Example 1
中所示,如果 name
的值定义明确(如仅包含字母数字字符),该代码就能正常运行,但无法检查是否存在恶意数据。即使从数据库中读取,也应对该值进行适当的验证,因为数据库的内容可能源自用户提供的数据。这样,攻击者就可以在用户的 Web 浏览器中执行恶意命令,而无需像在 Reflected XSS 中那样与受害者进行交互。这种类型的攻击称为 Stored XSS 或 Persistent XSS,它可能极其隐蔽,因为数据会被间接提供给易受攻击的函数;另外,由于这种攻击可能影响多个用户,因而会造成巨大的影响。XSS 漏洞利用首先会在网站上为访问者提供一个“留言簿”。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中读取数据,并在 HTTP 响应中返回数据。如果攻击者可以将危险内容发送给易受攻击的 Web 应用程序,随后将其反馈给用户并在用户浏览器中执行,则会发生 Reflected XSS。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布的或通过电子邮件直接发送给受害者的 URL 中。以这种方式构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者可以借此诱骗受害者访问该 URL。站点将该内容反馈给用户后,便会执行这些内容,并可执行多项操作,例如转发私人敏感信息、在受害者计算机上执行未经授权的操作等。Example 2
中所示,数据库或其他数据存储可能会向应用程序提供危险数据,这些数据将包含在动态内容中。从攻击者的角度看,存储恶意内容的最佳位置莫过于可供所有用户(特别是具有较高权限的用户)访问的区域,因为这些用户更有可能处理敏感信息或执行重要操作。
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login
和 EmployeeID
为表单控件,定义如下:示例 2:下面的 ASP.NET 代码片段显示了如何以编程方式实现
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1
.的功能的方法。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Login
只包含标准的字母或数字文本,上面两个示例中的代码就能正确运行。如果 Login
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>
EmployeeName
为表单控件,定义如下:示例 4:下面的 ASP.NET 代码片段实现的功能与
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3
等效,但会以编程方式实现所有表单元素。
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
Example 1
和Example 2
中所示,如果 name
的值正常,则这些代码示例可以正确运行,但如果这些值不正常,则这些代码示例将无法阻止漏洞利用。另外,这些代码示例可能会看起来不太危险,因为 name
的值是从数据库中读取的,而数据库的内容明显由应用程序管理。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
和Example 2
中所示,系统会从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 3
和Example 4
中所示,应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。EID
,并将其显示给用户。
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
EID
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 EID
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
Example 1
,如果对 ENAME
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 ENAME
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 ENAME
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Stored XSS,它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并且更可能使此攻击影响到多个用户。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTML 表单中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。当攻击者有以下行为时,将会发生 Stored XSS 漏洞利用: eid
,并将其显示给用户。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Form.eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 Form.eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。user
,并将其显示给用户。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 user
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者便能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”,以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并将其显示给用户。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url
的值以 javascript:
开头,则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 3
中所示,应用程序外部的源会将危险数据存储在数据库或其他数据存储中,随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。eid
,并将其显示给用户。
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并在 servlet 响应中将值显示给该用户。
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url
的值以 javascript:
开头,则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。Example 3
中所示,应用程序外部的源会将危险数据存储在数据库或其他数据存储中,随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。myapp://input_to_the_application
) 的自定义 URL 方案的文本部分。然后,该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,数据会直接从自定义 URL 方案中读取,并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行,就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是,将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心,攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并将其显示给用户。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并将其显示给用户。
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并将其显示给用户。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并将其显示给用户。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。Example 1
所示使用 Rack::Request#params()
,则会看到 GET
和 POST
这两个参数,因此可能很容易受到各种类型的攻击,而不仅仅是将恶意代码附加到 URL 中。
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并将其显示给用户。
def getEmployee = Action { implicit request =>
val eid = request.getQueryString("eid")
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 inputTextField
中的文本包括元字符或源代码,那么可以由 Web 浏览器在显示 HTTP 响应的过程中以代码方式执行输入。myapp://input_to_the_application
) 的自定义 URL 方案的文本部分。然后,该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
Example 2
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从用户可控的 UI 组件中直接读取数据,并反馈到 HTTP 响应中。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,目标应用程序外部的源使用目标应用程序的自定义 URL 方案发出 URL 请求,该 URL 请求中未经验证的数据随后作为可信数据读回应用程序并包含在动态内容中。Example 3
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。eid
,并将其显示给用户。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
NSString *regex = @"^(e+)+$";
NSPredicate *pred = [NSPRedicate predicateWithFormat:@"SELF MATCHES %@", regex];
if ([pred evaluateWithObject:mystring]) {
//do something
}
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
let regex : String = "^(e+)+$"
let pred : NSPredicate = NSPRedicate(format:"SELF MATCHES \(regex)")
if (pred.evaluateWithObject(mystring)) {
//do something
}
Example 1
中,如果攻击者提供了匹配字符串“eeeeZ”,则正则表达式解析器必须经过 16 次内部求值才能识别出匹配项。如果攻击者使用 16 个“e”(“eeeeeeeeeeeeeeeeZ”)作为匹配字符串,则正则表达式解析器必须进行 65536 (2^16) 次计算。通过增加连续的匹配字符数,攻击者可以轻易地消耗计算资源。已知的正则表达式实现方式均无法避免这种漏洞。所有平台和语言都容易受到这种攻击。author
,并将其置于一个 HTTP 响应的 cookie 头文件中。
...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
。如果您的应用程序服务器能够防止设置带有换行符的标头,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。
@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();
RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}
author
和 Jane Smith
组成,则包含此标头的 HTTP 响应可能会采用以下形式:
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo
和 bar
,然后 HTTP 响应将被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
HttpResponse.AddHeader()
方法时将其转换为 %0d、%0a 和 %00。如果您正在使用的最新的 .NET 框架不允许使用新行字符设置头文件,则应用程序便不会容易受到 HTTP Response Splitting 攻击。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author
,并将其置于一个 HTTP 响应的 Cookie 头文件中。
protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
Author.Text
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
author
,并在一个 HTTP 响应的 cookie 头文件中设置。
...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.
EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......",那么 HTTP 响应就会被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author
,并且把它设置到一个 HTTP 响应的 cookie 头文件中。
<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......",那么 HTTP 响应就会被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1/1 200 OK
...
IllegalArgumentException
。如果您的应用程序服务器能够防止设置带有换行符的标头,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此在设置带有用户输入的 HTTP 标头时仍需小心谨慎。
final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});
author
,并将其置于一个 HTTP 响应的 Cookie 标头中。
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
IllegalArgumentException
。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author
,并将其置于一个 HTTP 响应的 cookie 头文件中。
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
author
,并将其置于一个 HTTP 响应的 cookie 头文件中。
author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n......",那么 HTTP 响应就会被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。name
和 value
可能会被攻击者控制。这段代码设置了一个名称和值可能被攻击者控制的 HTTP 标头。
...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...
author
和 Jane Smith
组成,则包含此标头的 HTTP 响应可能会以这样的形式出现:
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo
和 bar
,于是该 HTTP 响应将会拆分为如下形式的两个响应:
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
header()
函数时,最新版本的 PHP 将生成一个警告并停止创建头文件。如果您的 PHP 版本能够阻止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。
<?php
$location = $_GET['some_location'];
...
header("location: $location");
?>
HTTP/1.1 200 OK
...
location: index.html
...
some_location
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“index.html\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
author
,并将其置于一个 HTTP 响应的 Cookie 头文件中。
...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
location = req.field('some_location')
...
response.addHeader("location",location)
HTTP/1.1 200 OK
...
location: index.html
...
some_location
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“index.html\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
IllegalArgumentException
。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。author
的名字,并在发往站点另一部分的 Get 请求中使用它。
author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...
AUTHOR_PARAM
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,例如“Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker
POST /index.php HTTP/1.1
...
IllegalArgumentException
。如果您的应用程序服务器能够防止设置带有换行符的头文件,则其具备对 HTTP Response Splitting 的防御能力。然而,单纯地过滤换行符可能无法保证应用程序不受 Cookie Manipulation 或 Open Redirects 的攻击,因此必须在设置带有用户输入的 HTTP 头文件时采取措施。name
和 value
可能会被攻击者控制。这段代码设置了一个名称和值可能被攻击者控制的 HTTP 标头。
...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...
author
和 Jane Smith
组成,则包含此标头的 HTTP 响应可能会以这样的形式出现:
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo
和 bar
,于是该 HTTP 响应将会拆分为如下形式的两个响应:
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
author
,并将其置于一个 HTTP 响应的 Cookie 头文件中。
...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
的值不包含任何 CR 和 LF 字符时,响应才会保留这种形式。如果攻击者提交的是一个恶意字符串,比如“Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...”,那么 HTTP 响应就会被分割成以下形式的两个响应:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...