在這個軟件安(ān)全系列的第3部分(fēn)中(zhōng)，我們提到了軟件環境中(zhōng)有(yǒu)關安(ān)全的幾個關鍵要素。設計正确的流程來保證您的網絡安(ān)全是很(hěn)重要的。最後一個部分(fēn)要讨論的是主入口。由于客戶可(kě)直接訪問主入口——即應用(yòng)本身，因此主入口有(yǒu)時候是最薄弱的環節。

在這篇文(wén)章中(zhōng)，我們依舊先從宏觀的角度切入，再逐漸深入探讨細節問題。首先我們會了解一下基礎配置，接着探讨如何對輸入數據進行殺毒、檢查，最後我們會回顧一下優秀的成功案例，學(xué)習如何為(wèi)您客戶的賬戶提供安(ān)全保障。

SSL與安(ān)全

如今，SSL應該是web應用(yòng)的默認方案了。憑借SSL證書，您可(kě)以對浏覽器和基礎設施之間的數據進行加密，這樣數據在互聯網上流動時就不會被想要監控流量的人讀取。新(xīn)的浏覽器甚至會在您浏覽未經SSL加密的網站時發出警告。證書的獲取也比以往要容易得多(duō)，而且完全免費，隻需要使用(yòng)諸如Let’s Encrypt的網站即可(kě)。或者，若您使用(yòng)的是AWS，您可(kě)以通過他(tā)們的證書管理(lǐ)器在幾秒(miǎo)内獲得SSL證書，同樣不需要支付任何費用(yòng)。

不過有(yǒu)一個方面您可(kě)能(néng)沒有(yǒu)考慮過，那就是後端系統之間的數據傳輸安(ān)全。若您配備了相互通信的API，那麽最好将這部分(fēn)數據也一并加密。這樣即使應用(yòng)是在内部網絡實現的，若有(yǒu)人想要訪問網絡，那他(tā)就必須投入更多(duō)的精(jīng)力讀取數據。這一點同樣适用(yòng)于數據庫——内部API應該通過SSL與數據庫通信。

阻止跨站點腳本攻擊

當有(yǒu)人成功在應用(yòng)中(zhōng)注入代碼，然後該應用(yòng)又(yòu)運行了這段代碼時，就會發生跨站點腳本攻擊。發生跨站點腳本攻擊時，攻擊者會獲得對代碼的完全掌控，并可(kě)以實施某些惡意行為(wèi)。因此在接收用(yòng)戶輸入時，務(wù)必要對其進行“消毒”。消毒是接收輸入，确保輸入的數據不會在應用(yòng)程序中(zhōng)形成漏洞的一個過程，通常意味着某些字符會被跳過。

eBay是一個最好的例子。過去，eBay允許腳本在其網站上運行，目的是為(wèi)賣家提供一種獨一無二的使用(yòng)體(tǐ)驗——但代價是他(tā)們的客戶被迫暴露在風險之中(zhōng)。最終，eBay在衆人的呼聲中(zhōng)做出了正确的選擇，移除了這項特性。

阻止SQL注入攻擊

和跨站點腳本攻擊類似，SQL注入攻擊發生在通過惡意輸入獲取數據庫訪問權限的時候。在數據庫中(zhōng)運行SQL語句時，有(yǒu)時會獲取用(yòng)戶數據（譬如進行搜索時）。而掌握了SQL的攻擊者可(kě)以通過在文(wén)本和其他(tā)字段中(zhōng)輸入SQL命令将系統和數據暴露出來。這些命令可(kě)以返回敏感的用(yòng)戶數據，或者像這幅著名(míng)的XKCD漫畫一樣，删除某些表格。經驗告訴我們，不要相信用(yòng)戶。

加密數據

顯而易見，敏感數據應該加密。也就是說，不要直接将數據原樣存儲在磁盤上，而要先将數據轉換成人類無法理(lǐ)解的形式後在儲存。如果需要将數據重新(xīn)轉換成人類可(kě)以理(lǐ)解的形式，則需要使用(yòng)密鑰。這樣，若有(yǒu)人在沒有(yǒu)密鑰的情況下想要訪問數據，隻能(néng)夠獲得一堆垃圾。無論是在哪裏儲存數據（數據庫或設備文(wén)件中(zhōng)），都應該對數據進行加密。

不發送多(duō)餘的數據

