大家对于这2个攻击可能比较混淆，因为从名字上就很容易混淆，csrf跨站点伪装请求和xss跨站点攻击。我一开始也对这两个东西搞混淆了，后面发现他们的最根本区别。
（1）CSRF攻击的主要目的是让用户在不知情的情况下攻击自己已登录的一个系统，类似于钓鱼。如用户当前已经登录了邮箱，或bbs，同时用户又在使用另外一个，已经被你控制的站点，我们姑且叫它钓鱼网站。这个网站上面可能因为某个图片吸引你，你去点击一下，此时可能就会触发一个js的点击事件，构造一个bbs发帖的请求，去往你的bbs发帖，由于当前你的浏览器状态已经是登陆状态，所以session登陆cookie信息都会跟正常的请求一样，纯天然的利用当前的登陆状态，让用户在不知情的情况下，帮你发帖或干其他事情。预防措施，请求中加入随机数，让钓鱼网站无法正常伪造请求。
CSRF成功的前提用户必须登录到目标站点，且用户浏览了攻击者控制的站点。
与XSS最为不同一点是CSRF可以不用JS就能达到目的（GET和POST的区别）。
而且攻击者仅仅只需要给目标站一个请求就能成功。如0X01所说请求可以绕过同源策略。
还有一个天然条件是浏览器的安全缺陷：
浏览器在最初加入Cookie功能时并没有考虑安全因素。假设一个网站使用了Cookie，当一个用户完成身份验证之后.浏览器得到一个标识用户身份的Cookie，只要不退出或关闭浏览器。以后访问相同网站下的页面的时候，对每一个请求浏览器都会“智能”地主动附带上该网站的Cookie来标识自己，用户不需要重新认证就可以被网站识别。当第三方WEB页面产生了指向当前网站域下的请求时，该请求也会带上当前网站的Cookie。这种认证方式，称之为隐式认证。
除了Cookie认证方式之外，其他Web认证机制也面临同样的问题。比如HTTP基本认证，用户通过认证后。浏览器仍会“智能”地把用户名和口令附加到之后第三方发给站点的请求中。即使网站使用了安全套接字(SSL)来加密连接.浏览器也会”智能“地自动把SSL认证信息加到第三方发给站点的请求中。
（2）XSS攻击的主要目的则是，想办法获取目标攻击网站的cookie，因为有了cookie相当于有了seesion，有了这些信息就可以在任意能接进互联网的pc登陆该网站，并以其他人的生份登陆，做一些破坏。预防措施，防止下发界面显示html标签，把</>等符号转义。
注：
（1）同源策略
同源策略不需要讲了，这里只提与CSRF，XSS有关的一个概念：
同源策略仅仅阻止了脚本读取来自其他站点的内容和阻住对请求的响应。但是却没有防止脚本向其他站点发出请求。
请求的内容相当于一个灵魂，没有肉体，而站点相当于一栋房子。
房子的大门(同源策略）并不会排斥灵魂的进入（灵魂是可以穿墙的嘛）,会排斥非此房子不怀好意的人(其他域的javascript)进入
因而房子里面的主人(程序）对灵魂是视而不见的，或者说是看不见的。且不会理会调皮的请求的。
（2）为什么要用XSS
网上很多文章都是直接讲XSS分什么类型，怎样利用XSS，怎样发现XSS。好像没有讲为什么要用XSS（可能我阅读面不太广），那么不管了，自己总结下。
有人会问：把保存型XSS放在一边不谈，为什要用反射型XSS和DOM-BASE XSS，这么麻烦，不如要攻击A站点，直接在攻击者控制的B站点保存一段恶意js，并向用户传送一个直接指向这段脚本的链接？
原因一：伪装。攻击者传送的是以A站点开头的URL，而不是B站点开头的URL更能令用户上当
比如：A:的站点为：http://www.yunsec.com/
B的站点为：http://www.yunsec.net/
那么你构造URL:http://www.yunsec.net/hello.asp?message=http://www.yunsec.net/evil.js /*http://www.yunsec.net/evil.js为其他域的脚本*/
比直接构造URL：http://www.yunsec.net/evil.js 传送给用户，更能让用户点击。
更者，message后面的网址还可以经过编码，更会迷惑用户。这种更多用于钓鱼。
原因二：第二点也是最重要的一点，由于同源策略的限制，导致如果不用XSS，浏览器不会执行脚本或者不会返回攻击者想要的数据。
利用XSS之所以成功是因为攻击者的恶意JS是由http://www.yunsec.net/hello.asp提交的。
浏览器误以为是www.yunsec.net此域提交的。
于是浏览器会执行http://www.yunsec.net/evil.js这段恶意脚本。
又来YY下下列场景:
A站点相当于蓝军的制造厂（无攻击性），B站点相当于绿军的根据地（有攻击性）
某时，绿军派遣特工（恶意js）去制造厂窃取机密，但是蓝军的制造厂大门(同源策略)是紧闭的，特工无法穿越（因为不是请求），
但是特工经过高超的装扮技术（XSS），假扮成了制造厂里的一员,于是大门向特工打开(bypass同源策略)，然后特工达成目的。
（3）CSRF与XSS
刚开始看的时候有个误区，认为CSRF是一次性的，不会造成worm，后来才知道我当时太天真了，但是CSRF应该是单向的。
CSRF成功的前提用户必须登录到目标站点，且用户浏览了攻击者控制的站点。
与XSS最为不同一点是CSRF可以不用JS就能达到目的（GET和POST的区别）。
而且攻击者仅仅只需要给目标站一个请求就能成功。如0X01所说请求可以绕过同源策略。
还有一个天然条件是浏览器的安全缺陷：
浏览器在最初加入Cookie功能时并没有考虑安全因素。假设一个网站使用了Cookie，当一个用户完成身份验证之后.浏览器得到一个标识用户身份的Cookie，只要不退出或关闭浏览器。以后访问相同网站下的页面的时候，对每一个请求浏览器都会“智能”地主动附带上该网站的Cookie来标识自己，用户不需要重新认证就可以被网站识别。当第三方WEB页面产生了指向当前网站域下的请求时，该请求也会带上当前网站的Cookie。这种认证方式，称之为隐式认证。
除了Cookie认证方式之外，其他Web认证机制也面临同样的问题。比如HTTP基本认证，用户通过认证后。浏览器仍会“智能”地把用户名和口令附加到之后第三方发给站点的请求中。即使网站使用了安全套接字(SSL)来加密连接.浏览器也会”智能“地自动把SSL认证信息加到第三方发给站点的请求中。
因此第三方请求相当于无肉体的灵魂，虽然可以进入房子，但是只能四处飘荡毫无作为。
然而当灵魂遇到了自动附加上的肉体(cookie)就会变身组成一个完整的人，而且是通过了房子认证的人，属于房子的一部分。
那么灵魂一旦复活，就开始暴漏本性，执行恶意行为，虽然只能在房子里横，但是足以造成混乱。(如添加管理员，发表欺骗性状态等等)。
下图就是人人网爆出的一个CSRF利用页面代码,人人网的CSRF应该是屡见不鲜了，几乎每次搞个活动都会爆出吧。
| 脚本页面http://bookman.sinaapp.com/doover.php，访问该页面后会发送一条状态“已经结束了，这是我的自白，想明白原理的看我日志就好。http://bookman.sinaapp.com/doover.php” |
由图可以看出CSRF的代码是在第三方站点就可以执行了，所以说即使有对输入的检查，CSRF一样都可以绕过，所以一个应用程序如果有XSS漏洞，那么极大可能会有CSRF漏洞，但是一个应用程序没有XSS漏洞，并不能代表没有CSRF漏洞。
