Awesome Application Security Checklist

很棒的應用 - 安全檢查清單

如果您要牢記使用安全性設計，創建，測試您的Web/移動應用程序，則此反測量清單可能是一個很好的起點

身份驗證系統（註冊/簽名/2因子/密碼重置）

• 到處使用HTTP。
• 使用Bcrypt存儲密碼哈希（無需鹽 - Bcrypt為您提供）。
• logout後破壞會話標識符。
• 在重置密碼上銷毀所有主動會議（或提供）。
• 必須在OAuth2中具有state參數。
• 成功登錄後或任何其他中間重定向後，沒有開放的重定向。
• 解析註冊/登錄輸入時，為JavaScript：// andialsize data：//，crlf字符。
• 設置安全的，httponly cookie。
• 在基於移動OTP移動驗證中，當generate OTP或Resend OTP API時，請勿將OTP發送迴響應中。
• 限制嘗試Login ， Verify OTP ， Resend OTP並為特定用戶generate OTP API。有一個指數的向後集或/和/和/和類似基於驗證碼的挑戰。
• 在電子郵件或SMS中檢查重置密碼令牌的隨機性。
• 在合理的期間設置重置密碼令牌的到期。
• 成功使用重置令牌後到期。

用戶數據和授權

• 任何資源訪問，例如my cart ， my history都應使用會話ID檢查用戶對資源的所有權。
• 應避免串行峰值資源ID。使用/me/orders代替/user/37153/orders 。如果您忘了檢查授權令牌，這是一種理智檢查。
• Edit email/phone number功能應隨附給帳戶所有者的驗證電子郵件。
• 任何上傳功能都應消毒用戶提供的文件名。另外，由於通常原因，除了安全性外，還將上傳到S3（以及使用Lambda的後處理），而不是您自己的服務器能夠執行代碼。
• Profile photo upload功能也應消毒所有EXIF標籤（如果不需要）。
• 對於用戶ID和其他ID，請使用符合RFC的UUID而不是整數。您可以在GitHub上找到用於您的語言的實現。
• JWT很棒。如果需要，請使用單頁應用程序/API。

資料庫

• 使用加密來識別用戶和敏感數據，例如訪問令牌，電子郵件地址或計費詳細信息。
• 如果您的數據庫支持REST（例如AWS Aurora）的低成本加密，則可以使其在磁盤上保護數據。確保所有備份也被存儲了加密。
• 為數據庫訪問用戶帳戶使用最小特權。不要使用數據庫根帳戶。
• 使用為該目的設計的密鑰商店存儲和分發秘密。不要在您的應用程序中硬代碼。
• 僅通過使用SQL準備的語句完全防止SQL注入。例如：如果使用NPM，請勿使用NPM-MYSQL，請使用支持準備的語句的NPM-MYSQL2。

Android / iOS應用程序

• 付款網關中的salt不應進行硬編碼。
• 第三方SDK的secret / auth token不應進行硬編碼。
• 旨在完成server to server API調用不應從應用程序中完成。
• 在Android中，應仔細評估所有授予的權限。
• 在iOS上，在系統鍵鏈中存儲敏感信息（身份驗證令牌，API密鑰等）。請勿將此信息存儲在用戶默認值中。
• 強烈建議固定證書。

安全標頭和配置

• Add CSP標頭以減輕XSS和數據注入攻擊。這很重要。
• Add CSRF標頭以防止跨站點請求偽造。還要在cookie上添加samesite屬性。
• Add HST標題以防止SSL剝離攻擊。
• 將您的域Add到HSTS預加載列表
• Add X框架選項以防止點擊夾克。
• Add X-XSS保護標頭以減輕XSS攻擊。
• 更新DNS記錄以添加SPF記錄以減輕垃圾郵件和網絡釣魚攻擊。
• 添加子資源完整性檢查是否從第三方CDN加載JavaScript庫。為了獲得額外的安全性，請添加要求SRI-FOR CSP指導性，以免加載沒有SRI SAT的資源。
• 使用隨機的CSRF代幣並將業務邏輯API作為HTTP POST請求。例如，在初始請求升級階段中，請勿通過HTTP公開CSRF令牌。
• 請勿在獲取請求參數中使用關鍵數據或令牌。服務器日誌的暴露或計算機/堆棧處理它們會依次曝光用戶數據。

輸入的消毒

