今天下午在v2ex上看到一个帖子，讲述自己因为忘记加分布式锁导致了公司的损失：
我曾在《从Pwnhub诞生聊Django安全编码》一文中描述过关于商城逻辑所涉及的安全问题，其中就包含并发漏洞（Race Condition）的防御，但当时说的比较简洁，也没有演示实际的攻 击过程与危害。今天就以v2ex上这个帖子的场景来讲讲，常见的存在漏洞的Django代码，与我们如何正确防御竞争漏洞的方法。
首先，使用我这个Django-Cookiecutter脚手架创建一个项目，项目名是Race Condition Playground。
创建两个新的Model：
class User(AbstractUser):
username = models.CharField('username', max_length=256)
email = models.EmailField('email', blank=True, unique=True)
money = models.IntegerField('money', default=0)
USERNAME_FIELD = 'email'
REQUIRED_FIELDS = ['username']
class Meta(AbstractUser.Meta):
swappable = 'AUTH_USER_MODEL'
verbose_name = 'user'
verbose_name_plural = verbose_name
def __str__(self):
return self.username
class WithdrawLog(models.Model):
user = models.ForeignKey('User', verbose_name='user', on_delete=models.SET_NULL, null=True)
amount = models.IntegerField('amount')
created_time = models.DateTimeField('created time', auto_now_add=True)
last_modify_time = models.DateTimeField('last modify time', auto_now=True)
class Meta:
verbose_name = 'withdraw log'
verbose_name_plural = 'withdraw logs'
def __str__(self):
return str(self.created_time)
一个是User表，用以储存用户，其中money字段是这 个用户的余额；一个是WithdrawLog表，用以储存提取的日志。我们假设公司财务会根据这个日志表来向用户打款，那么只要成功在这个表中插入记录，则说 明攻击成功。
然后，我们编写一个WithdrawForm，其字段amount，表示用户此时想提取的余额，必须是整数：
class WithdrawForm(forms.Form):
amount = forms.IntegerField(min_value=1)
def __init__(self, *args, **kwargs):
self.user = kwargs.pop('user', None)
super().__init__(*args, **kwargs)
def clean_amount(self):
amount = self.cleaned_data['amount']
if amount > self.user.money:
raise forms.ValidationError('insufficient user balance')
return amount
我将检查用户余额的逻辑放在WithdrawForm.clean_amount
中，如果发现用户要提取的金额大于用户的余额，则抛出一个forms.ValidationError
异常。
最后我们编写一个用于提现的View：
class BaseWithdrawView(LoginRequiredMixin, generic.FormView):
template_name = 'form.html'
form_class = forms.WithdrawForm
def get_form_kwargs(self):
kwargs = super().get_form_kwargs()
kwargs['user'] = self.request.user
return kwargs
class WithdrawView1(BaseWithdrawView):
success_url = reverse_lazy('ucenter:withdraw1')
def form_valid(self, form):
amount = form.cleaned_data['amount']
self.request.user.money -= amount
self.request.user.save()
models.WithdrawLog.objects.create(user=self.request.user, amount=amount)
return redirect(self.get_success_url())
这个WithdrawView1
非常简单，因为使用了django的generic.FormView
，所以Django在接收到POST请求后会正常使用form的方法进行检查（包含上面提到的余额充足的检查），检查通过后执行form_valid()
函数完成提现操作 ：
对request.user.money
进行自减
在WithdrawLog
中添加一条新记录
最后再添加一些必要的前端、路由、Admin等即可完工。
跑起来Web应用，访问后台，给自己的账户设置余额为10：
然后来到前台，输入Amount即可进行提现。我们尝试输入100 提交，此时会因为余额不足而报错：
运行正常，我们可以开始进行实验。
观察我前 面写的WithdrawView1
，可以发现整个操作即没有使用事务，也没有加锁，理论上是存在Race Condition漏洞的。
Race Condition的原理很简单，下图 是用户提现时的流程：
在经过amount <= user.money
检查后，服务端执行提现操作，本无可厚非。但如果某个用户同时发起两次提现请求， 在第一个请求经过检查到达Withdraw handler之前，此时该用户的user.money
是还没有减少的；此时第二个请求如果也经过了检查，两个请求同时到达Withdraw handler，就会导致user.money -= amount
执行两次。
那么如果用户的余额只够提取一次，这里执行了两次，就实现了竞争攻击，造成了资产损失的结果。
测试方法也很简单，我们下载Yakit，新建一个Web Fuzzer，贴入提现的数据包。这里，我账户余额是10，我设置的提现金额amount也为10。正 常情况下，我只能提现一次，第二次就会因为余额不足而失败。
然后我在数据包中添加{{repeat(100)}}
，并把并发线程调高到100发送，此时Yakit就 会使用100个线程重复发送100次这个数据包：
见上图，发送结果里，前4个请求返回了302跳转，说明提现成功。我们来到后台Withdraw Log 页面，有4个提现日志：
这意味着，我余额虽然只有10，但我成功提现了4次，也就是40元，造成的资产损失为30元。
很多Django初学者会认为，这种情况只要我们加上事务就可以解决了。
原因也比较有趣，Django里增加事务的操作名字叫transaction.atomic
，atomaic嘛就是“原子”的意思，原子操作不是可以解决并发问题吗？
我们也可以来做试验，新编写一个WithdrawView2
，加上@transaction.atomic
修饰符：
class WithdrawView2(BaseWithdrawView):
success_url = reverse_lazy('ucenter:withdraw2')
@transaction.atomic
def form_valid(self, form):
amount = form.cleaned_data['amount']
self.request.user.money -= amount
self.request.user.save()
models.WithdrawLog.objects.create(user=self.request.user, amount=amount)
return redirect(self.get_success_url())
同样使用Yakit做测试，结果和刚才并无区别：
后台也是4条提现记录：
这也可以说明，transaction.atomic
并无处理并发的能力，只是保证当前上下文中的数据库操作在出错的时候能够回滚。
Django在ORM里提供了对数据库Select for Update的支持，在PostgreSQL、Mysql、Oracle三个数据库中都可以使用，结合Where语句，可以实现行级的锁。
使用SELECT FOR UPDATE
获取到的数据库记录，不会再被其他事务获取。比如，我查询id = 1
的用户，在提交事务前，其他事务执行同一个SQL语句就会block：
START transation;
SELECT * FROM user WHERE id = 1 FOR UPDATE;
COMMIT;
这样就可以保证我们在同一个事务内执行的操作的原子性，这是一个典型的悲观锁。“悲观锁”的意思是，我们先假设其他线程会修改数据 ，所以在操作数据库前就加锁，直到当前线程释放锁后，其他线程才能再次获取这个锁。
我们使用select_for_update()
来实现一个WithdrawView3
：
class WithdrawView3(BaseWithdrawView):
success_url = reverse_lazy('ucenter:withdraw3')
def get_form_kwargs(self):
kwargs = super().get_form_kwargs()
kwargs['user'] = self.user
return kwargs
@transaction.atomic
def dispatch(self, request, *args, **kwargs):
self.user = get_object_or_404(models.User.objects.select_for_update().all(), pk=self.request.user.pk)
return super().dispatch(request, *args, **kwargs)
def form_valid(self, form):
amount = form.cleaned_data['amount']
self.user.money -= amount
self.user.save()
models.WithdrawLog.objects.create(user=self.user, amount=amount)
return redirect(self.get_success_url())
对于当前这个场景，我们可以再 次尝试使用Yakit进行竞争攻击：
可见，此时返回包只有一个302响应了，再查看后台也只成功添加一条提现记录：
这意味着程序是 按照预期运行，没有发生Race Condition问题。
我们观察上述的WithdrawView3
代码，其实会发现一个问题，如果有大量读操作的场景下，使用悲观锁会有性能问题。因为每次访问这个view都会锁住当前用户对象，此时其他要使用 这个用户的场景（如查看用户主页）也会卡住。
另外，也不是所有数据库都支持select for update
，我们也可以尝试使用乐观锁来解决Race Condition的问题。
乐观锁的意思就是，我们不假设其他进程会修改数据，所以不加锁，而是到需要更新数据的时候，再使用数据库自身的UPDATE操作来更新 数据库。因为UPDATE语句本身是原子操作，所以也可以用来防御并发问题。
我们新增一个WithdrawView4
：
class WithdrawView4(BaseWithdrawView):
success_url = reverse_lazy('ucenter:withdraw4')
@transaction.atomic
def form_valid(self, form):
amount = form.cleaned_data['amount']
rows = models.User.objects.filter(pk=self.request.user, money__gte=amount).update(money=F('money')-amount)
if rows > 0:
models.WithdrawLog.objects.create(user=self.request.user, amount=amount)
return redirect(self.get_success_url())
代码基本是从WithdrawView2
来的，只是将其中的self.request.user.money -= amount
改成了用update，并且在修改数据行数大于0的情况下再添加提现日志。
此时，假设有多个提现请求同时到达update语句，因为update本身的原子性，执 行第一次update后，用户的余额已经减少amount，再执行第二次update时，money__gte=amount
这个条件就不会成功，就不会再次减少amount了。
使用Yakit进行测试，只有一次302返回：
查看后台，也只成功添加一个提现日志，符合预期：
乐观锁的优点就是不会锁住数据库记录，也就不会影响其他线程查询该用户。
本文主要从v2ex一个帖子的例子入手，阐述了如何使用Yakit进行Race Condition攻击，以及 在Django中如何使用悲观锁和乐观锁对该攻击进行防御。
本文涉及的代码，可以在https://github.com/phith0n/race-condition-playground找到。