做 Web 開(kāi)發必備的安全核對清單

    做 Web 開(kāi)發必備的安全核對清單。如果能按照本文的這個清單來實踐，就能将網絡安全方面的風險降得很低。

    Web開(kāi)發人員(yuán)安全清單

    在雲端開(kāi)發安全又(yòu)健壯的 Web 應用非常難。如果你認爲這很容易，那你技術水平要麽已經很牛叉，要麽還沒有踩過坑。
    \

    如果你盲目接受 最簡可行産品 (Minimum Viable Product，簡稱 MVP)，并且認爲你能在一(yī)個月之内創建一(yī)個既有價值又(yòu)安全的産品，那麽在你推出你的“産品原型”前，你還需要多想想。在你查看了下(xià)面的清單之後，确認你不會犯這些嚴重的安全問題。至少，你要對你的潛在用戶坦誠，讓他們知(zhī)道你還沒有一(yī)個完整的産品，并且隻提供一(yī)個沒有全面安全的原型。

    這個清單很簡單，并且也不是那種大(dà)而全的。我(wǒ)已經開(kāi)發安全的 Web 應用有 14 年多了。這個清單包含了一(yī)些相對重要的問題。這些問題都是我(wǒ)在這段時間學到的，而這個過程也是痛苦的。當你在創建 Web 應用時，我(wǒ)希望你能夠認真地對待這些問題。

    如果在這個清單中(zhōng)，你有我(wǒ)沒有提到的項目，請留言補充。

    數據庫

    [ ] 可以識别用戶的數據和敏感數據(如訪問令牌、電(diàn)子郵件地址或賬單信息)需要加密。

    [ ] 如果你的數據庫在休息狀态時支持低成本加密(如 AWS Aurora )，那麽啓動該功能來保護硬盤上的數據。同時也要确保所有備份都是被加密存儲的。

    [ ] 給用戶最低訪問權限的賬戶。不要使用數據庫的 root 賬戶。

    [ ] 刻意設計一(yī)個密鑰庫，用它存儲和分(fēn)發機密内容。不要硬編碼到你的應用中(zhōng)。

    [ ] 通過隻使用 SQL 預處理語句(prepared statements)的方法來完全防止 SQL 注入。比如：如果要使用 NPM，不要使用 npm-mysql，而是使用 npm-mysql2，因爲它支持預處理語句。

    開(kāi)發

    [ ] 對于每個發布的版本，确保軟件的所有組件都通過了漏洞掃描。組件指的是操作系統、庫和包。這應該自動地進入持續集成/持續交付流程。

    [ ] 保證開(kāi)發系統的安全。同樣的，對于你使用的産品系統，也需要保持相同的警惕。在安全、隔離(lí)的開(kāi)發系統中(zhōng)開(kāi)發軟件。

    認證

    [ ] 确保所有密碼都經過合适的加密方法(如 bcrypt )的散列處理。永遠不要自己實現加密方法，并且用好的随機數據來正确地初始化加密方法。

    [ ] 在實現登錄、忘記密碼、密碼重置等功能時，用經過驗證過的最佳實現或組件。不要重複造輪子，因爲你很難保證其在所有場景中(zhōng)都不會出現問題。

    [ ]遵循簡單且合适的密碼規則，鼓勵用戶使用較長的随機密碼。

    [ ] 你們提供的所有服務，用多重認證來驗證登錄。

    拒絕服務防護

    [ ]确保網站不會因 API 遭拒絕服務攻擊(DOS)而癱瘓。至少，在相對較慢(màn)的 API 路徑上(像登錄和 Token 生(shēng)成程序)設置頻(pín)率限制器。

    [ ] 對用戶所提交的數據和請求，在大(dà)小(xiǎo)以及結構這兩點上執行合理的限制。

    [ ] 通過使用全局緩存代理服務(類似 CloudFlare )來規避分(fēn)布式拒絕服務(DDOS)。如果網站遭到 DDOS 攻擊，你就能打開(kāi)這個服務和其他類似的，以作 DNS 查詢。

    網絡流量

    [ ] 整個網站都使用 TLS，不僅僅是登錄表單和響應。 永遠不要隻在登錄表單中(zhōng)使用 TLS。

    [ ] Cookie 必須設置 httpOnly、安全、被路徑和域限定。

    [ ] 使用内容策略安全( CSP )，并且不允許 unsafe-*(*是通配符)後門。雖然配置時很痛苦，但這是值得做的。

    [ ] 在客戶端的響應頭中(zhōng)使用 X-Frame-Option、X-XSS-Protection。

    [ ] 使用 HSTS 響應強制僅限 TLS 訪問。在服務器上重定向所有 HTTP 請求到 HTTPS，作爲替代方案。

    [ ] 在所有的表單中(zhōng)使用 CSRF 令牌(Token)。使用新的 SameSite Cookie 響應頭，這徹底解決了所有較新浏覽器上的 CSRF 問題。

    API

    [ ] 确保公開(kāi) API 中(zhōng)沒有可枚舉的資(zī)源。

    [ ] 确保用戶經過全面的認證，并且擁有适當權限的用戶才能訪問 API。

    [ ] 在 API 中(zhōng)使用随機檢查，以檢測潛在攻擊的非法或異常請求。

    驗證

    [ ] 爲了給用戶快速的反饋，可以在客戶端做輸入合法性驗證，但是永遠不要相信用戶的輸入數據。

    [ ] 在服務器端使用白(bái)名單，來驗證所有用戶的輸入。永遠不要直接将用戶的内容添加到響應中(zhōng)。永遠不要在 SQL 語句中(zhōng)使用用戶輸入的内容。

    雲配置

    [ ] 确保所有的服務打開(kāi)盡可能少的端口。當隐晦式安全(security through obscurity)沒有保護的效果時, 将默認的端口替換成非标準的端口，這樣可以讓攻擊者更難攻破。

    [ ] 将後端數據庫和服務托管到私有 VPC 上 (虛拟私有雲)，而 VPC 不能被任何公共網絡訪問。當你在配置 AWS 安全組和對等 VPC 時，你需要非常仔細，因爲這可能導緻服務無意中(zhōng)對外(wài)部開(kāi)放(fàng)。

    [ ] 在隔離(lí) VPC 和對等 VPC 裏隔離(lí)邏輯服務，以便支持跨服通信。

    [ ] 确保所有服務接收的數據，來自于一(yī)個盡可能小(xiǎo)範圍内的 IP 地址。

    [ ] 限制出站 IP 和端口流量，最大(dà)限度地減少 APT 攻擊帶來的損失和“通訊”。

    [ ] 始終使用 AWS 訪問管理(IAM)這個身份，而不是 root 憑據。

    [ ] 授予所有操作和開(kāi)發人員(yuán)最小(xiǎo)的訪問權限。

    [ ] 根據時間表定期地更換密碼和訪問密鑰。

    基礎設施

    [ ] 确保你能在不停機的情況下(xià)升級。确保你能通過完全自動的方式快速升級。

    [ ] 使用像 Terraform 這樣的工(gōng)具創建所有的基礎架構，而不是通過雲端控制台。基礎架構應該被定義爲“代碼”，并且能夠按下(xià)按鈕來重建。對于任何在雲端手動創建的資(zī)源采取零容忍态度，之後 Terraform 就能審計你的配置了。

    [ ] 所有服務都使用集中(zhōng)式日志(zhì)架構。你永遠都不應該需要 SSH 來訪問或者檢索日志(zhì)。

    [ ] 除了一(yī)次性診斷，不要通過 SSH 連接到你的服務。通常使用 SSH 意味着你沒有自動執行重要任務。

    [ ] 永遠不要在任何 AWS 服務組上保持 22 号端口爲打開(kāi)的狀态。

    [ ] 創建 不變的主機 ，而不是不斷地給你長壽的服務器打補丁和升級。(參見 Immutable Infrastructure Can Be More Secure ).

    [ ] 使用 入侵檢測系統 來最大(dà)化減少 APT 攻擊帶來的影響。

    運營

    [ ] 關閉未使用的服務和服務器。斷電(diàn)的服務器是最安全的。

    測試

    [ ] 審計你的設計和實施。

    [ ] 做滲透測試。除了你之外(wài)，還可以叫其他人進行滲透測試。

    培訓

    就關于社會工(gōng)程領域中(zhōng)的潛在威脅和相關防護技術，要對員(yuán)工(gōng)(特别是高級員(yuán)工(gōng))進行培訓。

    最後，制定一(yī)個計劃

    [ ] 做一(yī)個威脅模型，描述你正在防禦對象。按主次列出可能的威脅和參與者。

    [ ] 制定一(yī)份可實操的安全事故計劃。總有一(yī)天你會需要的。