从 WTForm 的 URLXSS 谈开源组件的安全性

0x00 开源组件与开源运用

开源组件是咱们咱们平常开发的时分必不行少的东西，所谓『不要重复造轮子』的原因也是因为，许多封装好的组件咱们在开发中能够直接调用，减少了重复开发的工作量。

开源组件和开源程序也有一些差异，开源组件面向的运用者是开发者，而开源程序就能够直接面向用户。开源组件，如JavaScript里的uploadify，php里的PHPExcel等；开源程序，如php写的wordpress、joomla，node.js写的ghost等。

就安全而言，毋庸置疑，开源组件的缝隙影响面远比开源软件要大。但许多开源组件的缝隙却很少呈现在咱们眼中，我总结了几条原因：

开源程序的缝隙具有通用性，许多能够经过一个通用的poc来测验全网，更具『商业价值』；而开源组件因为开发者运用办法不同，导致测验办法不一致，运用门槛也相对较高群众更了解开源软件，如wordpress，而很少有人知道wordpress内部运用了哪些开源组件。相应的，当呈现缝隙的时分人们也只会以为这个缝隙是wordpress的缝隙。惯性思想让人们以为：『库』里应该不会有缝隙，在代码审计的时分也很少会重视import进来的第三方库的代码缺点。所以，开源组件爆出的缝隙也较少。能够开发开源组件的开发者本身本质相对较高，代码质量较高，也使开源组件出缝隙的可能性较小。组件缝隙八成有争议性，许多锅分不清是组件本身的仍是其运用者的，许多问题咱们也只能称其为『特性』，但实际上这些特性反而比某些缝隙更可怕。

特别是现在国内浮躁的安全气氛，能够显着感遭到第一条原因。就前段时间呈现的几个影响较大的缝隙：Java反序列化缝隙、joomla的代码履行、redis的写ssh key，能够显着感觉到后两者炒的比前者要响，而前者不愠不火的，曝光了近一年才遭到广泛重视。

Java反序列化缝隙，刚好便是典型的『组件』特性形成的问题。早在2019年的1月28号，就有白帽子报告了运用Apache Commons Collections这个常用的Java库来完成恣意代码履行的办法，但并没有太多重视（本来国外也是这样）。直到11月有人提出了用这个办法进犯WebLogic、WebSphere、JBoss、Jenkins、OpenNMS等运用的时分，才被忽然炒起来。

这种比照显着反应出『开源组件』和『开源运用』在安全缝隙重视度上的距离。

我个人在乌云上发过几个组件缝隙，从前年发的ThinkPHP结构注入，到后边的Tornado文件读取，到slimphp的XXE，根本都是我自己在运用完这些组件后，对全体代码做code review的时分发现的。

这篇文章以一个比方，简略地谈谈怎么对第三方库进行code review，与怎么正确运用第三方库。

0x01 WTForm中的弱validator

WTForms是python web开发中重要的一个组件，它供给了简略的表单生成、验证、转化等功用，是很多python web结构（特别是flask）不行短少的辅佐库之一。

WTForms中有一个重要的功用便是对用户输入进行查看，在文档中被称为validator：

http://wtforms.readthedocs.org/en/latest/validators.html

A validator simply takes an input, verifies it fulfills some criterion, such as a maximum length for a string and returns. Or, if the validation fails, raises a ValidationError. This system is very simple and flexible, and allows you to chain any number of validators on fields.

咱们能够简略地运用其内置validator对数据进行查看，比方咱们需求用户输入一个『不为空』、『最短10个字符』、『最长64个字符』的『URL地址』，那么咱们就能够编写如下class:

#!py
class MyForm(Form):
    url = StringField("Link", validators=[DataRequired(), Length(min=10, max=64), URL()])

以flask为例，在view视图中只需调用validate()函数即可查看用户的输入是否合法：

#!py
@app.route('/', methods=['POST'])
def check():
    form = MyForm(flask.request.form)
    if form.validate():
        pass # right input
    else:
        pass # bad input

典型的灵敏开发手法，减少了许多开发工作量。

但我自己在做code review的过程中发现，WTForms的内置validators并不行信，与其说是不行信，不如说在安全性上部分validator完全不起任何效果。

就拿上诉代码为比方，这段代码真的能够查看用户输入的数据是否是一个『URL』么？咱们看到wtforms.validators.URL()类：

#!py
class URL(Regexp):
    def __init__(self, require_tld=True, message=None):
        regex = r'^[a-z]+://(?P<host>[^/:]+)(?P<port>:[0-9]+)?(?P<path>/.*)?$'
        super(URL, self).__init__(regex, re.IGNORECASE, message)
        self.validate_hostname = HostnameValidation(
            require_tld=require_tld,
            allow_ip=True,
        )

    def __call__(self, form, field):
        message = self.message
        if message is None:
            message = field.gettext('Invalid URL.')

        match = super(URL, self).__call__(form, field, message)
        if not self.validate_hostname(match.group('host')):
            raise ValidationError(message)

其承继了Rexexp类，实际上便是对用户输入进行正则匹配。咱们看到它的正则：

regex = r'^[a-z]+://(?P<host>[^/:]+)(?P<port>:[0-9]+)?(?P<path>/.*)?$'

可见，这个正则与开发者了解的URL严峻的不匹配。大部分的开发者期望取得的URL是一个『HTTP网址』，但这个正则匹配到的却广泛的太多了，最大特色便是其可匹配恣意protocol。最简单想到的一个进犯方式便是运用Javascript协议触发的XSS，比方我传入的url是

javascript://...xss

[1] [2] [3] 黑客接单网

发表于 2021-04-17 13:18
阅读 ( 333 )
分类：互联网