美的金融科技安全開發checklist| 安全設計與開發checklist | |
|---|---|
| 檢查類型 | 檢查項(checklist) |
| 輸入驗證
|
校驗跨信任邊界傳遞的不可信數據（策略檢查數據合法性，含白名單機制等） |
| 格式化字符串時，依然要檢驗用戶輸入的合法性，避免可造成系統信息泄露或者拒絕服務 | |
| 禁止向java Runtime.exec()方法傳遞不可信、未凈化的數據（當參數中包含空格，雙引號，以-或者/符號開頭表示一個參數開關時，可能會導致參數注入漏洞）， 建議如果可以禁止JVM執行外部命令，未知漏洞的危害會大大降低，可以大大提高JVM的安全性。 |
|
| 驗證路徑之前應該先將其標准化為實際路徑（特殊的文件名，如“..”,symbolic links 、hard links、shortcuts） | |
| 從ZipInputStream提取文件，如果不在程序預期計划的目錄之內時，應拒絕將其提取出來，或者將其提取到一個安全的位置 | |
| 從ZipInputStream提取文件，若解壓之后的文件大學超過一定限制時，必須拒絕將將其解壓 | |
| 在處理以前，驗證所有來自客戶端的數據，包括：所有參數、url、http頭信息(比如：cookie名字和數據值)，確定包括了來自JavaScript、Flash或者他潛入代碼 的postf返回信息 |
|
| 如果任何潛在的危險字符必須作為輸入，請確保您執行來了額外的安全控制，比如：輸入轉義、輸出編碼、特定的安全API等。部分常見的危險字符，包含但不限於： <> " ' % () & + \ \' \" |
|
| 如果您使用的標准驗證規則無法驗證下面的輸入，那么它們需要被單獨驗證，比如驗證空字節（%00）；驗證換行符（%0d,%0a,\r,\n）;驗證路徑替代字符../或..\；如果支持UTF-8擴展字符集編碼，驗證替代字符：%c0%ae%c0%ae(使用規范化驗證雙編碼或者其他類型的編碼) | |
| 嚴格驗證來自重定向輸入的數據（一個攻擊者可能向重定向的目標直接提交惡意代碼，從而避免開應用程序邏輯以及在重定向前執行的任何驗證） | |
| 驗證數據類型 | |
| 驗證數據范圍 | |
| 驗證數據長度 | |
| 輸出編碼 |
為每一種輸出編碼方法采用一個標准的、已通過測試的規則 |
| 通過語義輸出編碼方式，對所有從服務端返回到客戶端的數據進行編碼。比如HTML編碼、URL編碼等，編碼形式根據具體的應用場景選擇 | |
| 除非對目標編譯器是安全的，否則請對所有字符進行編碼 | |
| 針對sql、xml和ldap查詢，語義凈化所有可信數據的輸出 | |
| 對操作系統命令，凈化所有不可信數據輸出 | |
| 異常處理 | 禁止在異常中泄露敏感信息（敏感數據的范圍應該基於應用場景以及產品威脅分析的結果來確定。典型的敏感數據包括口令、個人信息、通訊錄、秘鑰、數據庫信息登） |
| 禁止在異常中泄露應用服務器的指紋信息（版本、路徑、框架） | |
| 方法發生異常是要恢復到之前的對象狀態（業務操作失敗時，進行回滾業務；或者避免去修改對象狀態，維持對象狀態一致） | |
| I/O操作 | 臨時文件使用完畢及時刪除 |
| 不要講Buffer對象封裝的數據暴露給不可信帶代碼 | |
| 在多用戶系統中創建文件時指定合適訪問許可，以防止未授權的文件訪問 | |
| 當一個外部進程通過其輸出流對外輸出信息或者錯誤時，必須及時清空其輸出流，以防止輸出流中的緩沖區被耗盡而導致外部進程被阻塞 | |
| 白名單控制共享目錄操作文件權限，比如讀/寫/可執行權限 | |
| 運行環境 | 不要使用危險得許可與目標組合（比如不要將AllPermission許可賦予給不信任得代碼，不要將ReflectPermission許可和suppressAccessChencks目標組合使用，不要將java.lang.RuntimePermission許可與createClassLoader目標組合） |
| 不要禁用JVM字節碼驗證，如歌使用得字節碼，如class文件被惡意篡改，將會存在安全風險 | |
| 建議監控平台不要對互聯開放，避免照成信息泄露 | |
| 建議將所有安全敏感代碼（例如進行權限控制或者用戶名密碼校驗得代碼）都放在一個jar包中 | |
| 生產代碼不能包含任何調試代碼或接口 | |
| 身份驗證 | 除了那些特定設為“公開”的內容以外，對所有的網頁和資源都要進行身份驗證，並正確設計身份驗證功能 |
| 所有的身份驗證過程都必須在服務器后端執行 | |
| 所有的身份驗證控制應當安全的處理未成功的身份驗證，比如給出模糊的錯誤提示，隱藏敏感信息 | |
| 登錄入口應具有防止爆力猜解及撞庫猜解的措施，超過設定失敗次數需要啟用鎖定或者圖片隨機碼進行訪問控制 | |
| 采用https psot請求方式傳輸身份驗證的憑據信息 | |
| 身份壓着的失敗提示信息采用迷糊處理，比如key使用“用戶名或密碼錯誤”，而不是使用“用戶名錯誤”或者“密碼錯誤”明確提示 | |
| 涉及敏感信息或功能的外部系統連接應配置身份驗證功能，並進行有效身份驗證控制 | |
| 在執行關鍵操作（如個人信息密碼修改操作）時，應對用戶身份進行再次驗證 | |
| 為高度敏感或重要的交易賬戶使用多因子身份驗證機制，如支付密碼、短信驗證碼等 | |
| 短信驗證碼 | 一次一用 |
| 發送頻率控制（建議60s獲取一次） | |
| 驗證碼有效期（建議60s內有效，發送短信時進行友好提示） | |
| 復雜度（短信驗證碼建議6位數字） | |
| 安全提示：是否是自己操作等風險提示信息 | |
| 在前端校驗（客戶端的檢驗只能作為輔助手段，很容易被繞過），必須使用服務端代碼對輸入數據進行最終校驗 | |
| 圖形驗證碼 | 一次一用，自動刷新 |
| 驗證碼有效期（5分鍾內有效，可根據場景兼容安全和體驗靈活設置） | |
| 復雜度（4位及以上數字、字母替換並模糊處理），根據需要也可以采用拖拽驗證、計算驗證、識別驗證 | |
| 服務端進行認證，並每次驗證后清理緩存 | |
| 從用戶體驗和安全角度出發，可設計為當用戶輸入3次錯誤密碼后自動彈出驗證碼 | |
| 密碼管理 | 禁止使用私有或者弱加密算法（不如禁止使用DES，sha1等，推薦使用AES:128位，RSA:2048位，DSA2048位） |
| 采用基於哈希算法和加鹽（salt）方式安全存儲口令信息 | |
| 密碼輸入框，可設計為顯示密碼和隱藏密碼切換功能 | |
| 密碼重設和更改操作，需要進行二次合法身份驗證 | |
| 密保問題，應當支持盡可能隨機得問題提問 | |
| 密碼重設時，應對注冊手機號和郵箱進行有效驗證，鏈接只能發送多預先注冊得郵箱地址和這預先綁定得手機號 | |
| 驗證碼和鏈接應該設計一個短暫得有效期，防止暴力破解 | |
| 當密碼重新設置時，應短信通知用戶是否是本人在操作，告知安全風險 | |
| 密碼復雜度設置：建議8個字符以上，包含字母、數字及特殊字符等 | |
| 密碼設置場景中應具有密碼復雜度檢查功能 | |
| 密碼不能輸出到日志和控制台 | |
| 數據庫鏈接配置中得用戶密碼要以加密得形式存儲 | |
| 建議設計密碼定期修改提醒機制 | |
| 會話管理 | 用戶登出后應立即清理會話及其相關登錄信息 |
| 注銷功能應當完全終止相關的會話或者鏈接 | |
| 增加cookie安全性，添加“httponly” | |
| 回話cookie應設計有限期，超時后立即失效 | |
| 當設計允許用戶在多渠道終端同事登錄時，建議應進行常用設備登錄限制 | |
| 為包含已驗證的會話標識符的cookie設置域和路徑，為站點設置一個恰當的限制值。默認cookie的域是當前域名，默認cookie的路徑是當前頁面的目錄路徑。如果想要跨域或者在其他的路徑下訪問cookie就必須要重新設置這兩個屬性，domain和path | |
| 注銷功能應當可用於所有受身份驗證保護的網頁 | |
| 在平衡風險和業務功能需求的基礎上，設置一個盡量短的會話超時時間。 | |
| 不要再url、錯誤信息或者日志中暴露會話表示符，會話表示符應當只出現在http套信息中，不要將會話標識符以get參數進行傳遞 | |
| 定期生成一個新的會話標識符並周期性地使上一個會話標識符失敗（可以緩解那些標識符被獲取的特定會話劫持情況） | |
| 在身份驗證的時候，如果連接從HTTP變為HTTPS，則會生成一個新的會話標識符。在應用程序中，推薦持續使用https,不應在http和https之間來回轉換，有效避免切換過程會話被劫持篡改。 | |
| 為服務器端的操作執行標准的安全會話管理，為每個會話執行合法的身份驗證和權限控制，防止存在csrf跨站請求偽造漏洞 | |
| 訪問控制 | 將具有特權的邏輯從其他應用程序代碼中隔離開 |
| 限制只有授權的用戶才能訪問文件資源 | |
| 限制只有授權的用戶才能訪問受保護的url | |
| 限制只有授權的用戶才能訪問受保護的功能 | |
| 限制只有授權的用戶才能訪問直接對象引用 | |
| 限制只有授權的用戶才能訪問受保護的服務 | |
| 限制只有授權的用戶才能訪問受保護的應用程序數據 | |
| 限制只有授權的用戶才能訪問與安全相關的配置信息 | |
| 限制只有授權的外部應用程序或者接口才能訪問受保護的本地程序或者資源 | |
| 服務器端執行的訪問控制規則和前端實施的訪問控制規則必須匹配 | |
| 服務器中創建文件時需指定合理的訪問權限（讀/寫/可執行） | |
| 當權限重新設置發送改變時，應記錄日志，並短信通知用戶是否是本人在操作，告知可能存在的安全風險 | |
| 日志規范 | 不要在日志中保存敏感信息，包括系統指紋信息、會話標識符、賬號密碼、證件等 |
| 確保日志記錄包含了重要的日志世間數據 | |
| 記錄所有失敗的輸入驗證 | |
| 記錄所有失敗的身份驗證記錄 | |
| 記錄所有成功的身份驗證記錄 | |
| 記錄所有失敗的訪問和操作記錄 | |
| 記錄所有失敗的成功和操作記錄 | |
| 記錄明顯的修改事件，包括對於狀態數據的修改 | |
| 記錄連接無效或者已過期的會話令牌嘗試 | |
| 記錄所有的管理功能操作行為，包含但不限於安全配置設置的更改 | |
| 記錄所有失敗的后端連接 | |
| 記錄加密模塊的錯誤信息 | |
| 敏感信息 | 臨時產生的敏感數據（寫入內存或文件），應具有即時清除和釋放機制 |
| 不要再http get請求參數中包含敏感信息，如用戶名、密碼、sessionid等 | |
| 禁止表單中的自動填充功能，因為表單中可能包含敏感信息，包括身份驗證信息 | |
| 不要再客戶端上以明文形式保存密碼或者其他敏感信息 | |
| 為所有敏感信息采用SSL加密傳輸 | |
| 禁止將敏感信息硬編碼在程序中 | |
| 禁止明文存儲用戶敏感信息，如密碼、銀行卡號、身份證號等 | |
| 不要再日志中保存敏感信息，包含但不限於系統詳細信息，會話標識符，密碼等 | |
| 禁止在異常中泄露應用服務器的指紋信息，如版本信息，路徑信息，組件版本等 | |
| 禁止將源碼或者sql上傳到開源平台或者社區，如github、開源中國等 | |
| 請求只能含有敏感參數（如訂單號，id等），應進行混淆處理，防止產生參數遍歷獲取信息風險 | |
| 敏感信息需要展示在web頁面時，應在后台進行敏感字段脫敏處理 | |
| 請求返回數據不應該包含請求之外的業務數據，特別是敏感信息數據 | |
| 密碼找回安全 | 服務端做認證，避免繞過前端控制 |
| 增加二次認證因子，如驗證碼 | |
| 涉及登錄驗證token之類的，不要直接將驗證內容直接返回給用戶 | |
| 認證憑證加密，推薦強算法（AES128位、RSA2048位、DSA2048位） | |
| 認證憑證中的參數應進行混淆處理 | |
| 在多個驗證操作中，要對各驗證機制進行排序，以防出現跳過前面驗證機制直接到最后一步認證的安全風險 | |
| 手機短信驗證碼驗證，需同時校驗手機號和短信是否對應 | |
| 輸入框中，應校驗輸入數據的合法性，防止產生XSS和注入 | |
| SQL注入 | 永遠不要信任用戶的輸入，要對用戶的所有輸入進行校驗，包含sql語句的過濾和轉義 |
| 永遠不要使用動態拼接sql，可以使用參數化的sql或者使用存儲過程進行數據查詢存取 | |
| 永遠不要使用管理員權限進行數據庫連接，為每個應用使用單獨的非特權權限，且配置有限的數據庫連接數 | |
| 不要把敏感信息明文存儲，采用加密或者哈希、混淆對敏感信息進行脫敏存儲 | |
| 應用的異常信息用不帶有敏感信息，給出盡量可能少的提示；建議使用自定義的錯誤信息對原始錯誤進行包裝，可把異常信息存放在獨立的數據庫表中 | |
| xml注入 | 不要使用字符串/StringBuilder/StringBuilder/StringFormat組裝XML |
| 建議對XML元素屬性或者內容進行轉義 | |
| XSS跨站腳本攻擊 | 對輸入的數據進行過濾和轉義，包含但不限於<>" ' % () & + \ \' \"等危險特殊字符 |
| 數據添加到html元素屬性或者內容中時，誰數據進行html轉義 | |
| 數據添加到script轉義腳本中時，對數據進行script | |
| 數據添加到style中時，對數據進行css轉義 | |
| CSRF跨站請求偽造 | 建議在每個關鍵表單中引入CSRF驗證（回話中生成隨機串，提交后校驗） |
| 在關鍵表單提交時要求用戶進行二次身份驗證（錄入密碼、插入key、輸入圖片驗證碼、短信驗證碼） | |
| 對請求refer做驗證（比如跨域，系統內部應用） | |
| 文件上傳安全 | 上傳操作應設計身份驗證機制，並進行合法身份校驗 |
| 只允許上傳滿足業務需要的相關文檔類型 | |
| 通過檢查文件頭信息，比如JPEG（jpg）文件頭信息（十六進制）：FFD8FF，驗證上傳文檔是否是所期待的類型 | |
| 不要把文件保存在於應用程序相同的web環境中，建議將文件保存在專用的文檔服務器中，單獨給文檔服務器配置域名范文更好 | |
| 限制上傳任意可能被web服務器解析的文件，比如jsp、php、aspx等 | |
| 上傳文件以二進制形式下載，建議不提供直接訪問（防止木馬文件直接執行） | |
| 禁止授予上傳we你安存儲目錄可執行權限 | |
| 組件安全 | 在使用隨機數函數時，推薦使用強隨機數函數（如java.security.SecureRandom類） |
| 精簡組件中不需要得功能、方法、以免帶來未知得安全風險 | |
| 不可將系統內部使用得鎖對象暴露給不可信代碼 | |
| 建議使用SSL Socket代替Socket進行安全數據交換 | |
| 封裝本地方法調用（所有得本地方法都應該被定義為私有得，然后僅通過一個封裝方法調用） | |
| 使用安全管理器（比如java.security或第三方組件）來保護敏感操作 | |
| 編寫自定義類加載器必須覆蓋getPermissions()函數時，在為代碼源分配任意權限錢，應調用超類super.getPermissions()函數，實現處了自定義策略外，系統全局的默認安全策略也被應用 | |
| 避免完全依賴URLclassLoader和java.util.jar提供的默認自動簽名認證機制，應從加載類的代碼源（Code-Source）中獲取認證鏈，然后檢查認證是否屬於本地秘鑰庫中的受信任簽名者 | |
| 接口安全 | 調用方來源IP控制，比如可通過防火牆、主機host deny、Nginx deny等技術措施進行實施 |
| 調用方身份認證，比如key 、secret、證書等技術措施進行實施 | |
| 調用參數認證，需設計參數容錯機制，避免出現參數可遍歷敏感數據安全問題 | |
| 采用數字簽名保障接口身份來源可信，數據防篡改 | |
| 調用方權限控制設置 | |
| 調用頻率、有效期進行控制 | |
| 調用行為實時檢測，對異常阻攔 | |
| 冪等性校驗，保持數據一次性 | |
| 采用應用接入安全網關，實現APPID/KEY身份認證，加密傳輸，摘要簽名安全保障 | |
| Redis調用安全 | 用啟用客戶端IP訪問控制驗證功能 |
| 用啟用客戶端身份驗證功能 | |
| 敏感信息不要明文存儲於redis | |