ah！其實沒有標題說的那么嚴重！

不過下面可是我們開發(fā)產(chǎn)品初期的一些血淋淋的案例，更多的安全威脅可以看看北北同學的《python hack》PPT，里面提及了不只命令執(zhí)行的威脅，那些都是我們親身經(jīng)歷的代碼。

千萬要記得執(zhí)行命令的時候，不要信任其他傳入數(shù)據(jù)就行了，既然意識到問題，那么修復方法是多種多樣的。

在我們的系統(tǒng)中，多處出現(xiàn)問題然后修修補補是不靠譜的，那么我們需要一個通用的安全執(zhí)行接口，這個接口過后更新進來。

此外，我們在開發(fā)新功能的時候，也要掌握安全編程的規(guī)范技巧，這些技巧不局限在命令執(zhí)行安全。

總結了一下，就是一下幾點要素啦：

•命令執(zhí)行的字符串不要去拼接輸入的參數(shù)，非要拼接的話，要對輸入?yún)?shù)進行白名單過濾
•對傳入的參數(shù)一定要做類型校驗，例如知道是數(shù)字型的，就int測試一下，會安全許多
•對于拼接串，也要嚴格一些，例如int類型參數(shù)的拼接，對于參數(shù)要用%d，不要%s。
•使用subprocess來傳入多個參數(shù)，就可以防止命令行注入

拿我們曾經(jīng)的代碼（當時是最新版=，=時過境遷了）存在的bug來做教程：

示例1（變量沒過濾）：

a.py

site變量其實是個url格式的串，未經(jīng)過濾。由于老版本中site格式?jīng)]有出現(xiàn)問題，新版本支持url格式，就可以傳入各種符號了。

示例2（不牢靠的過濾）：

util/update.py

downloadFile函數(shù)盡管對fileName使用了過濾，但繞過的方法很多。

linux下面的命令分隔方法非常多，黑名單法是不牢靠的。

修復的方法就是對fileName進行白名單格式檢查，比如，只允許出現(xiàn)字符數(shù)字以及.。

示例3（不安全的格式化字符串）：

b.py

target是個url格式的串，未經(jīng)過濾。并且還有潛在威脅，deep使用了%s，其實它必須是個int，使用%d才對，假如以后有機會感染deep變量，那就xxoo了。

示例4（無法利用的命令注入）：

c.py

site_report函數(shù)，tid參數(shù)未經(jīng)格式化，目前無法利用是因為有一個查詢數(shù)據(jù)庫的語句：

get_object_or_404(Task, get_domain_query(request), id=tid)#這里會讓帶了特殊符號的tid查不到記錄，所以變?yōu)?04，暫時保護了位于下文的cmd拼接。

一旦該語句變更，就會導致新的命令注入漏洞

cmd = 'sh /opt/report %s >/tmp/export_report.log 2>&1' % tid

最新評論