• Sanitize所有用戶輸入或暴露於用戶的任何輸入參數以防止XSS。
• 始終使用參數化查詢來防止SQL注入。
• 如果直接將其用於CSV導入等功能，則對用戶輸入進行消毒。
• 為特殊情況（例如robots.txt）作為配置文件的用戶輸入Sanitize以防您使用coolcorp.io/username之類的URL模式。
• 無論對像有多小，都不要通過字符串串聯來手動代碼或構建JSON。使用您的語言定義的庫或框架。
• 消毒輸入，這些輸入需要某種URL來防止SSRF。
• 在向用戶顯示之前對輸出進行消毒。

拒絕服務保護

• 確保對API的DOS攻擊不會削弱您的網站。至少在較慢的API路徑（例如登錄和令牌生成程序）上具有速率限制。考慮前端API上的CAPTCHA，以保護後端服務免受DOS的影響。
• 對用戶提交的數據和請求的大小和結構進行理智限制。
• 使用分佈式拒絕服務（DDOS）緩解通過CloudFlare等全球緩存代理服務。如果您遭受DDOS攻擊並作為DNS查找功能，則可以打開此功能。

營運

• 如果您很小且經驗不足，請使用AWS ElasticBeanstalk或PAAS來評估您的代碼。
• 使用一個體面的配置腳本在雲中創建VM。
• 檢查有不必要的公開open ports的機器。
• 檢查databases中的不/默認密碼，尤其是MongoDB和Redis。
• 使用SSH訪問您的機器；不要設置密碼，而是使用基於SSH的基於SSH的身份驗證。
• 及時安裝更新以對零日漏洞（如Heartbleed，Shellshock）採取行動。
• 修改服務器配置以將TLS 1.2用於HTTPS並禁用所有其他方案。 （權衡很好。）
• 請勿繼續調試模式。在某些框架中，調試模式可以提供訪問成熟的補充或外殼，或在錯誤消息stackTraces中揭示關鍵數據。
• 為不良演員和DDOS做好準備 - 使用具有DDOS減輕的託管服務。
• 為您的系統設置監視，並記錄物品（使用新的遺物或類似的東西）。
• 如果為企業客戶開發，請遵守合規要求。如果AWS S3，請考慮使用該功能加密數據。如果使用AWS EC2，請考慮使用該功能使用加密量（現在也可以加密啟動量）。

雲配置

• 確保所有服務都有最低端口。儘管通過晦澀難懂的安全性沒有保護，但使用非標準端口將使攻擊者更難。
• 在任何公共網絡上都不可見的私人VPC上的主機後端數據庫和服務。配置AWS安全組和凝視VPC時，請非常小心，這些VPC可以無意間使公眾可見。
• 在單獨的VPC和PEER VPC中隔離邏輯服務，以提供服務間通信。
• 確保所有服務僅接受最小的IP地址集中的數據。
• 限制即將發出的IP和端口流量，以最大程度地減少APT和“腐爛”。
• 始終使用AWS IAM角色而不是根憑證。
• 為所有OP和開發人員使用最小的訪問權限。
• 根據時間表定期旋轉密碼並訪問鍵。

CI和CD通過單位/集成測試覆蓋範圍審核您的設計和實施。使用代碼審核過程並無視自我批准。確保您的服務的所有組件在推入生產之前，都由AV軟件靜態掃描，包括供應商庫和其他依賴關係。設計用於部署的回滾解決方案。

人們

• 設置電子郵件（例如[email protected]）和一個頁面供安全研究人員報告漏洞。
• 根據您的製作，請限制對用戶數據庫的訪問。
• 對錯誤記者有禮貌。
• 從安全的編碼角度來完成您的代碼審查。 （更多眼睛）
• 如果發生黑客攻擊或數據洩露，請檢查以前的日誌以獲取數據訪問，請人們更改密碼。您可能需要根據您合併的位置進行外部機構進行審核。

基礎設施

• 確保您可以在不停機的情況下進行升級。確保您可以以完全自動化的方式快速更新軟件。
• 使用Terraform等工具而不是通過雲控制台創建所有基礎架構。基礎架構應定義為“代碼”，並可以按按鈕重新創建。對於雲中創建的任何資源的零公差 - Terraform然後可以審核您的配置。
• 將集中列表用於所有服務。您永遠不應需要SSH來訪問或檢索日誌。
• 除了一次性診斷外，不要進入服務。定期使用SSH，通常意味著您沒有自動化一項重要的任務。
• 不要永久對任何AWS服務組的端口22打開。而是考慮僅允許授權的IPS在框中進行SSH。
• 創建不變的主機，而不是您修補和升級的長壽命服務器。 （請參閱不變的基礎架構更安全）。
• 使用Sensedeep或服務等入侵檢測系統來最大程度地減少APT。