前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >WEB开发常见的安全漏洞和解决思路

WEB开发常见的安全漏洞和解决思路

原创
作者头像
windwei
修改2020-02-11 11:55:58
修改2020-02-11 11:55:58
2.3K0
举报
文章被收录于专栏:魏佳新

一,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.对于特别敏感的操作,可以进行二次权限校验

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一,SQL注入
    • 1.布尔型盲注
      • 2.报错型注入
        • 3.union注入
          • 4.SQL堆叠查询
          • 二,CSRF漏洞
          • 三,SSRF漏洞
          • 四,越权漏洞
            • 1.水平越权
              • 2.垂直越权
              领券
              问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档