下面這個安(ān)全漏洞常常被人忽視：返回數據時，應該問問自己：“應該發送這部分(fēn)數據嗎？”例如，若您的API獲取了一整個用(yòng)戶模型，那麽返回這個模型有(yǒu)大概率會是一個馊主意，因為(wèi)這個模型可(kě)能(néng)包含了身份信息和敏感信息，而這一點是可(kě)以避免的。每一個API都應該限制返回數據的範圍，即隻返回關聯性最強的數據塊，因為(wèi)一旦向浏覽器發送了數據，這部分(fēn)數據就基本相當于暴露了。

雙因子認證提升安(ān)全性

在回顧一些成功案例後，我們會探讨還有(yǒu)哪些措施可(kě)以保證用(yòng)戶數據的安(ān)全。雙因子認證或多(duō)因子認證（MFA）是保護用(yòng)戶賬戶安(ān)全的常見做法之一。這項技(jì )術會在用(yòng)戶輸入密碼後要求用(yòng)戶證明自己的身份。如果您有(yǒu)使用(yòng)網上銀行應用(yòng)程序的經驗，那麽您大概率已經遇到過這個機制了。用(yòng)戶登錄後，這項技(jì )術會向用(yòng)戶請求建立一條通道來獲取一個驗證碼——例如：輸入文(wén)本，或者更理(lǐ)想的是使用(yòng)像Authy這樣的安(ān)全應用(yòng)程序。有(yǒu)了這些工(gōng)具(jù)後，用(yòng)戶在登錄時就會被要求提供一個一次性的驗證碼。這樣即便用(yòng)戶的密碼洩露，賬戶也不會被他(tā)人非法訪問。

在和登錄賬戶有(yǒu)關的問題上，邏輯分(fēn)析是一個很(hěn)好的辦(bàn)法。用(yòng)戶是否在最近2秒(miǎo)内登錄失敗了15次？這些請求來源的IP地址是否和其常規位置相去甚遠(yuǎn)？這些迹象都可(kě)能(néng)表明進行登錄操作(zuò)的不是實際用(yòng)戶本人。提示用(yòng)戶進行登錄驗證，或者在登錄發生時告知用(yòng)戶，都是保護用(yòng)戶賬戶安(ān)全的好辦(bàn)法。

給密碼加鹽

保護用(yòng)戶信息的另一種标準做法是在密碼中(zhōng)增加一個随機生成的字符串（又(yòu)叫“鹽值”），然後再進行加密。采取這種做法後，即使用(yòng)戶在您的應用(yòng)程序和其他(tā)應用(yòng)程序上都使用(yòng)相同的密碼（順便說一下，這種習慣很(hěn)不好），您的應用(yòng)程序也可(kě)保證儲存的信息的唯一性。

那麽，為(wèi)什麽這一點很(hěn)重要呢(ne)？不妨考慮一下這種情形：您的密碼在某個網站被洩露了。此時，若其他(tā)網站都引入了鹽值，那麽這個密碼就沒辦(bàn)法被用(yòng)于非法用(yòng)途。實際上，對于加了鹽的密碼而言，即使您輸入的是和以前相同的密碼，這個密碼也不再是原來的密碼了。

小(xiǎo)心第三方庫

在今天的環境中(zhōng)很(hěn)難再找到一款沒有(yǒu)使用(yòng)第三方庫的應用(yòng)，任何用(yòng)戶都可(kě)以輕松使用(yòng)開源庫中(zhōng)的代碼，而這些代碼是允許所有(yǒu)人自由查看的。因此，最好的辦(bàn)法是在使用(yòng)這些代碼以前檢查這些庫是否存在安(ān)全漏洞。一個年代久遠(yuǎn)又(yòu)缺乏維護的庫有(yǒu)大概率是不安(ān)全的。

關于安(ān)全最後的一些想法

應用(yòng)程序是業務(wù)的組成部分(fēn)，在某些情況下甚至是最關鍵的部分(fēn)。應用(yòng)程序是客戶與您互動的橋梁，也是您與同行拉開差距的手段，但在面對攻擊者和用(yòng)戶本身時也是最薄弱的一環。遵循數據加密的标準做法，為(wèi)用(yòng)戶提供數據保護的選項，就是在為(wèi)您的業務(wù)争取最大的機遇。

最後，安(ān)全是團隊合作(zuò)的産(chǎn)物(wù)，任何人都不可(kě)能(néng)僅憑一己之力為(wèi)您的企業和客戶提供安(ān)全保障，安(ān)全是公(gōng)司從上到下每一個人的日常。您要在自己的企業内建立起這種習慣和氛圍。