东营网站制作方案,wordpress 添加外部链接,景区vi设计案例,站群软件哪个好目录
漏洞原因
环境搭建
复现
A.无锁无事务时的竞争攻击
B.无锁有事务时的竞争攻击
防御
A.悲观锁加事务防御
B.乐观锁加事务防御
总结 漏洞原因 Race Condition 发生在多个执行实体#xff08;如线程、进程#xff09;同时访问共享资源时#xff0c;由于执行顺序…目录
漏洞原因
环境搭建
复现
A.无锁无事务时的竞争攻击
B.无锁有事务时的竞争攻击
防御
A.悲观锁加事务防御
B.乐观锁加事务防御
总结 漏洞原因 Race Condition 发生在多个执行实体如线程、进程同时访问共享资源时由于执行顺序的不确定性导致程序的最终行为依赖于这些实体的执行时序。如果程序逻辑未正确处理这种并发访问就会产生意外的结果。
环境搭建
从github上下载源码GitHub - phith0n/race-condition-playground: Playground for Race Condition attack
然后拖到虚拟机上解压
unzip race-condition-playground-main.zip
之后重命名并修改.env.default文件
rootsxc-ubuntu:~/race-condition-playground-main# mv .env.default .env 安装依赖的库
pip3 install -r requirements.txt 依赖库python3 manage.py migrate 生成数据表python3 manage.py collectstatic 生成前端代码python3 manage.py createsuperuser 添加用户python3 manage.py runserver 0.0.0.0:8080 启动 最后还要修改一下templates目录下的form.html将form表单的提交方式修改为form-data流 复现
A.无锁无事务时的竞争攻击
class WithdrawView1(BaseWithdrawView):success_url reverse_lazy(ucenter:withdraw1)//form表单验证//已经通过验证def form_valid(self, form):amount form.cleaned_data[amount]self.request.user.money - amountself.request.user.save()models.WithdrawLog.objects.create(userself.request.user, amountamount)return redirect(self.get_success_url())
整个操作没有使用事务也没有加锁理论上存在Race Condition漏洞。
1.登录后台
http://192.168.217.128:8080/admin
2.在user模块添加Money 3.进入ucenter提现页面
http://192.168.217.128:8080/ucenter/1/ 4.点击提交使用burp抓包发送到repeater模块。注意要将拦截到的包drop掉不然10块钱直接没了没法测试了。然后将包内容复制到Yakit上的WebFuzzer下的request里面并设置好重复发包数和并行线程数。 5.点击发送请求我们会在request模块右边看到响应结果很幸运一次就成功了
在前端页面的withdrow logs模块也看到了日志信息 竞争成功
B.无锁有事务时的竞争攻击
新编写一个WithdrawView2加上transaction.atomic修饰符成功则成功失败则回滚class WithdrawView2(BaseWithdrawView):success_url reverse_lazy(ucenter:withdraw2)transaction.atomicdef form_valid(self, form):amount form.cleaned_data[amount]self.request.user.money - amountself.request.user.save()models.WithdrawLog.objects.create(userself.request.user, amountamount)return redirect(self.get_success_url())同样使用Yakit测试 发现结果并没有什么区别
防御
A.悲观锁加事务防御 Django在ORM里提供了对数据库Select for Update的支持结合Where语句可以实现行级的锁。 使用SELECT FOR UPDATE获取到的数据库记录不会再被其他事务获取。
这样就可以保证我们在同一个事务内执行的操作的原子性这是一个典型的悲观锁。
“悲观锁”的意思是我们先假设其他线程会修改数据所以在操作数据库前就加锁直到当前线程释放锁后其他线程才能再次获取这个锁。
乐观锁通常通过版本号Version或时间戳Timestamp实现。
我们使用select_for_update()来实现一个WithdrawView3class WithdrawView3(BaseWithdrawView):success_url reverse_lazy(ucenter:withdraw3)def get_form_kwargs(self):kwargs super().get_form_kwargs()kwargs[user] self.userreturn kwargstransaction.atomicdef dispatch(self, request, *args, **kwargs):self.user get_object_or_404(models.User.objects.select_for_update().all(), pkself.request.user.pk)return super().dispatch(request, *args, **kwargs)def form_valid(self, form):amount form.cleaned_data[amount]self.user.money - amountself.user.save()models.WithdrawLog.objects.create(userself.user, amountamount)return redirect(self.get_success_url())
对于当前这个场景我们再次尝试使用Yakit进行竞争攻击 可见此时返回包只有一个302响应了 这意味着程序是按照预期运行没有发生Race Condition问题。
B.乐观锁加事务防御
我们观察上述的WithdrawView3代码其实会发现一个问题如果有大量读操作的场景下使用悲观锁会有性能问题。因为每次访问这个view都会锁住当前用户对象此时其他要使用这个用户的场景如查看用户主页也会卡住。
另外也不是所有数据库都支持select for update我们也可以尝试使用乐观锁来解决Race Condition的问题。
乐观锁的意思就是我们不假设其他进程会修改数据所以不加锁而是到需要更新数据的时候再使用数据库自身的UPDATE操作来更新数据库。因为UPDATE语句本身是原子操作所以也可以用来防御并发问题。
我们新增一个WithdrawView4class WithdrawView4(BaseWithdrawView):success_url reverse_lazy(ucenter:withdraw4)transaction.atomicdef form_valid(self, form):amount form.cleaned_data[amount]rows models.User.objects.filter(pkself.request.user, money__gteamount).update(moneyF(money)-amount)if rows 0:models.WithdrawLog.objects.create(userself.request.user, amountamount)return redirect(self.get_success_url()) 使用Yakit进行测试只有一次302返回
乐观锁的优点就是不会锁住数据库记录也就不会影响其他线程查询该用户。
总结
悲观锁 和 乐观锁 是两种常见的并发控制机制用于解决多个事务同时访问和修改同一数据时可能引发的冲突问题。它们的核心区别在于对并发冲突的处理方式。
