• EN
香港:(852)3749 9734
廣州: (020) 3808 3267
[email protected]

新聞資料

網站建設后別掉以輕心!盤點web開發者安全速查清單

  如果你覺得你可以在一個月之內開發出一款集使用價值、用戶體驗度以及安全性為一身的產品,那麼在你將產品原型真正推上市場之前,請一定要三思啊!因為你會發現在產品開發階段有可能跳過了很多重要的安全步驟,現在,小編就各位分享web開發者安全速查清單,幫助各位解決網站常見的安全問題。

  ☆ 數據庫篇

  1. 對類似訪問令牌、電子郵箱地址或賬單詳情進行加密處理,尤其是用戶的身份識別信息(密碼)。

  2. 如果你的數據庫支持低成本加密,請確保開啟這項功能并保護主機磁盤中的數據。與此同時,確保所有的備份文件都進行了加密存儲。

  3. 按照最小權限原則給數據庫訪問賬號分配權限,不要使用數據庫的root賬號。

  4. 使用秘鑰存儲器來保存或派發秘鑰,不要直接將秘鑰硬編碼在你的應用之中。

  5. 通過使用SQL預處理語句來避免SQL注入攻擊,比如說,如果你使用的是NPM,那麼請不要使用npm-mysql,你應該用的是npm-mysql2,因為它支持SQL預處理語句。

  ☆ 開發篇

  1. 確保你軟件中所有組件的每一個版本都進行了漏洞掃描,包括接口、協議、代碼以及數據包。

  2. 對產品中所有使用到的第三方工具時刻保持警惕性,選擇一款安全系數較高的開發平台

  ☆ 身份驗證篇

  1. 使用合適的加密算法(例如:bcrypt)來計算并存儲密碼,在初始加密時選擇合適的隨機數據,還有就是千萬不要自己去寫一個加密算法。

  2. 使用簡單但強壯的密碼規則,以鼓勵用戶設置長度足夠安全的隨機密碼。

  3. 在服務的登錄機制中引入多因素身份驗證功能。

  ☆ DOS保護篇

  1. 確保那些針對API的DoS攻擊不會嚴重影響你網站的正常運行,至少要限制API的請求訪問速率。

  2. 對用戶所提交的數據和請求進行結構和大小的限制。

  3. 使用緩存代理服務來爲你的Web應用添加DoS緩解方案。

  ☆ Web流量篇

  1. 使用TLS協議,不只是你的登錄表單和網站響應數據,而是你的整個網站都應該使用TLS。

  2. Cookie必須爲httpOnly。

  3. 使用CSP(內容安全策略),雖然配置過程比較麻煩,但這覺得是值得的。

  4. 在客戶端響應中使用X-Frame-Option和X-XSS-Protection頭。

  5. 使用HSTS響應,使用HTTPS加密。

  6. 在所有的表單中使用CSRF令牌。

  ☆ API篇

  1. 確保你所有的公共API中沒有可以枚舉的資源。

  2. 確保用戶在使用你的API之前,對他們的身份進行驗證。

  ☆ 驗證篇

  1. 在客戶端對用戶的輸入進行驗證,並即使給予反饋(Ajax),但永遠不要相信用戶輸入的數據。

  2. 在服務器端再對用戶所輸入的每一個字符進行一次徹底的驗證,永遠不要直接將用戶輸入的內容注入到響應數據中,永遠不要直接在SQL語句中插入用戶提供的數據。

  ☆ 雲端配置篇

  1. 確保所有的服務只開啓必要的端口,關閉不用的端口,並對常用端口進行強制性的安全保護,因爲通過非標准端口來進行攻擊對于攻擊者而言相對來說是比較困難的。

  2. 確保服務器後台數據庫和後台服務無法通過公網查看到。

  3. 在單獨的VPC節點配置邏輯服務或提供服務內通信。

  4. 確保所有的服務只接受來自有限IP地址的數據。

  5. 限制輸出數據的IP地址以及端口。

  6. 使用AWS IAM角色,不要使用root憑證。

  7. 對所有的管理員和開發人員提供最小的訪問權限。

  8. 定期更換密碼和訪問密鑰。

  ☆ 基礎設施篇

  1. 確保可以在主機不下線的情況下進行更新操作,確保部署了全自動化的軟件更新策略。

  2. 使用類似Terraform這樣的工具來創建所有的基礎設施,不要使用雲端console(控制台)來進行創建。

  3. 對所有服務的日志進行集中記錄,不要通過SSH來訪問或獲取日志。

  4. 不要讓AWS服務組的端口22保持開啓狀態。

  5. 一定要部署入侵檢測系統。

  ☆ 操作篇

  1. 關閉不用的服務和服務器,因爲最安全的服務器是那些關閉著的服務器。

  ☆ 測試篇

  1. 開發完成之後,對你的設計和代碼實現進行多次安全審查。

  2. 進行滲透測試,也就是自己黑自己,但你也要讓別人來對你的網站進行滲透測試。

  ☆ 計劃篇

  1. 創建一個安全威脅模型,用來描述你可能會遇到的威脅以及攻擊者。

  2. 設計一個安全應急響應方案,你總有一天會用到的。