XSS(Cross Site Script)：跨站脚本，也就是javascript脚本注入，一般在站点中的富文本框，里面发表文章，留言等表单，这种表单一般是写入数据库，然后再某个页面打开。
防御：
1，在用户表单输入的数据进行过滤，对javascript进行转义，然后再存入数据库；
2，在信息的展示页面，也要进行转义，防止javascript在页面上执行。
CSRF(Cross-site request forgery)：跨站请求伪造，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用，与XSS不用的是：XSS利用的是站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。
比如黑客A在自己的网站恶意注入了一个src的网址，是个恶意请求访问，类似银行转账，小白刚好登陆过自己银行系统，浏览器目前还保留有登陆过的cookie，小白点击了黑客A的网站里的银行恶意请求，此时该请求后台以为是小白自己想要访问的，因为带了小白自己的cookie，就去处理小白的请求了。但是黑客A拿不到服务器的response的，只是伪造了请求参数。
无论是GET请求还是POST请求都可能存在CSRF攻击，无论是php后台还是java后台，都是可以区分是哪种请求方式。如果是get请求，则在危险网站B中直接使用src标签进行get请求，如果是post请求则需要写一个form表单，进行post伪造请求，也是可以实现的。最常用的就是使用一个<img>标签，post请求比较麻烦。
CSRF攻击其实就是源于【WEB的隐式身份验证机制】。虽然可以保证一个请求是来源于某个用户的浏览器，但是却无法保证该请求是用户批准发送的！！！其根本原因就是Web站点所验证的是Web浏览器而非用户本身。
主要原因是同一个浏览器会共享cookie，防止CSRF的方法：只要确保请求是自己的站点发出的即可。例如：处理请求的时候加上验证：Cookie+Token。
防御：客户端和服务端
1，Request header里的Referer参数不同
Referer参数是请求源地址参数，黑客A的请求Url是自己的，而真正银行系统的源地址跟黑客A的不同，可以利用Referer的不同加以预防，但是Referer是浏览器的，黑客可能篡改，所以不能完全保证安全。【来源记录很容易伪造】
2，请求Url中加上Token验证
无论是get还是post请求加上一个server返回的token参数校验，Referer+token可以有效防御。
3，服务端：思想是在客户端加上伪随机数
验证码，每次用户提交的时候填写一个图片上的随机字符串，可以完全解决CSRF，但是用户体验不好。
token（不同的表单包含一个不同的伪随机数）
【完】
天才源于勤奋