XSS攻击

XSS的全称是Cross-site scripting,翻译过来就是跨站脚本。script可以跨域加载脚本这个特性，合理利用比如JSONP。如果不合理利用，比如某个坏人通过某种方式，让你的浏览器去加载恶意的javascrpt脚本，必然就会导致敏感信息被盗或者财务损失。最常见的就是XSS攻击，其实就是注入恶意脚本。真是凡事都有利有弊，就看如何使用了。常用的XSS攻击手段和目的有如下几种：

盗用cookie，获取敏感信息。
利用植入Flash，通过crossdomain权限设置进一步获取更高权限；或者利用Java等得到类似的操作。
利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻击）用户的身份执行一些管理动作，或执行一些一般的如发微博、加好友、- 发私信等操作。
利用可被攻击的域受到其他域信任的特点，以受信任来源的身份请求一些平时不允许的操作，如进行不当的投票活动。
在访问量极大的一些页面上的XSS可以攻击一些小型网站，实现DDoS攻击的效果。

如果某一个字符串里面有var a = 1;<script>alert('我是你大爷')</script>;var b = 2;这种类型的字符串。而且我们刚好要通过script标签加载。那么他就会弹出一个我是你大爷。避免的方式就是把存在这种可能性的地方都处理过，如果包含类似<script>这种字符的脚本就处理掉或者干脆返回错误。目前最常见的预防操作有如下几种：

将重要的cookie标记为http only,这样的话Javascript 中的document.cookie语句就不能获取到cookie了。
只允许用户输入我们期望的数据。例如:年龄的textbox中，只允许用户输入数字。而数字之外的字符都过滤掉。
对数据进行Html Encode处理。
过滤或移除特殊的Html标签，例如:<script>,<iframe>,<for<,>for>,"for。
过滤JavaScript事件的标签。例如"onclick=","onfocus"等等。

CSRF攻击

这玩意我了解不多，也无法做出模拟操作。跨站请求伪造（英语：Cross-site request forgery），也被称为one-click attack或者session riding，通常缩写为 CSRF 或者 XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。[1] 跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

我的理解就是，比如你刚去淘宝买了东西，并且浏览器有你的session护着cookie之类的信息。然后你马上又进入一个不该去的网站，并且点击了里面的一个淘宝链接，然后在你不知情的情况下做一些违法操作。这样阿里后台是不知道的，因为你刚刚通过合法手段买了东西，从而达到在你不知情的情况下，而且淘宝也信任你的情况下，畏畏缩缩偷偷摸摸的干坏事。

SCRF预防

检查Referer字段,通过这个字段来判断用户是从那个地址跳转到当前地址的。HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。以上文银行操作为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.examplebank.com之下，这时候服务器就能识别出恶意的访问。这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。

添加校验token,这个就最常见了，现在那个前端网站还不加一个验证码啊。不管你如何千变万化，你验证码中是用户数据的吧，而且现在好像越来越流行手机号码验证了。CSRF的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再执行CSRF攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中，其内容是一个伪乱数。当客户端通过表单提交请求时，这个伪乱数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪乱数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪乱数的值，服务器端就会因为校验token的值为空或者错误，拒绝这个可疑请求。