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