XSS(Cross Site Script)跨站脚本
“用户输入总是不可信任的。”
解释
代码注入的一种，通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本，从而达到攻击者的目的：比如获取用户的Cookie，导航到恶意网站，携带木马等。
攻击者使被攻击者在浏览器中执行脚本后，如果需要收集来自被攻击者的数据（如 cookie 或其他敏感信息），可以自行架设一个网站，让被攻击者通过 JavaScript 等方式把收集好的数据作为参数提交，随后以数据库等形式记录在攻击者自己的服务器上。
攻击的威力，取决于用户输入了什么样的脚本。
1 反射型XSS
反射型XSS，又称非持久型XSS。之所以称为反射型XSS，则是因为这种攻击方式的注入代码是从目标服务器通过错误信息、搜索结果等等方式“反射”回来的。而称为非持久型XSS，则是因为这种攻击方式具有一次性。攻击者通过电子邮件等方式将包含注入脚本的恶意链接发送给受害者，当受害者点击该链接时，注入脚本被传输到目标服务器上，然后服务器将注入脚本“反射”到受害者的浏览器上，从而在该浏览器上执行了这段脚本。
比如攻击者将如下链接发送给受害者：
http://www.targetserver.com/search.asp?input=<script>alert(document.cookie);</script>
当受害者点击这个链接的时候，注入的脚本被当作搜索的关键词发送到目标服务器的search.asp页面中，则在搜索结果的返回页面中，这段脚本将被当作搜索的关键词而嵌入。这样，当用户得到搜索结果页面后，这段脚本也得到了执行。这就是反射型XSS攻击的原理，可以看到，攻击者巧妙地通过反射型XSS的攻击方式，达到了在受害者的浏览器上执行脚本的目的。由于代码注入的是一个动态产生的页面而不是永久的页面，因此这种攻击方式只在点击链接的时候才产生作用，这也是它被称为非持久型XSS的原因。
2 存储型XSS
存储型XSS，又称持久型XSS，他和反射型XSS最大的不同就是，攻击脚本将被永久地存放在目标服务器的数据库和文件中。这种攻击多见于论坛，攻击者在发帖的过程中，将恶意脚本连同正常信息一起注入到帖子的内容之中。随着帖子被论坛服务器存储下来，恶意脚本也永久地被存放在论坛服务器的后端存储器中。当其它用户浏览这个被注入了恶意脚本的帖子的时候，恶意脚本则会在他们的浏览器中得到执行，从而受到了攻击。
防御
1 浏览器同源策略
2 输入过滤
对用户的所有输入数据进行检测，比如过滤其中的“<”、“>”、“/”等可能导致脚本注入的特殊字符，或者过滤“script”、“javascript”等脚本关键字，或者对输入数据的长度进行限制等等。同时，我们也要考虑用户可能绕开ASCII码，使用十六进制编码来输入脚本。因此，对用户输入的十六进制编码，我们也要进行相应的过滤。只要能够严格检测每一处交互点，保证对所有用户可能的输入都进行检测和XSS过滤，就能够有效地阻止XSS攻击。
3 输出处理
之所以会产生XSS攻击，就是因为Web应用程序将用户的输入直接嵌入到某个页面当中，作为该页面的HTML代码的一部分。因此，当Web应用程序将用户的输入数据输出到目标页面中时，只要用 HtmlEncoder等工具先对这些数据进行编码，然后再输出到目标页面中。这样，如果用户输入一些HTML的脚本，也会被当成普通的文字，而不会成为目标页面HTML代码的一部分得到执行。
以使用HTTP头指定内容的类型，使得输出的内容避免被作为可能引发攻击的HTML解析。
4 Cookie防盗
利用XSS攻击，攻击者可以很方便地窃取到合法用户的Cookie信息。对于Cookie，可以采取以下措施：尽可能地避免在Cookie中泄露隐私，如用户名、密码等；可以将Cookie信息利用MD5等Hash算法进行多次散列后存放；为了防止重放攻击，也可以将Cookie和IP进行绑定，这样也可以阻止攻击者冒充正常用户的身份。
CSRF(Cross Site Request Forgery) 跨预请求伪造
1 浅谈CSRF攻击方式
攻击原理图和攻击示例
2 wikipedia/跨域请求伪造
攻击细节：
跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户浏览器，让其以用户的名义执行操作。
防御措施：
（1） 根据 HTTP 头 Request Header 的 Refer 字段判断请求是否来自与服务器同域的网站，判别恶意访问。
优点：工作量低，仅需要在关键访问处增加一步校验。
缺点：但是存在攻击者攻击浏览器、篡改发请求的 Refer 字段的可能。
（2） 校验 token （伪乱数）同 POST 请求的数据内容一同发送。
在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验。
首先服务器端要以某种策略生成随机字符串，作为令牌（token），保存在 Session 里。然后在发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与 Session 中的令牌比较，只有一致的时候才处理请求，否则返回 HTTP 403 拒绝请求或者要求用户重新登录验证身份。
（3）验证码
总结比较
XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。
XSS利用的是用户对指定网站的信任；
CSRF利用的是网站对用户网页浏览器的信任。