web安全类主要分为两个部分：CSRF和XSS

一、CSRF

基本概念：CSRF,通常称为跨站请求伪造，英文名Cross-site request forgery 缩写为CSRF;

 

怎么防御

1、Token验证：那个伪造的请求只会自动携带cookie，不会自动携带token，所以验证时，如果没有token，就会避免攻击；

2、Referer验证：页面来源，服务器判断是否为本站点下的页面，如果是才会执行，

3、隐藏令牌：

一个用户的会话cookie在浏览器没有关闭的时候，是不会被删除的，所以可以换个思路，不再去偷这个cookie了，相反，可以在web.com中构造一个领奖页面，里面包含一个连接，让用户去惦记，例如：

恭喜你获得了iPhoneX一台，快来领取吧

这得先知道icbc.com.cn的转账操作的url和参数名称。

如果这个用户恰好登录了icbc.com，那他的cookie还在，当他禁不住诱惑，点了这个链接后，一个转账操作就神不知鬼不觉的发生了。

注：为了方便展示，本文举了一个非常简单的案例，银行实际的转账操作要远远比文章描述安全的多。

除了让用户点击外，还可以使用img标签<img src="www.icbc.com.cn/transfer?toAccountID=黑客三兄弟的账户&money=金额">，只要用户打开了这个页面，不点击任何东西，就会发生转账操作。

所以现在有很多邮箱默认是不显示邮件中的图片的。

如果icbc.com.cn的转账操作需要form表单，是POST操作，那么可以自己创建一个表单，放到一个不可见的iframe中，用户只要一访问，就用JavaScript自动提交。

总之，只要用户在访问icbc.com.cn的时候，访问了web.com，就极有可能中招，这种方式，只是利用了一下合法的Cookie，在服务器看来，发出的这个请求是一次合法的请求。这个就叫跨站请求伪造，Cross Site Request Forgest (CSRF)。

防范措施：

1.用户在icbc.com.cn转账，显示转账的form，除了常用的字段之外，额外添加一个token:

这个token是icbc.com服务器端生成的，是一个随机的数字。

2.用户的转账数据发送的服务器端，icbc.com就会检查从浏览器发过来的数据中有没有token，并且这个token的值是不是和服务器端保存的相等，如果相等，就继续执行转账操作，如果不相等，那这次POST请求肯定是伪造的。

这个token是服务器端生成的，无法伪造，CSRF的手段也不行了。

二、XSS

基本概念：XSS（cross-site scripting 跨域脚本攻击）

XSS，即（Cross Site Scripting）中文名称为“跨站脚本攻击”。

XSS的重点不在于跨站攻击而在于脚本攻击。攻击者可以利用 web应用的漏洞或缺陷之处，向页面注入恶意的程序或代码，以达到攻击的目的。

通俗的来说就是我们的页面在加载并且渲染绘制的过程中，如果加载并执行了意料之外的程序或代码（脚本、样式），就可以认为是受到了 XSS攻击。