从 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()类：
其承继了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] 黑客接单网
