ah!其实没有标题说的那么严重!
不过下面可是我们开发产品初期的一些血淋淋的案例,更多的安全威胁可以看看北北同学的《python hack》PPT,里面提及了不只命令执行的威胁,那些都是我们亲身经历的代码。
千万要记得执行命令的时候,不要信任其他传入数据就行了,既然意识到问题,那么修复方法是多种多样的。
在我们的系统中,多处出现问题然后修修补补是不靠谱的,那么我们需要一个通用的安全执行接口,这个接口过后更新进来。
此外,我们在开发新功能的时候,也要掌握安全编程的规范技巧,这些技巧不局限在命令执行安全。
总结了一下,就是一下几点要素啦:
•命令执行的字符串不要去拼接输入的参数,非要拼接的话,要对输入参数进行白名单过滤
•对传入的参数一定要做类型校验,例如知道是数字型的,就int测试一下,会安全许多
•对于拼接串,也要严格一些,例如int类型参数的拼接,对于参数要用%d,不要%s。
•使用subprocess来传入多个参数,就可以防止命令行注入
拿我们曾经的代码(当时是最新版=,=时过境迁了)存在的bug来做教程:
示例1(变量没过滤):
a.py
site变量其实是个url格式的串,未经过滤。由于老版本中site格式没有出现问题,新版本支持url格式,就可以传入各种符号了。
示例2(不牢靠的过滤):
util/update.py
downloadFile函数尽管对fileName使用了过滤,但绕过的方法很多。
linux下面的命令分隔方法非常多,黑名单法是不牢靠的。
修复的方法就是对fileName进行白名单格式检查,比如,只允许出现字符数字以及.。
示例3(不安全的格式化字符串):
b.py
target是个url格式的串,未经过滤。并且还有潜在威胁,deep使用了%s,其实它必须是个int,使用%d才对,假如以后有机会感染deep变量,那就xxoo了。
示例4(无法利用的命令注入):
c.py
site_report函数,tid参数未经格式化,目前无法利用是因为有一个查询数据库的语句:
get_object_or_404(Task, get_domain_query(request), id=tid)#这里会让带了特殊符号的tid查不到记录,所以变为404,暂时保护了位于下文的cmd拼接。
一旦该语句变更,就会导致新的命令注入漏洞
cmd = 'sh /opt/report %s >/tmp/export_report.log 2>&1' % tid