讲讲越权那些事

2015-01-14 14,192

简要

越权漏洞是比较常见的漏洞类型,越权漏洞可以理解为,一个正常的用户A通常只能够对自己的一些信息进行增删改查,但是由于程序员的一时疏忽,对信息进行增删改查的时候没有进行一个判断,判断所需要操作的信息是否属于对应的用户,可以导致用户A可以操作其他人的信息。​

6119d1c9ed8c4bf67f1477c79abb1b70

如何发现越权

为了不影响厂商的正常用户数据,通常在测试前,会注册两个帐号,来进行测试越权,测试越权时大家需要准备两个东西:

Firefox
burp suite

不管是正常模式和隐身模式的Firefox走的都是同一个代理,所以不需要重新进行设置,关于如何设置代理之类的内容,笔者在这里就不写了 :),写得太基础容易被吐槽,两个帐号暂且称为攻击者A、受害者B,笔者使用Firefox普通模式与隐身模式分别登录两个不同的帐号,如图所示:

44e6ee2c40fde1217e5ee3215d80b118

 

那么如何发现越权呢?正如上文所说越权一般都会存在在一些增删改查的地方,笔者就先从一些拥有敏感信息的地方(例如:收货地址/个人资料/用户订单等)进行测试,首先切换burp到Intercept is on 状态,点击收货地址,拦截到的请求如下:

GET /u/***addr.do?xcase=list&_t=1420876539083&_=1420876539084 HTTP/1.1
Host: www.***.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Accept: text/html, */*
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
Referer: http://***.com/member/
Cookie: cookie hide
X-Forwarded-For: 127.0.0.1
Connection: keep-alive

 

可以看到请求包是一个get请求,笔者猜想下访问这个页面所会执行的是伪sql为:

Select 收货人,地址,邮编,手机号码 from 收货地址表 where 所属用户编号=1111

从上的伪sql语句来看,查某一个人的收货地址必定需要知道这个人的用户编号,仔细看了下请求并没有发现任何携带用户编号/姓名的参数,估计程序员把用户身份验证的标识存在session中,查询地址的时候再读取出来,这样就没有办法去修改了,那么就把这个数据包放行了,看到如下的页面:

e60bee58ca8efe09ffb0f12831caa620

 

继续看下面的功能,页面中存在 默认地址/修改/删除 三个选项,先点击一下修改,请求包如下:

POST /u/*****.do?&_t=1420879245405 HTTP/1.1
Host: www.*******.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Accept: text/html, */*
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://www.******.com/member/
Content-Length: 39
Cookie: cookie hide
X-Forwarded-For: 127.0.0.1
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
 
xcase=init&DeliveryAddrDto.addrid=82833

 

通过上面一个请求的包,假设伪sql语句为:

Select 收货人,地址,邮编,手机号码 from 收货地址表 where 收货地址编号=82833

这次的数据包是不是又是将校验用户身份的值存在session当中了呢:),在当前环境下,笔者猜测下几种状态:

用户身份标识存在存在session当中并使用它进行校验   = 不可越权
用户身份标识存在存在session当中没有使用它进行校验 = 可越权
未将用户身份标识存在session中 = 可越权(这点排除)

*这里的校验是指:校验对应的收货地址是否属于当前登录的用户

那么为了校验这两个状态,笔者直接把其中代表地址编号的DeliveryAddrDto.addrid参数改为82833或者前面数字,如果没有使用用户表示进行校验的话,就可以直接获取到其他收货地址编号的内容,实际测试结果是没有进行校验,如图所示:

dfff9beea37454a4eb2f99651a7e8874

 

总结

从上面的实例来看越权最简单的修复办法是用户对某一数据进行增删改查时需要去校验下所操作的数据是否属于该用户,回归漏洞本质,关注漏洞细节,欢迎更多的白帽子通过漏洞时间进行投稿:)

 

【原文:Sobug漏洞时间-讲讲越权那些事 作者:feng  SP小编整理发布】

Tags:

评论  (9)
快来写下你的想法吧!
  • Pis 2015-01-14 21:31:57

    越权这种逻辑漏洞还是很好找的 盯着增删改查的地方 细心的测试一下常常就会发现程序员的粗心大意

  • 09 2015-07-02 15:08:24

    看样子好简单。

  • Timmy 2016-09-26 15:40:55

    很浅显易懂,逻辑清晰讲得很好!

  • Clouds Flying 2017-02-03 9:47:41

    讲得很好啊

  • 1234 2017-03-17 10:43:38

    有点水

  • cdxampp 2017-03-31 10:23:54

    看到一处书写错误,“但是由于程序员的一时疏忽未对信息进行增删改查的时候没有进行一个判断”,双重否定。

SP小编

文章数:215 积分: 25

交流和分享以及愉快的玩耍

关注我们

合作伙伴