[譯] Web 開發者安全清單

• 原文地址：Web Developer Security Checklist
• 原文做者：Michael O'Brien
• 譯文出自：掘金翻譯計劃
• 譯者： GangsterHyj
• 校對者： zaraguo, yzgyyang

Web 開發者安全清單

開發安全、健壯的雲端 web 應用程序是很是困難的事情。若是你認爲這很容易，要麼你過着更高級的生活，要麼你還正走向痛苦覺醒的路上。

假若你已經接受 MVP（最簡可行產品） 的開發理念，而且相信能在一個月內創造既有價值又安全的產品 —— 在發佈你的「原型產品」以前請再三考慮。在你檢查下面列出的安全清單後，意識到你在開發過程當中忽視了不少極其重要的安全問題。至少要對你潛在的用戶坦誠，讓他們知道你並無真正完成產品，而僅僅只是提供沒有充分考慮安全問題的原型。

這份安全清單很簡單，絕非覆蓋全部方面。它列出了在建立 web 應用時須要考慮的比較重要的安全問題。

若是下面的清單遺漏了你認爲很重要的問題，請發表評論。

數據庫

• 對識別用戶身份的數據和諸如訪問令牌、電子郵箱地址或帳單明細等敏感數據進行加密。
• 若是數據庫支持在空閒狀態進行低消耗的數據加密 (如 AWS Aurora)，那麼請激活此功能以增強磁盤數據安全。確保全部的備份文件也都被加密存儲。
• 對訪問數據庫的用戶賬號使用最小權限原則，禁止使用數據庫 root 賬號。
• 使用精心設計的密鑰庫存儲和分發密鑰，不要對應用中使用的密鑰進行硬編碼。
• 僅使用 SQL 預備語句以完全阻止 SQL 注入。例如，若是使用 NPM 開發應用，鏈接數據庫時不使用 npm-mysql ，而是使用支持預備語句的 npm-mysql2 。

開發

• 確保已經檢查過軟件投入生存環境使用的每一個版本中全部組件的漏洞，包括操做系統、庫和軟件包。此操做應該以自動化的方式加入 CI/CD（持續集成/持續部署） 過程。
• 對開發環境系統的安全問題保持與生產環境一樣的警戒，從安全、獨立的開發環境系統構建軟件。

認證

• 確保全部的密碼都使用例如 bcrypt 之類的合適的加密算法進行哈希。絕對不要使用本身寫的加密算法，並正確地使用隨機數初始化加密算法。
• 使用簡單但充分的密碼規則以激勵用戶設置長的隨機密碼。
• 使用多因素身份驗證方式實現對服務提供商的登陸操做。

拒絕服務防衛

• 確保對 API 進行 DOS 攻擊不會讓你的網站崩潰。至少增長速率限制到執行時間較長的 API 路徑（例如登陸、令牌生成等程序）。
• 對用戶提交的數據和請求在大小和結構上加強完整性限制。
• 使用相似 CloudFlare 的全局緩存代理服務應用以緩解 Distributed Denial of Service （DDOS，分佈式拒絕服務攻擊）對網站帶來的影響。它會在你遭受 DDOS 攻擊時被激活，而且還具備相似 DNS 查找等功能。

網絡交通

• 整個網站使用 TLS （安全傳輸層協議），不要僅對登陸表單使用 TLS。
• Cookies 必須添加 httpOnly 和 secure 屬性，且由屬性 path 和 domain 限定做用範圍。
• 使用 CSP（內容安全策略） 以禁止不安全的後門操做。策略的配置很繁瑣，可是值得。
• 使用 X-Frame-Option 和 X-XSS-Protection 響應頭。
• 使用 HSTS(HTTP Strict Transport Security) 響應強迫客戶端僅使用 TLS 訪問服務器，同時服務端須要將全部 HTTP 請求重定向爲 HTTPS。
• 在全部表單中使用 CSRF 令牌，使用新響應頭 SameSite Cookie 一次性解決 CSRF 問題， SameSite Cookie 適用於全部新版本的瀏覽器。

APIs

• 確保公有 API 中沒有可枚舉的資源。
• 確保每一個訪問 API 的用戶都能被恰當地認證和受權。

校驗

• 使用客戶端輸入校驗以及時給予用戶反饋，可是不能徹底信任客戶端校驗結果。
• 使用服務器的白名單校驗用戶輸入。不要直接向響應注入用戶信息，切勿在 SQL 語句裏使用用戶輸入。

雲端配置

• 確保全部服務開放最少的端口。儘管經過隱藏信息來保障安全是不可靠的，使用非標準端口將使黑客的攻擊操做更加困難。
• 在對任何公有網絡都不可見的私有 VPC 上部署後臺數據庫和服務。在配置 AWS 安全組和對等互聯多個 VPC 時務必謹慎（可能無心間使服務對外部可見）。
• 不一樣邏輯的服務部署在不一樣的 VPC 上，VPC 之間經過對等鏈接進行內部服務的訪問。
• 讓鏈接服務的 IP 地址個數儘量少。
• 限制對外輸出的 IP 和端口流量，以最小化 APT（高級持續性威脅）和「警告」。
• 始終使用 AWS 的 IAM（身份與訪問管理）角色，而不是使用 root 的認證信息。
• 對全部操做和開發人員使用最小訪問權限原則。
• 按照預約計劃按期輪換密碼和訪問密鑰。

基礎架構

• 確保在不停機的狀況下對基礎架構進行升級，確保以全自動的方式快速更新軟件。
• 利用 Terraform 等工具建立全部的基礎架構，而不是經過雲端命令行窗口。基礎架構應該代碼化，僅需一個按鈕的功夫便可重建。請不要手動在雲端建立資源，由於使用 Terraform 就能夠經過配置自動建立它們。
• 爲全部服務使用集中化的日誌記錄，不應再利用 SSH 訪問或檢索日誌。
• 除了一次性診斷服務故障之外，不要使用 SSH 登陸進服務。頻繁使用 SSH ，意味着你還沒將執行重要任務的操做自動化。
• 不要長期開聽任何 AWS 服務組的22號端口。
• 建立 immutable hosts（不可變主機） 而不是使用一個通過你長期提交補丁和更新的服務器。。（詳情請看博客 Immutable Infrastructure Can Be More Secure）。
• 使用如 SenseDeep 的 Intrusion Detection System（入侵檢測系統） 或服務，以最小化 APTs（高級持續性威脅） 。

操做

• 關閉未使用的服務和服務器，關閉的服務器是最安全的。

測試

• 審覈你的設計與實現。
• 進行滲透測試 — 攻擊本身的應用，讓其餘人爲你的應用編寫測試代碼。

最後，制定計劃

• 準備用於描述網絡攻擊防護的威脅模型，列出可能的威脅和網絡攻擊參與者，並按優先級對其排序。
• 制定經得起實踐考驗的安全事故計劃，總有一天你會用到它。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃。