一，SQL注入
SQL注入时web开发中最常见也是危害性最大的安全漏洞，SQL注入攻击可能会导致 服务器故障，数据泄漏，数据被恶意删除等等严重后果。
SQL注入最常见的方式有：
1.布尔型盲注
在互联网刚刚兴起的时候，该方法常常会被用来恶意登录一些安全性不高的网站：
代码语言：sql复制SELECT * FROM users WHERE user_name ='zhangsan' and password ='mima';如果用户在密码框里填入 'or1=1or1='，那么上面的SQL 就变成了
代码语言：sql复制SELECT * FROM users WHERE user_name ='zhangsan' and password ='' or 1 =1 or 1='' ;这样就可以绕过密码校验，登录为任意用户了
2.报错型注入
一个常见的语句为 ：
代码语言：javascript复制SELECT * FROM users WHERE id=1 AND user_name ='zhangsan' 通过修改 zhangsan 这个 入参，很容易将SQL拼接为
代码语言：javascript复制SELECT * FROM users WHERE id=1 AND user_name= 'zhangsan' AND (SELECT 1 FROM (SELECT COUNT(*),CONCAT(USER(),FLOOR(RAND(0)*2))X FROM information_schema.tables GROUP BY X)a) AND 1='1';这个语句会报一个固定的错误
显然，你用来登录Mysql的用户名就暴漏了
3.union注入
这种比较好理解，就是在原来的select 语句上通过union的方式，增加新的信息，将SQL拼接为
代码语言：javascript复制SELECT * FROM users WHERE id=1 AND user_name ='zhangsan' union select * from other_table 这种方式可以查询到你的任意表的信息，严重的话可能会被脱库。
4.SQL堆叠查询
这种跟 union 类似，可以将SQL拼接为
代码语言：javascript复制SELECT * FROM users WHERE id=1 AND user_name ='zhangsan' ; select * from other_table更为严重的是，分号后面的语句时可以随意写的，如果时拼上 drop 或者 delete 之类的语句 就可以会造成删库的风险了。
SQL注入的攻击最常见，影响也最大，SQL注入的本质是将 用户本来应该传入的 “数据” 变成了 程序 会执行的“代码”，从根源上解决这个问题，就是不要让 数据变成代码，最好的方式就是预编译了。
如果时已经写完了的历史代码，修改起来非常麻烦的话，可以推荐使用腾讯云的waf ，waf 可以帮助用户解决很多安全防护的问题 ：https://cloud.tencent.com/product/waf
二，CSRF漏洞
CSRF跨站点请求伪造(Cross—Site Request Forgery)，跟XSS攻击一样，存在巨大的危害性,攻击者盗用了你的身份，以你的身份来调用后台接口，对服务器来说这个请求是完全合法的，但是实际上，这个接口的调用，你却并不知情。
简单模拟一下整个过程如下：
1. 张三打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；网站A 有一个接口为http://www.a.com/deletedata?id=100 ，那么正常情况下，因为张三已经登录了网站A，那么他是可以直接访问这个接口的。
2. 张三在同一浏览器中，打开一个TAB页访问网站B；网站B 上有这么一段代码 <a href ='http://www.a.com/deletedata?id=100 ' > 查看 </a> ，这样的话 如果张三在B网站上点击了 查看 这个 按钮，那么实际上 ，他就删除了 在 A网站上的 数据了。
当然例子里是个 deletedata ，而实际上这个接口的含义也可能是查询了某个数据，甚至时转了一笔钱等等，那么影响就非常大了。
要防治CSRF 漏洞，一般有两种方法：
1.验证 HTTP Referer 字段
HTTP Referer是header的一部分，当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器该网页是从哪个页面链接过来的，服务器因此可以获得一些信息用于处理，以上示例中，如果A网站做了这个校验，那么他就可以识别出 deletedata 这个请求时来自于 B网站而不是A网站自身，就可以拒绝掉这个请求了。
这种方式最常见也最简单，但是却并不是最安全的，毕竟Referer是依赖浏览器的，每个浏览器对 Referer的实现可能不一样，对于部分浏览器，Referer 甚至是可以篡改的 。另外，由于网站会记录 Referer信息 ，在用户对隐私的问题越来越敏感的今天，可能会带来隐私风险问题。
2.在请求中增加 token 并验证；
CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，是因为黑客利用已知信息以及cookie中的未知信息 来发起了攻击，那么，如果我们添加一个不能伪造的并且不在cookie中的未知信息，那么攻击就无法产生了。因此，我们可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务端进行token校验，如果没有token或者token的值不正确，我们就认为这是一个非法的请求，拒绝掉他就可以了。
三，SSRF漏洞
SSRF是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。因为请求本身是由服务端发起的，因此可以通过这个请求调用到服务端的一些内部接口，探测内网的信息，攻击内网的服务等等。
可能会产生SSRF 漏洞的地方主要有：
1.能够对外发起网络请求的地方
2.请求远程服务器资源的地方
3.一些邮件系统，文件上传，文件处理系统，在线处理工具等等
举一个简单的示例：
假如 A网站有一个功能，就是用来下载一些第三方的数据的，URL 为 http://a.com/downloadurl="http://b.com/b.jpg",
执行逻辑上其实就是简单的 wget -Ob.jpg http://b.com/b.jpg 这样的。明面上，这个功能很简单，就是将一些网站 ，比如 b.com 上的 图片给下载下来保存。看起来没啥问题
但是，如果这里的参数被人利用 改成了 http://a.com/downloadurl="http://127.0.0.1/deletedata?id=1" ，那么当你执行 weget -Ob.jpg 的时候，就等于是执行了内部接口 deletedata了，这样就会对内部系统造成攻击。更深层次的，如果是用的其他一些协议，比如 downloadurl 为 file:///etc/passwd ，或者 dict://127.0.0.1:6379/info 之类的，就可以直接拿到服务器上的一些数据信息了。
防治SSRF漏洞的思路主要就是禁止对不安全的资源进行下载和访问：
1.禁用不需要的协议，仅仅允许http和https请求，并禁止30x跳转，可以防止类似于file://, gopher://, ftp:// 等引起的问题。
2.服务端的服务都需要做访问授权，避免root启动，禁止非正常用户访问服务。
3.设置URL白名单，限制内网IP的请求，过滤输入信息，严格判断输入的URL是不是安全的URL
四，越权漏洞
越权漏洞也是常见的web漏洞，一般分为分为水平越权和垂直越权两种，水平越权指的是攻击者尝试访问与他拥有相同权限的用户的资源，比如A本来是只能看A自己的用资料的，但是当他把URL 为getInfo?id=a 修改为 getInfo?id=b 后 就可以看到b的数据了。垂直越权是指普通的用户获取到了比他级别更高的用户的权限，如果普通用户获取到了管理员的权限。
1.水平越权
水平越权里，一个最常见的示例就是攻击者通过遍历ID 来进行信息的窃取。比如某个页面如下：
这个页面在显示列表时，就通过后台进行过滤，只显示了当前登录者的任务列表
任务名 | 查看详情 |
|---|---|
任务1 | getInfo?id=1 |
任务2 | getInfo?id=2 |
任务3 | getInfo?id=3 |
列表里的数据，攻击者时没法伪造的，但是这里有一个查看详情的链接，如果这个 getInfo 接口本身没有做好鉴权的话，那么攻击者就可以通过遍历ID 的方式来查到到了所有用户的详情数据了，严重的甚至可能会被脱库。
2.垂直越权
垂直越权的常见例子就是菜单的展示，比如管理员可以看到所有的菜单，包括“系统管理” 这个菜单，而其他用户是看不到 “系统管理” 这个菜单的，但是，如果某个用户通过特殊途径，获取到“系统管理” 这个菜单的URL ，他直接通过这个URL 来进行访问，发现时可以访问，这个就是产生了垂直越权的漏洞了。
要避免越权漏洞，主要还是需要从逻辑上进行完善，以下有几点建议：
1.所有的接口都要做到两层鉴权，包括接口本身的鉴权以及接口对应的数据的鉴权
2.鉴权，服务端对请求的数据和当前用户身份做校验
3.所有的鉴权都要在后台做，不能依靠前端来鉴权
4.对于会暴漏给用户的数据，尽量避免通过自增ID的方式来实现，最好有自己的生成器，让黑客没法通过遍历的方式来获取数据
5.对于特别敏感的操作，可以进行二次权限校验
