一、代碼安全 · 凡普金科開發規范

## 一、代碼安全 ### （一）框架與組件 1. 【強制】禁止使用高危安全漏洞頻發的第三方開發框架和組件，如：Struts。 > **說明**：近年來，Struts框架頻繁爆發能夠導致服務器入侵事件的安全漏洞，對線上安全影響極大。 2. 【推薦】盡量避免使用長期無人維護的第三方開發框架和組件。 > **說明**：長期無人維護的第三方框架、組件，一旦被發現安全漏洞，難以得到官方的修復或升級，造成漏洞修復響應時間長、難度大，更容易被攻擊者利用。 3. 【推薦】不在代碼中引入不受控的第三方資源，如：CSS、js文件等。 ### （二）用戶請求 1. 【強制】用戶可控的輸入參數必須做有效性驗證。 > **說明**： > 未做參數校驗可以引發多種類型的漏洞，包括但不限于： > * 跨站腳本攻擊（XSS） > * SQL注入 > * 錯誤的URL解析，可能導致服務端請求偽造（SSRF）或任意URL跳轉 > * 命令執行及代碼執行 > * 文件遍歷 > * HTTP響應分割（CRLF） > * 反序列化注入 > * LDAP注入 > * XML 實體注入、XPath注入 > * 惡意order by導致數據庫慢查詢，引發應用拒絕服務 > * 用戶輸入的正則表達式導致ReDoS 2. 【強制】禁止在頁面中直接輸出未通過正確安全過濾或轉義的用戶可控輸入（包含用戶輸入并存儲于數據庫中的數據）。 > **說明**：為防止跨站腳本攻擊（XSS），應進行輸入過濾或輸出轉義，建議使用輸出轉義。 > > **示例**：<為`<`，>為&`gt;`，&為`&`，'為&`#x27;`，"為`"`。 3. 【強制】用戶可控的用于執行SQL查詢的參數，必須使用ORM、預編譯等參數化封裝形式，禁止直接拼接SQL字符串訪問數據庫。 > **說明**：如果用戶輸入為數據庫表名，則應使用正則表達式判斷，僅允許`[a-zA-Z0-9_-]`。 4. 【強制】禁止使用存在用戶可控輸入的系統命令、代碼執行語句。如必須使用，應做好輸入校驗，并由安全組進行審核。 > **說明**：用戶可控的系統命令、代碼執行，可以導致攻擊者寫入WebShell到服務器中，導致服務器被入侵。 5. 【強制】禁止在線上應用、服務器中留存可執行系統命令的后門，用于服務器變更、代碼調試等。 6. 【強制】用戶請求中的URL參數，應當僅允許http、https協議，且使用白名單限定域名/IP，防范服務端請求偽造（SSRF）及釣魚攻擊。 > **說明**： > a) 如果允許非http、https協議請求，可能通過javascript、file、gopher等協議，造成XSS、文件遍歷、命令執行等漏洞。 > b) 應使用語言自帶的方法提取URL中的host。 > c) 如果URL用于服務端請求網頁或下載文件，應當統一返回信息，使攻擊者無法判斷請求失敗的原因。如無法使用白名單進行判斷，應使用黑名單屏蔽內網請求，此時需注意302跳轉、DNS解析、數值格式IP、IPV6等繞過方法。 > d) 短鏈接跳轉應用應使用獨立的主域名。 7. 【強制】如存在請求體為XML格式的請求，應當禁用XML外部實體。 8. 【強制】增刪改操作的表單、AJAX請求必須執行CSRF安全過濾，且使用POST方法傳輸。 > **說明**：當增刪改操作的URL中，請求參數可被預測時，攻擊者可事先構造好URL，誘使受害者訪問，此時用戶即在不知情的狀態下，執行了增刪改操作。當使用GET方法執行增刪改操作時，即使是普通的流量重放或黑盒掃描，都會對業務數據產生影響。 9. 【強制】上傳文件應在后端進行有效驗證，并存儲在外網不可直接訪問的位置。 > **說明**： > **上傳文件需使用如下方式進行驗證及處理**： > a) 白名單限制后綴。 > b) 驗證請求頭的Content-Type。 > c) 文件重命名，包含隨機字符串，且不包含用戶可控字符串。 > d) 圖片執行resize、加水印等處理，破壞圖片原有結構。 > > **上傳文件存儲應滿足如下條件**： > a) 一般情況下，應存儲于不對外網開放的存儲服務器中。 > b) 如必須存儲于Web服務器本地，則需放置在非Web目錄，并禁用腳本執行權限和文件執行權限。 10. 【強制】上傳、編輯、查看、下載、刪除文件時，應當限定可操作的目錄范圍，避免跨目錄操作。 > **說明**：過濾`../`，避免路徑目錄變更。最終的拼接結果應與限定目錄比對，確認是否仍在該目錄中。 ### （三）賬號與權限 1. 【推薦】用戶登錄、注冊、用戶名檢測功能應使用驗證碼等人機交互手段,限制用戶請求次數及頻率。 2. 【強制】用戶登錄失敗時，應使用統一的出錯信息。 > **說明**：如果用戶名不存在和密碼錯誤使用不同的出錯信息，則攻擊者可以通過撞庫的手段確認用戶名是否存在、密碼是否錯誤；如使用統一的出錯信息，則攻擊者無法確定登錄失敗的原因是用戶不存在還是密碼錯誤。 3. 【強制】密碼修改時，需通過session等手段正確判斷當前用戶，并對原密碼進行校驗。 4. 【強制】密碼重置時，返回憑證應隨機不可猜測，且設置訪問次數、頻率和有效期限制，操作成功后立即失效，不應在前端代碼中出現。 5. 【強制】隸屬于用戶個人的頁面或者功能必須進行權限控制校驗。 > **說明**：防止未做水平/垂直權限校驗時，用戶可對其他用戶（同級別或更高級別）的數據進行增刪改查操作。 > **建議**：定義權限與角色，為每個用戶分配角色，做到最小權限、默認拒絕。應通過session判斷當前用戶。避免使用可遍歷的參數。 ### （四）敏感信息 1. 【強制】用戶敏感數據禁止直接對外展示，必須對展示數據做脫敏處理。 > **說明**： > **頁面展示數據包括如下幾種場景**： > a) 無需登錄，直接對外展示的數據。 > b) 登錄后，對任意用戶或特定用戶展示的他人數據。 > c) 登錄后，對用戶自己展示的數據。 > d) 登錄后，使用二次驗證手段，才對用戶自己展示的數據。 > 其中，a、b兩種場景由于存在對外展示，必須做脫敏處理；c、d兩種場景可依據業務需求決定是否脫敏。 > > **示例（建議）**： > 手機號：顯示前3后4位，如138\*\*\*\*8000。 > 證件號（身份證、護照等）：僅顯示首位3位和末位2位，如610\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*20。 > 姓名：僅顯示名，如\*錢進。 > 銀行卡號：僅顯示最后4位，如\*\*\*\*\*\*\*\*\*\*\*\*1234。 > 郵箱：僅顯示前3位和郵箱域名，其余位使用3個星號（不按照實際字符數），如iqi\*\**@163.com。 2. 【推薦】員工使用的管理后臺中，敏感信息默認不顯示或脫敏顯示，如需獲取未脫敏數據，應通過點擊按鈕等手段，避免批量獲取。員工獲取未脫敏數據時，應在日志中記錄。 3. 【強制】測試環境數據必須進行脫敏處理，嚴禁將生產數據直接用于測試。 4. 【強制】管理后臺不對外網開放，且應當設置賬號、證書、IP限制等訪問控制措施，防止任意員工直接訪問。 5. 【強制】關閉調試信息顯示，統一4XX、5XX等出錯頁面，禁止在出錯頁面上直接顯示用戶輸入或顯示數據庫錯誤信息。 > **說明**：調試、出錯頁面可能泄露Web容器、應用版本、源代碼等敏感信息。直接顯示用戶輸入的錯誤信息可能引起XSS漏洞。頁面中顯示數據庫出錯信息，可能導致數據庫信息泄露。 ### （五）流程邏輯 1. 【強制】在使用集團資源時，必須實現正確的防重放機制。如有用戶可控輸入，應當對用戶輸入進行審核。 > **說明**： > 未使用或不正確的防重放機制，可以造成用戶被騷擾、公司資損。未對用戶輸入進行有效限制，可能會存在用戶發送廣告或違法信息的風險。 > > **集團資源**包括但不限于：短信、電話、郵件、支付。 > > **防重放機制**包括： > a) 限制數量、頻率和有效期。 > b) 使用驗證碼等人機交互手段，驗證碼需在每次請求后立即失效更新。 > c) 判斷referer來源是否為本站。 2. 【推薦】使用驗證碼時，應在服務端進行校驗，并對驗證碼的請求頻率、次數進行限制。 > **說明**： > **驗證碼的處理要求**： > a）圖形驗證碼至少需要4位字母、數字混合，手機驗證碼至少需要6位純數字或4位字母、數字混合。 > b）設置驗證碼請求頻率，一定時間內請求次數過多的用戶應當予以拒絕。 > c）驗證碼需要在服務端進行校驗，并設置有效期。對于圖形驗證碼，每次請求（無論是否成功）、超出有效期均應失效重新生成。