1. 程式人生 > >做 Web 開發必備的安全核對清單

做 Web 開發必備的安全核對清單

如果能按照本文的這個清單來實踐,就能將網路安全方面的風險降得很低。

Web開發人員安全清單

在雲端開發安全又健壯的 Web 應用非常難。如果你認為這很容易,那你技術水平要麼已經很牛叉,要麼還沒有踩過坑。

如果你盲目接受最簡可行產品(Minimum Viable Product,簡稱 MVP),並且認為你能在一個月之內建立一個既有價值又安全的產品,那麼在你推出你的“產品原型”前,你還需要多想想。在你查看了下面的清單之後,確認你不會犯這些嚴重的安全問題。至少,你要對你的潛在使用者坦誠,讓他們知道你還沒有一個完整的產品,並且只提供一個沒有全面安全的原型。

這個清單很簡單,並且也不是那種大而全的。我已經開發安全的 Web 應用有 14 年多了。這個清單包含了一些相對重要的問題。這些問題都是我在這段時間學到的,而這個過程也是痛苦的。當你在建立 Web 應用時,我希望你能夠認真地對待這些問題。

如果在這個清單中,你有我沒有提到的專案,請留言補充。

資料庫

  • [ ] 可以識別使用者的資料和敏感資料(如訪問令牌、電子郵件地址或賬單資訊)需要加密。
  • [ ] 如果你的資料庫在休息狀態時支援低成本加密(如AWS Aurora),那麼啟動該功能來保護硬碟上的資料。同時也要確保所有備份都是被加密儲存的。
  • [ ] 給使用者最低訪問許可權的賬戶。不要使用資料庫的 root 賬戶。
  • [ ] 刻意設計一個金鑰庫,用它儲存和分發機密內容。不要硬編碼到你的應用中。
  • [ ] 通過只使用 SQL 預處理語句(prepared statements)的方法來完全防止 SQL 注入。比如:如果要使用 NPM,不要使用 npm-mysql,而是使用 npm-mysql2,因為它支援預處理語句。

開發

  • [ ] 對於每個釋出的版本,確保軟體的所有元件都通過了漏洞掃描。元件指的是作業系統、庫和包。這應該自動地進入持續整合/持續交付流程。
  • [ ] 保證開發系統的安全。同樣的,對於你使用的產品系統,也需要保持相同的警惕。在安全、隔離的開發系統中開發軟體。

認證

  • [ ] 確保所有密碼都經過合適的加密方法(如 bcrypt )的雜湊處理。永遠不要自己實現加密方法,並且用好的隨機資料來正確地初始化加密方法。
  • [ ] 在實現登入、忘記密碼、密碼重置等功能時,用經過驗證過的最佳實現或元件。不要重複造輪子,因為你很難保證其在所有場景中都不會出現問題。
  • [ ]遵循簡單且合適的密碼規則,鼓勵使用者使用較長的隨機密碼。
  • [ ] 你們提供的所有服務,用多重認證來驗證登入。

拒絕服務防護

  • [ ]確保網站不會因 API 遭拒絕服務攻擊(DOS)而癱瘓。至少,在相對較慢的 API 路徑上(像登入和 Token 生成程式)設定頻率限制器。
  • [ ] 對使用者所提交的資料和請求,在大小以及結構這兩點上執行合理的限制。
  • [ ] 通過使用全域性快取代理服務(類似 CloudFlare )來規避分散式拒絕服務(DDOS)。如果網站遭到 DDOS 攻擊,你就能開啟這個服務和其他類似的,以作 DNS 查詢。

網路流量

  • [ ] 整個網站都使用 TLS,不僅僅是登入表單和響應。 永遠不要只在登入表單中使用 TLS。
  • [ ] Cookie 必須設定 httpOnly、安全、被路徑和域限定。
  • [ ] 使用內容策略安全(CSP),並且不允許 unsafe-*(*是萬用字元)後門。雖然配置時很痛苦,但這是值得做的。
  • [ ] 在客戶端的響應頭中使用 X-Frame-Option、X-XSS-Protection。
  • [ ] 使用 HSTS 響應強制僅限 TLS 訪問。在伺服器上重定向所有 HTTP 請求到 HTTPS,作為替代方案。
  • [ ] 在所有的表單中使用 CSRF 令牌(Token)。使用新的 SameSite Cookie 響應頭,這徹底解決了所有較新瀏覽器上的 CSRF 問題。

API

  • [ ] 確保公開 API 中沒有可列舉的資源。
  • [ ] 確保使用者經過全面的認證,並且擁有適當許可權的使用者才能訪問 API。
  • [ ] 在 API 中使用隨機檢查,以檢測潛在攻擊的非法或異常請求。

驗證

  • [ ] 為了給使用者快速的反饋,可以在客戶端做輸入合法性驗證,但是永遠不要相信使用者的輸入資料。
  • [ ] 在伺服器端使用白名單,來驗證所有使用者的輸入。永遠不要直接將使用者的內容新增到響應中。永遠不要在 SQL 語句中使用使用者輸入的內容。

雲配置

  • [ ] 確保所有的服務開啟儘可能少的埠。當隱晦式安全(security through obscurity)沒有保護的效果時, 將預設的埠替換成非標準的埠,這樣可以讓攻擊者更難攻破。
  • [ ] 將後端資料庫和服務託管到私有 VPC 上 (虛擬私有云),而 VPC 不能被任何公共網路訪問。當你在配置 AWS 安全組和對等 VPC 時,你需要非常仔細,因為這可能導致服務無意中對外部開放。
  • [ ] 在隔離 VPC 和對等 VPC 裡隔離邏輯服務,以便支援跨服通訊。
  • [ ] 確保所有服務接收的資料,來自於一個儘可能小範圍內的 IP 地址。
  • [ ] 限制出站 IP 和埠流量,最大限度地減少 APT 攻擊帶來的損失和“通訊”。
  • [ ] 始終使用 AWS 訪問管理(IAM)這個身份,而不是 root 憑據。
  • [ ] 授予所有操作和開發人員最小的訪問許可權。
  • [ ] 根據時間表定期地更換密碼和訪問金鑰。

基礎設施

  • [ ] 確保你能在不停機的情況下升級。確保你能通過完全自動的方式快速升級。
  • [ ] 使用像 Terraform 這樣的工具建立所有的基礎架構,而不是通過雲端控制檯。基礎架構應該被定義為“程式碼”,並且能夠按下按鈕來重建。對於任何在雲端手動建立的資源採取零容忍態度,之後 Terraform 就能審計你的配置了。
  • [ ] 所有服務都使用集中式日誌架構。你永遠都不應該需要 SSH 來訪問或者檢索日誌。
  • [ ] 除了一次性診斷,不要通過 SSH 連線到你的服務。通常使用 SSH 意味著你沒有自動執行重要任務。
  • [ ] 永遠不要在任何 AWS 服務組上保持 22 號埠為開啟的狀態。
  • [ ] 使用入侵檢測系統來最大化減少 APT 攻擊帶來的影響。

運營

  • [ ] 關閉未使用的服務和伺服器。斷電的伺服器是最安全的。

測試

  • [ ] 審計你的設計和實施。
  • [ ] 做滲透測試。除了你之外,還可以叫其他人進行滲透測試。

培訓

  • 就關於社會工程領域中的潛在威脅和相關防護技術,要對員工(特別是高階員工)進行培訓。

最後,制定一個計劃

  • [ ] 做一個威脅模型,描述你正在防禦物件。按主次列出可能的威脅和參與者。
  • [ ] 制定一份可實操的安全事故計劃。總有一天你會需要的。