一种可能的新的漏洞类型

xsser (十根阳具有长短!!) | 2013-01-21 11:15

这个问题切实存在的,本人经历过

if($code=='xxxxx'){ 
.... 
updatecoin(); 
updatecode(); 
.... 

}else{ 
exit(); 
}

就是说系统可能给你个code,用于你兑奖买东西什么的,但是这个是一次有效的,用了就在数据库里设置无效,但是呢,假设同时来100个请求,这100个请求几乎同时到达webserver,同时到达php,但是因为更新数据库需要时间,所以其中很可能有20个请求执行的时候数据库里的code因为更新不及时都是有效的,所以呢就导致coin的重复增加了,这特别是在后面的数据库逻辑较为复杂的时候更容易出现


1#

c4bbage | 2013-01-21 11:17

YD

2#

shine (shield) | 2013-01-21 11:18

...,难道你不知道有一个叫“线程安全”的安全问题吗?

3#

小胖胖要减肥 | 2013-01-21 11:19

以后兑换的时候可以多线程跑下 家里就10m贷款估计跑不了那么多

4#

xsser (十根阳具有长短!!) | 2013-01-21 11:20

@shine 来聊聊嘛

5#

horseluke (微碌) | 2013-01-21 11:28

web的并发问题?

6#

小胖胖要减肥 | 2013-01-21 11:34

@shine 科普了 对于不做开发的很多东西基本一无所知

7#

Clar | 2013-01-21 11:34

同时的难度有点大,毕竟总有个先来后到。除非数据库那边更新速度跟不上流程了

8#

xsser (十根阳具有长短!!) | 2013-01-21 11:35

@Clar 事实上是可以的,几毫秒不算事儿

9#

GaRY | 2013-01-21 11:36

sae的线程操作原子性不是应该数据库接口自身保证么?你如果发现这个问题可以报告sae了.读写锁不同步

10#

小囧 ('';!--"<XSS>=&{()}) | 2013-01-21 11:38

我写代码的时候也有过这样的困惑, 特别是数据库负载均衡的时候    中间还有个主从同步的时间。 你查的是从库   更新的是主库。     严重关注中。。。。

11#

无敌L.t.H | 2013-01-21 11:39

这种不一定,毕竟有队列,有事务去控制,看上去是并发但是服务器不看作并发。

12#

波波虎 ( ) | 2013-01-21 11:46

应该设计应该需要考虑并发问题,做幂等性测试,存在此类问题的应用应该也比较多,程序员设计时未考虑好并发

13#

Jannock (what?) | 2013-01-21 11:51

线程安全确实也是个问题,遇到也多了。。

14#

Jannock (what?) | 2013-01-21 11:52

不过实际中,利用估计不好利用。。。一般出错了,很容易查出。

15#

horseluke (微碌) | 2013-01-21 11:52

突然想起@蟋蟀哥哥 ,他对这个有研究,因为以前他在OSChina上提过打重负荷的业务页面引发ddos,使得首页正常、但网站实质不可用

16#

Errorera | 2013-01-21 11:56

一种新的ddos?比如一个收藏夹功能 一个url就会请求一次,一个IP同时添加一千个url就会请求1000次 大量请求很容易就搞挂了服务器吧

17#

小胖胖要减肥 | 2013-01-21 11:59

@Errorera @horseluke 就是对某个弱请求点发动cc攻击,最好手里还有一堆ip

18#

pentest | 2013-01-21 12:01

@horseluke  这属于cc了吧

19#

Errorera | 2013-01-21 12:02

@小胖胖要减肥 亲身体验看到过运维处理这个问题的。即使能够利用这个弱点也是临时的,靠着POST日志 专业的团队在3分钟就分析出了问题所在

20#

erevus | 2013-01-21 12:05

我想到了DDOS 可是...这种DDOS只能生效一次,可能只会导致服务器瞬间的CPU负荷增加吧,

21#

shine (shield) | 2013-01-21 12:45

@xsser ^-^ ,好吧!随便说说啊(有些问题可能不准确)!由于一些语言的特性,有多线程机制,这样可以提高运行效率(有更多机会去抢占cpu的运行时间,因为cpu有个运行时间片(每个线程都只能固定运行一段时间,这个就不多说了。),在计算机基础中,应该都学过,cpu线程机的同步锁机制解决这个问题)。

例如:Java语言也有多线程特性,在早期的Struts框架中(这里是指Struts1),由于是使用一个servlet实例控制所有访问,所以有个线程安全的问题。

而在Struts2框架中改变了,使用拦截方式,一个访问对应创建一份实例。但不是说就能彻底解决这个问题,在局部代码区内,可能还是能发生类似情况,线程安全对于一般的开发者确实很难控制!

这里我们模拟一个卖票系统,就说铁道部卖火车票的场景:

假设:铁道部一共有100张票,10个窗口卖,如果第100张,同时被其中的两个窗口卖出,这样总票数是不是会出现-1张的情况(因为每卖出几张,总剩余票数会相应减去对应数字。)。所以这里Java引入了一个同步锁机制的关键字(synchronized),当有窗口要卖票时,就锁住这个总剩余票数,不允许其他窗口访问,卖完后再解开这个锁,别的窗口再进来卖!

或者,另一个转帐场景,我们知道,转帐可以简单分两步:一个帐号减少(A帐号),另一个帐号增加(B帐号)。

假设:当A帐号减少了相应金额这一时刻,突然ATM机断电了,是不是B帐号上的钱还没来得及增加?导致异步执行的安全问题!

假设转换sql执行(当然,银行肯定不是这样的。)我们在Java中可以把JDBC sql提交自动执行改为手动提交con.setAutoCommit(false);也就是数据添加时的事务处理这个问题!

简单代码实例:

try{
con.setAutoCommit(false);
sql1:A帐号减少金额
sql2:B帐号增加金额
con.commit();//手动提交
}catch (Exception  e) {
e.printStackTrace();
conn.rollback();//遇到异常,数据回滚。
}

问题简单的描述就是:多线程(异步)造成的变量覆盖(或异步执行不完整)等情况而引发的安全问题!

不过,楼主预测应该是对的,哥也目测一下,以当前电商对安全的实施程度,这个问题应该是泛滥!

22#

xsser (十根阳具有长短!!) | 2013-01-21 13:02

@shine 的确在数据库层面会考虑这个安全性,但是如果不使用存储过程的话,在语言层面是比较难保证这个问题的吧?

23#

horseluke (微碌) | 2013-01-21 13:06

@xsser 现在不是有种趋势说不搞存储过程咩,说搞存储过程不好作业务调整...

24#

xsser (十根阳具有长短!!) | 2013-01-21 13:11

@horseluke 那我就只能呵呵了

25#

shine (shield) | 2013-01-21 13:12

@xsser 在这里不是否定一些预防机制啊!说句实话,不管如何做它还是能出现,只是场景复杂度或几率多少的问题(也就是理论上还是能够发生),很难发现!

26#感谢(1)

小胖子 (z7y是我的,你们谁也不准抢~) | 2013-01-21 13:17

这种以前想到过 同步并发线程,只是没实现过、。

27#

shine (shield) | 2013-01-21 13:30

@xsser 不是说以后(特别是云计算到来)数据存储的趋势是NoSQL吗?NoSQL有存储过程这玩意没?

28#

shine (shield) | 2013-01-21 13:46

@xsser 乌云提交漏洞时,不是也有个类似问题吗?

在网络延迟提交时,如果用户多点几下按钮,会导致重复提交,你是如何修复的?

29#

小胖胖要减肥 | 2013-01-21 13:51

@shine 剑心手工啊,不是有过重复的情况,现在大多还是要审核的,小部分重复么再删掉一个

30#

Nimda (吃你的麻花去吧) | 2013-01-21 13:53

玩网游加血的时候,快速单击红药,可以短时间内忽略红药CD,是这个意思不 @xsser

31#

xsser (十根阳具有长短!!) | 2013-01-21 13:59

@Nimda 这位精辟!

32#

一刀终情 ((这个怎么实现的呢?) ?(1314520)) | 2013-01-21 14:02

@xsser 实测可行的,06年左右,上学那会儿,一张移动充值卡,同时多人用电话充值,最后同时按#确认,有机会同时充值2个以上,几率还不小

33#

核攻击 (统治全球,奴役全人类!毁灭任何胆敢阻拦的有机生物!) | 2013-01-21 14:05

这种问题只存在于提交指令后直接查询数据库的情况下。

很容易解决的。。。

高级方案:

1、用户提交查询数据

2、服务器端接收到请求后,将其加入一个任务表(按顺序排列)。

3、一个单独的后台的处理程序,遍历任务表,挨个执行任务,然后将执行结果通知到用户。

这样的话,你如果重复提交,只会在任务表重复添加数个任务,而由于任务表是挨个执行的,所以即使有大量重复任务,也不会存在什么同时写入数据库的情况,治根。

这种的已经普遍应用了,例如电商的下订单系统,用户下订单后,并非立即执行,而是加入后台任务表,挨个处理后,再告诉用户订单是否成功。

轻量级用法,例如 Asp 的:

Application.Lock

Application.UnLock

推荐阅读:由12306.cn谈谈网站性能技术

“B2C的电商基本上都会把这个事干成异步的,也就是说,你下的订单并不是马上处理的,而是延时处理的,只有成功处理了,系统才会给你一封确认邮件说是订单成功。”

34#

livers (如梦似幻) | 2013-01-21 14:08

我来补充一点。  到系统底层 最小的操作就是原子操作 在汇编里面即LOCK 指令,这种操作就是不会被其他线程打断,就是CPU会一口气执行完成。 当然这是在单CPU 多CPU操作要用到原子锁。(显卡里面多线程原子操作不太一样)这是底层,到了应用层就是层层封装底层的原子锁操作,为了避免 类似哲学家就餐这样的死锁出现,设计出了互斥变量 接着就是shine 那一段。

35#

核攻击 (统治全球,奴役全人类!毁灭任何胆敢阻拦的有机生物!) | 2013-01-21 14:09

还有啊,这个不是什么“新型漏洞”,而很古老的同步查询数据一致性问题……

36#

livers (如梦似幻) | 2013-01-21 14:12

@shine NoSQL 只是key-value的存储方式,无法替代关系数据库

37#

咚咚呛 (邪恶的瞅瞅!!) | 2013-01-21 14:13

脑子瞬间涌现出 事件 互斥 向量。。。

38#

shine (shield) | 2013-01-21 14:29

@核攻击 安全问题与安全漏洞应该还是有区别的,只是“新型漏洞”的本质是你所说的安全问题造成的!

39#

leehenwu (关注安全) | 2013-01-21 14:55

很多这种情况 有的秒杀也会出现多单的情况

40#

xsser (十根阳具有长短!!) | 2013-01-21 15:04

@核攻击 我是觉得乌云上没发现这案例撒

41#

斯文的鸡蛋 (以前在网上,没人知道你是一条狗;现在在网上,狗都知) | 2013-01-21 17:20

@xsser 那可以预感今年会出现了

42#

_Evil (HackEnd) | 2013-01-21 17:59

@xsser 饭卡两边打一边扣钱;最简单的线程了..

43#

_Evil (HackEnd) | 2013-01-21 17:59

@xsser http://zone.wooyun.org/content/526

44#

px1624 | 2013-01-21 18:47

这个不就是当年qq牧场的卡位bug么、、、配合鼠标电击器和变速齿轮,那是刚刚的啊

45#

lake2 (浮夸) | 2013-01-21 19:43

用事务型开发就可以规避吧

46#

蟋蟀哥哥 (popok是孙子!![just for fun]) | 2013-01-22 09:52

@xsser 我也认为这是安全问题,而不是漏洞。特别是在电商这些等,有库存系统内。对这种“锁”是必须的。

但是这种“锁”又容易引起DOS的问题。。比如目前本人管理的一套系统中,数据库是oracle的。但是某一张表是大家共用的(关于库存类的表),并且有“锁”。如果出现并发炒作(比如同时发某一人的货),就会出现死锁的问题。导致整个系统不能用使用。。

只要稍加利用,就可以针对该安全问题发动DOS攻击。。当然,这种问题还需要自己业务上配合才能造成。。

锁这个问题的存在,在数据不是很重要的业务中无所谓,比如你在头顶上说的code,如果是某游戏的推广码,重复就重复了,无所谓的。。但是,在特定的业务下是非常纠结了。。。

@horseluke 上次我说的那个DDOS,前台不垮,后台瘫痪。主要是因为服务器有缓存,对方把我Mysql搞瘫痪了,但是我的前台是正常的。和今天讨论的这个话题没有什么关系。

47#

园长 (你在身边就是缘,缘分写在数据库里面。) | 2013-01-22 10:17

多线程,线程同步。还比银行转账.

48#

shine (shield) | 2013-01-22 10:48

@蟋蟀哥哥  楼主可能有现实主义情节,想把它变成一个漏洞。因为有些时候,一个漏洞,在现实中可能很难利用,危害甚至很难出现,但我们还是把它当成一个安全漏洞对待;而有些安全问题,在现实中危害表现得很严重,却得不到漏洞待遇!

@园长 注意最后总结,是对应楼主说的两个不同问题的场景(虽然我们可以把它们当成一个概念去理解,但线程与异步执行严格来讲还是有点区别的)!

49#

蟋蟀哥哥 (popok是孙子!![just for fun]) | 2013-01-22 11:44

@shine 关键是出一个实例才行,并且要真实的威胁到了数据安全。应该才能定位为漏洞。。

当然,由于代码的原因,在高并发的时候暴露服务器路径一般来说还是环境设置的问题。没有关闭直接报错。

50#

shine (shield) | 2013-01-22 11:57

@xsser  楼主上洞吧!这个帐号快一年没在乌云提交漏洞了,也别顾及是什么应用的安全问题了。

51#

xsser (十根阳具有长短!!) | 2013-01-22 12:27

@蟋蟀哥哥 我觉得相当威胁了 等于是变相的篡改啊

52#

shine (shield) | 2013-01-22 12:40

@xsser 恩!对于简单的应用,应该没多大的威胁,因为能够快速发现问题所在并修正数据;

但如果是一个,数据操作相互依赖且环节比较多的业务逻辑,如果发生的次数越多,恐怕就很难发现并修正错误数据了!

觉得应该叫“数据准确性”好点吧(目前,这个安全问题从数据上考虑应该够了!)?

53#

蟋蟀哥哥 (popok是孙子!![just for fun]) | 2013-01-22 16:30

@xsser 要给出案例啊。。而且高并发一般情况下,对敏感数据都是有考虑的

54#

horseluke (微碌) | 2013-01-22 23:45

@shine@xsser 原来以前有人发过你们说的线程安全或者并发问题:http://zone.wooyun.org/content/526

55#

乱雪 (hi.baidu.com/lu4nx) | 2013-01-24 10:13

这个可以用队列或者AMQP解决

56#

phantom | 2013-01-24 10:20

这就是race condition的问题撒 不是新的漏洞类型撒

57#

gainover (">_< ' / & \ 看啥,没见过跨站字符么) | 2013-01-24 19:52

@蟋蟀哥哥 案例还是有的啦,页游里出现的还是挺多的。用这个刷过腾讯某游戏的游戏B和抽奖。正常每天抽一次,俺每次都是10个并发,就能得到10个奖品。

58#

Passer_by (腾讯微博的Passer-by不是我) | 2013-01-25 09:41

@gainover 我刷别的页游领新手包。。。。

59#

蟋蟀哥哥 (?????????????????????????) | 2013-01-25 12:26

@gainover 。。私聊给我啊。。。啥游戏。。

60#

softbug (算了,我还是做好我自己的东西) | 2013-01-25 16:10

安全和写程序最能结合 不会编码的安全工作者有时候问的问题很蛋疼

61#

whirlwind (息壤最大代理商,北京/香港不限内容云服务器,五线BGP/10兆独享/4千兆硬防,备案/可信,QQ493633628,海外服务器请联系Mujj-------------------------------------------------------无损音乐网 http://wusunyinyue.cn----------------------月色仍如昔,江上有归帆!-----------------------------) | 2013-02-14 21:07

坑跌,好久之间就测试,到现在几年了,没成功过一个站

62#

陈再胜 (http://t.qq.com/mibboy求收听) | 2013-02-14 23:30

线程安全的问题么?剑总说的我看不懂,看到上面的大概例子,大概知道了是类似于CC一样的东西······

63#

NiceWorm | 2013-02-15 18:18

数据库事务...

64#

zeger | 2014-01-02 07:24

@gainover 求并发WY思路··

65#

核攻击 (统治全球,奴役全人类!毁灭任何胆敢阻拦的有机生物!) | 2014-01-02 09:19

楼上你干啥,挖坟?

66#

Coner | 2014-01-02 10:12

这就相当于是在抢CGI和database的时间差啊

[浏览更多讨论]

留言评论(旧系统):

Mr.V @ 2013-01-21 15:47:13

运用高级方法 效率岂不是变低 原本输入即可显示的结果还要等系统排队做判定

本站回复:

又没叫你全部都用队列方法啊,只是将一些敏感写入数据、有可能出现数据同步问题的地方使用,什么只读查询,直接查询就行了,效率不会有多低。

佚名 @ 2013-01-21 21:11:13

锁。。

本站回复:

╮(╯_╰)╭

[暂无回复] @ 2013-01-22 16:47:17

警告: 你的访问频率太快,请不要快速刷新页面或者尝试 CC 攻击! 你的 IP 地址将于 3 秒后解封,在此期间你不能访问本站任何页面,届时本页面会自动刷新!

本站回复:

卖萌可耻…… ╮(╯_╰)╭

safe121 @ 2013-01-23 13:12:40

DZX2.0及之前的版本出现的问题。。多线程处理的时候出现的bug。。发回复的时候,服务器限制30秒一个帖子,你按的特别快,可以刷整整一页。。。

本站回复:

典型的处理流程问题……