不过下面可是我们开发产品初期的一些血淋淋的案例，更多的安全威胁可以看看北北同学的《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
下载本文