类型及原理及解决方案
一、CSRF
概念：跨站请求伪造，冒充受信任用户，向服务器发送非预期请求的攻击方式。例如，这些非预期请求可能是通过在跳转链接后的 URL 中加入恶意参数来完成:
简单的说，就是利用游览器对用户的信任，比如，用户已经登录了ww.aaa.com，自然aaa这个网站就会将用户的登录状态session存在cookie中；
然后，aaa.com这个网页有一个对作品点赞的功能，点赞提交地址为aaa.com/api.like?id=777；
这时，另外一个叫www.bbb.com的网站，放了这样一个元素<img src="aaa.com/api.like?id=888">，这样的话，一旦用户进入这个bbb.com页面，就会请求aaa.com这个网站的点赞接口，而且点赞的用户对象是888；
最后因为用户的登录信息尚未过期，那就等于给id为888这个作品点赞了，然而，用户并不知情。
首先，用户登录了没有CSRF防护的www.bank.com。该网站有一个转账链接http://www.bank.com/transferFunds?amount=money&destinationAccount=account_id
然后，用户又访问了攻击者发送过来的链接比如叫http://www.hack.com/csrf_attack。该页面具有以下关键代码<img src="http://www.bank.com/transferFunds?amount=1500&destinationAccount=123456789“ width="0" height="0" />
最后，浏览器自动请求src指向的链接http://www.bank.com/transferFunds?amount=1500&destinationAccount=123456789，由于请求的是www.bank.com所以浏览器会自动带上www.bank.com的cookie。链接+登录cookie都已具备，www.bank.com并没有其他检查，所以向123456789转账1500块的请求就会被成功响应。
防御：
- 后端判断referer是否合法（不推荐）
通过HTTP的referer可知道，用户是通过哪个网站发送这个请求的。但是referer的判断并不是好方法，有各种方式可以绕过的方法，具体可见 CSRF 花式绕过Referer技巧>> - 每次请求带上token
比如laravel，在后端模板渲染的时候会提供一个csrf的token，这样的话，不同域的网站是拿不到token的，所以也就防止了csrf了。
5.2.2 token检测法
token就是服务端返回给客户端类似sessionid那样一长串的类值（长是为了防暴力猜解）。csrf依赖于浏览器该问链接时自动对应网站的cookie带上，token不放cookie（一般form表单加个hidden属性的input标签来存放）csrf就没法获取token，这样我们就可以通过检测发送过来的数据包中是否有正确的token值来决定是否响应请求。
在讲清token防御的原理后，我们再来讲token的设计，因为token方式给人的感觉很复杂令人望而生畏。
我们首先明确一个问题，就是能够防止csrf攻击的token，并不需要每次请求都不一样，在用户登录后到退出前的这整个过程中的所有请求token完全可以是一样。因为（在基于没有其他漏洞会泄漏本次会话的token的设想下）黑客是无法获取用户的tokne，所以又何必每个请求都要生成一个新的token呢。（token每次请求都要不一样的想法是受防重放攻击的影响）只考滤防csrf不考滤防重放的情况下，token设计就简单多了。
使用sessionid作为token设计：在csrf中cookie是浏览器自己带上的，本质而言用户的sessionid并未丢失（也就是攻击者并不能知道sessionid是多少），基于此我们完全可以不用另传一个值只需直接将sessionid作为token即可（或者也可以做些运算比如取sessionid的某些值做个md5来做为token，意思都差不多）。判断代码类似 if session["id"] == $_POST["token"]
与sessionid同时返回的token设计：在生成sessionid的同时生成一个token（服务端token可以存于session变量中）返回给客户端，客户端保存该token每次请求时都在form表单中提交该值。判断代码类似if session["token"] == $_POST["token"]
二、xss
概念：
指恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。
