金融科技SDL安全設計Checklist-v1

金融科技SDL安全設計Checklistv1.0,

檢查類型,檢查項(Checklist)

輸入驗證,校驗跨信任邊界傳遞的不可信數(shù)據(jù)(策略檢查數(shù)據(jù)合法性，含白名單機制等)

,格式化字符串時，依然要檢驗用戶輸入的合法性，避免可造成系統(tǒng)信息泄露或者拒絕服務

,禁止向JavaRuntime.exec()方法傳遞不可信、未凈化的數(shù)據(jù)(當參數(shù)中包含空格，雙引號，以-或者/符號開頭表示一個參數(shù)開關(guān)時，可能會導致參數(shù)注入漏洞)，建議如果可以禁止JVM執(zhí)行外部命令，未知漏洞的危害性會大大降低，可以大大提高JVM的安全性。

,驗證路徑之前應該先將其標準化為實際路徑（特殊的文件名，比如“..”，symboliclinks、hardlinks、shortcuts）

,從ZipInputStream提取文件，如果不在程序預期計劃的目錄之內(nèi)時，應拒絕將其提取出來，或者將其提取到一個安全的位置

,從ZipInputStream提取文件，若解壓之后的文件大小超過一定的限制時，必須拒絕將其解壓

,在處理以前，驗證所有來自客戶端的數(shù)據(jù)，包括：所有參數(shù)、URL、HTTP頭信息（比如：cookie名字和數(shù)據(jù)值），確定包括了來自JavaScript、Flash或其他嵌入代碼的post返回信息

,"如果任何潛在的危險字符必須被作為輸入，請確保您執(zhí)行了額外的安全控制，比如：輸入轉(zhuǎn)義、輸出編碼、特定的安全API等。部分常見的危險字符，包含但不限于：<>""'%()&+\\'\"""

,"如果您使用的標準驗證規(guī)則無法驗證下面的輸入，那么它們需要被單獨驗證，比如驗證空字節(jié)(%00)；驗證換行符(%0d,%0a,\r,\n)；驗證路徑替代字符“點-點-斜杠”（../或..\）；如果支持UTF-8擴展字符集編碼，驗證替代字符：%c0%ae%c0%ae/(使用規(guī)范化驗證雙編碼或其他類型的編碼)"

,嚴格驗證來自重定向輸入的數(shù)據(jù)（一個攻擊者可能向重定向的目標直接提交惡意代碼，從而避開應用程序邏輯以及在重定向前執(zhí)行的任何驗證）

,驗證數(shù)據(jù)類型

,驗證數(shù)據(jù)范圍

,驗證數(shù)據(jù)長度

,,

輸出編碼,為每一種輸出編碼方法采用一個標準的、已通過測試的規(guī)則

,通過語義輸出編碼方式，對所有從服務端返回到客戶端的數(shù)據(jù)進行編碼。比如HTML編碼、URL編碼等，編碼形式需根據(jù)具體的應用場景選擇

,除非對目標編譯器是安全的，否則請對所有字符進行編碼

,針對SQL、XML和LDAP查詢，語義凈化所有不可信數(shù)據(jù)的輸出

,對于操作系統(tǒng)命令，凈化所有不可信數(shù)據(jù)輸出

,,

異常處理,禁止在異常中泄露敏感信息（敏感數(shù)據(jù)的范圍應該基于應用場景以及產(chǎn)品威脅分析的結(jié)果來確定。典型的敏感數(shù)據(jù)包括口令、銀行賬號、個人信息、通訊記錄、密鑰等）

,禁止在異常中泄露應用服務器的指紋信息（如版本，路徑，架構(gòu)）

,方法發(fā)生異常時要恢復到之前的對象狀態(tài)（業(yè)務操作失敗時，進行回滾業(yè)務；或者避免去修改對象狀態(tài)，維持對象狀態(tài)一致性）

,,

I/O操作,臨時文件使用完畢應及時刪除

,不要將Buffer對象封裝的數(shù)據(jù)暴露給不可信代碼

,在多用戶系統(tǒng)中創(chuàng)建文件時指定合適的訪問許可，以防止未授權(quán)的文件訪問

,當一個外部進程通過其輸出流對外輸出信息或錯誤時，必須及時清空其輸出流，以防止輸出流中的緩沖區(qū)被耗盡而導致外部進程被阻塞。

,白名單控制共享目錄操作文件權(quán)限，比如讀/寫/可執(zhí)行權(quán)限

,,

運行環(huán)境,不要使用危險的許可與目標組合（比如不要將AllPermission許可賦予給不信任的代碼，不要將ReflectPermission許可和suppressAccessChecks目標組合使用，不要將java.lang.RuntimePermission許可與createClassLoader目標組合）

,不要禁用JVM字節(jié)碼驗證，如果使用的字節(jié)碼，如class文件被惡意篡改過，將會存在安全風險

,建議監(jiān)控平臺不要對互聯(lián)網(wǎng)開放，僅限于內(nèi)網(wǎng)環(huán)境訪問；如果監(jiān)控平臺存在遠程執(zhí)行漏洞，將會給所監(jiān)控的應用帶來安全風險

,建議將所有安全敏感代碼(例如進行權(quán)限控制或者用戶名密碼校驗的代碼)都放在一個jar包中

,生產(chǎn)代碼不能包含任何調(diào)試代碼或接口

,,

身份驗證,除了那些特定設為“公開”的內(nèi)容以外，對所有的網(wǎng)頁和資源都要求進行身份驗證，并正確設計身份驗證功能

,所有的身份驗證過程必須在服務器后端上執(zhí)行

,在任何可能的情況下，建立并使用標準的、已通過安全測試的身份驗證服務(比如C4A)

,所有的身份驗證控制應當安全的處理未成功的身份驗證，比如給出錯誤模糊提示，隱藏敏感信息

,登錄入口應具有防止暴力猜解及撞庫猜解（利用已泄漏的密碼字典進行批量登錄嘗試）的措施，超過設定失敗次數(shù)需要啟用鎖定或圖片隨機碼進行訪問限制

,采用httpspost請求方式傳輸身份驗證的憑據(jù)信息

,身份驗證的失敗提示信息采用模糊處理，比如可以使用“用戶名或密碼錯誤”，而不要使用“用戶名錯誤”或者“密碼錯誤”明確提示。

,涉及敏感信息或功能的外部系統(tǒng)連接應配置身份驗證功能，并進行有效身份驗證控制

,在執(zhí)行關(guān)鍵操作（如個人信息密碼修改操作）時，應對用戶身份進行再次驗證

,為高度敏感或重要的交易賬戶使用多因子身份驗證機制，如支付密碼、短信驗證碼等

,,

短信驗證碼,一次一用

,發(fā)送頻率控制（建議60s獲取一次）

,驗證碼有效期（建議60s內(nèi)有效，發(fā)短信時進行友好提示）

,復雜度（短信驗證碼建議6位數(shù)字）

,安全提示：是否是個人自己操作等風險提示信息

,在前端校驗（客戶端的校驗只能作為輔助手段，很容易被繞過），必須使用服務端代碼對輸入數(shù)據(jù)進行最終校驗

,,

圖形驗證碼,一次一用

,驗證碼有效期(10分鐘內(nèi)有效，可根據(jù)場景兼容安全和體驗靈活設置)

,復雜度（4位及以上數(shù)字、字母交替），根據(jù)需要也可采用當下流行的拖拽驗證碼或計算值的驗證方式

,服務器端進行認證

,從用戶體驗和安全角度出發(fā)，可設計為當用戶輸3次錯誤密碼后自動彈出驗證碼輸入框進行驗證操作

,,

檢查類型,檢查項(Checklist)

密碼管理,禁止使用私有或者弱加密算法（比如禁止使用DES，SHA1等，推薦使用AES:128位，RSA:2048位，DSA:2048位）

,采用基于哈希算法和加入鹽值（salt）方式安全存儲口令信息

,密碼輸入框，可設計為顯示密碼和隱藏密碼切換功能

,密碼重設和更改操作，需要進行二次合法身份驗證

,密碼重設時，應對注冊手機號和郵箱進行有效驗證，鏈接只能發(fā)送到預先注冊的郵件地址或預先綁定的手機號

,臨時密碼和鏈接應設計一個短暫的有效期（比如5分鐘），防止暴力破解

,當密碼重新設置時，應短信通知用戶是否是本人在操作，告知安全風險

,密碼復雜度設置：建議8個字符以上，包含字母、數(shù)字及特殊字符等

,密碼設置場景中應具有密碼復雜度檢查功能

,密碼不能輸出到日志和控制臺

,數(shù)據(jù)庫連接配置中的用戶密碼要以加密的形式存儲

,建議設計密碼定期修改提醒機制

,,

會話安全,用戶登出后應立即清理會話及其相關(guān)登錄信息

,注銷功能應當完全終止相關(guān)的會話或連接

,"增加Cookie安全性，添加“HttpOnly”和“secure”屬性（當“secure”屬性設置為true時表示創(chuàng)建的Cookie會被以安全的形式向服務器傳輸，也就是只能在HTTPS連接中被瀏覽器傳遞到服務器端進行會話驗證，在HTTP連接中不會傳遞該信息，也就不會存在Cookie被竊取的問題；設置了""HttpOnly""屬性，通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，這樣也能減少XSS跨站腳本攻擊風險）"

,會話cookie應設計有效期，超時后立即失效

,當設計允許用戶在多渠道終端同時登錄時，建議應進行常用設備登錄限制

,為包含已驗證的會話標識符的cookie設置域和路徑，為站點設置一個恰當?shù)南拗浦?。默認cookie的域是當前域名，默認cookie的路徑是當前頁面的目錄路徑。如果想要跨域或者在其他的路徑下訪問cookie就必須要重新設置這兩個屬性，domain和path。

,注銷功能應當可用于所有受身份驗證保護的網(wǎng)頁

,在平衡風險和業(yè)務功能需求的基礎(chǔ)上，設置一個盡量短的會話超時時間。通常情況下，應當不超過幾個小時。

,不要在URL、錯誤信息或日志中暴露會話標識符，會話標識符應當只出現(xiàn)在http頭信息中，不要將會話標識符以GET參數(shù)進行傳遞

,定期生成一個新的會話標識符并周期性地使上一個會話標識符失效（這可以緩解那些原標識符被獲得的特定會話劫持情況）

,在身份驗證的時候，如果連接從HTTP變?yōu)镠TTPS，則會生成一個新的會話標識符。在應用程序中，推薦持續(xù)使用HTTPS，不應在HTTP和HTTPS之間來回轉(zhuǎn)換，有效避免切換過程會話被劫持篡改。

,為服務器端的操作執(zhí)行標準的安全會話管理，為每個會話執(zhí)行合法的身份驗證和權(quán)限控制，防止存在CSRF跨站點請求偽造漏洞

,,

訪問控制,將具有特權(quán)的邏輯從其他應用程序代碼中隔離開

,限制只有授權(quán)的用戶才能訪問文件資源

,限制只有授權(quán)的用戶才能訪問受保護的URL

,限制只有授權(quán)的用戶才能訪問受保護的功能或服務

,建議只有授權(quán)的用戶才能訪問直接對象引用

,限制只有授權(quán)的用戶才能訪問受保護的應用程序數(shù)據(jù)

,限制只有授權(quán)的用戶才能訪問與安全相關(guān)的配置信息

,限制只有授權(quán)的外部應用程序或接口才能訪問受保護的本地程序或資源

,服務器端執(zhí)行的訪問控制規(guī)則和前端實施的訪問控制規(guī)則必須匹配

,服務器中創(chuàng)建文件時需指定合理的訪問權(quán)限（讀/寫/可執(zhí)行）

,當權(quán)限重新設置發(fā)生變更時，應記錄好日志，并短信通知用戶是否是本人在操作，告知可能存在的安全風險

,,

日志規(guī)范,不要在日志中保存敏感信息，包括系統(tǒng)指紋信息、會話標識符、賬號密碼、證件、ID等

,確保日志記錄包含了重要的日志事件數(shù)據(jù)

,記錄所有失敗和成功的輸入驗證

,記錄所有失敗和成功的身份驗證記錄

,記錄所有失敗和成功的訪問和操作記錄

,記錄明顯的修改事件，包括對于狀態(tài)數(shù)據(jù)的修改

,記錄連接無效或者已過期的會話令牌嘗試

,記錄所有的管理功能操作行為，包含但不限于安全配置設置的變更

,記錄所有失敗和成功的后端連接

,記錄加密模塊的錯誤信息

,,

敏感信息,臨時產(chǎn)生的敏感數(shù)據(jù)（寫入內(nèi)存或文件），應具有及時清除和釋放機制

,不要在HTTPGET請求參數(shù)中包含敏感信息，如用戶名、密碼、卡號、ID等

,禁止表單中的自動填充功能，因為表單中可能包含敏感信息，包括身份驗證信息

,不要在客戶端上以明文形式保存密碼或其他敏感信息

,為所有敏感信息采用SSL加密傳輸

,禁止將敏感信息（包含加密秘鑰等）硬編碼在程序中

,禁止明文存儲用戶的密碼、身份證號、銀行卡號、持卡人姓名等敏感信息

,不要在日志中保存敏感信息，包含但不限于系統(tǒng)詳細信息、會話標識符、密碼等

,禁止在異常中泄露應用服務器的指紋信息，如版本，路徑，組件版本等

,禁止將源碼或sql上傳到開源平臺或社區(qū)，如github、開源中國等

,請求中含有敏感參數(shù)（如訂單號、ID等），應進行混淆方式處理，防止產(chǎn)生參數(shù)遍歷獲取信息風險

,敏感信息需要展示在web頁面上時，應在后臺進行敏感字段脫敏處理

,請求返回數(shù)據(jù)不應包含請求之外的業(yè)務數(shù)據(jù)，特別是敏感信息數(shù)據(jù)

,,

檢查類型,檢查項(Checklist)

密碼找回安全,服務器端要做認證，避免繞過前端控制

,增加二次認證因子，如驗證碼

,涉及登錄驗證token之類的，不要直接將驗證內(nèi)容直接返回給用戶

,認證憑證加密，推薦強算法（推薦使用AES:128位，RSA:2048位，DSA:2048位）

,認證憑證中的參數(shù)應進行混淆處理

,在多個驗證操作中，要對各驗證機制進行排序，以防出現(xiàn)跳過前面驗證機制直接到最后一步認證的安全風險

,手機短信碼驗證，需同時校驗手機號和短信是否對應

,輸入框中，應校驗輸入數(shù)據(jù)合法性，防止產(chǎn)生XSS跨站腳本攻擊

,,

SQL注入,永遠不要信任用戶的輸入，要對用戶的所有輸入進行校驗，包含SQL語句的過濾和轉(zhuǎn)義

,永遠不要使用動態(tài)拼裝SQL，可以使用參數(shù)化的SQL或者使用存儲過程進行數(shù)據(jù)查詢存取

,永遠不要使用管理員權(quán)限進行數(shù)據(jù)庫連接，為每個應用使用單獨的非特權(quán)權(quán)限，且配置有限的數(shù)據(jù)庫連接數(shù)

,不要把敏感信息明文存放，采用加密或者哈希、混淆等方式對敏感信息進行脫敏存儲

,應用的異常信息應不帶有敏感信息，給出盡可能少的提示；建議使用自定義的錯誤信息對原始錯誤信息進行包裝，可把異常信息存放在獨立的數(shù)據(jù)庫表中

,,

XML注入,不要使用字符串/StringBuffer/StringBuilder/StringFormat組裝XML

,建議對XML元素屬性或者內(nèi)容進行轉(zhuǎn)義

,,

XSS跨站腳本攻擊,"對輸入的數(shù)據(jù)進行過濾和轉(zhuǎn)義，包含但不限于<>""'%()&+\\'\""等危險特殊字符"

,數(shù)據(jù)添加到html元素屬性或者內(nèi)容中時，對數(shù)據(jù)進行HTML轉(zhuǎn)義

,數(shù)據(jù)添加到script腳本中時，對數(shù)據(jù)進行script轉(zhuǎn)義

,數(shù)據(jù)添加到style中時，對數(shù)據(jù)進行css轉(zhuǎn)義

,,

CSRF跨站請求偽造,建議在每個關(guān)鍵表單中引入了CSRFToken驗證(會話中生成的隨機串，提交后校驗)

,在關(guān)鍵表單提交時要求用戶進行二次身份驗證（錄入密碼、插KEY、輸入圖片驗證碼、短信驗證碼）

,對請求refer做驗證（比如跨域、系統(tǒng)內(nèi)部應用）

,,

文件上傳安全,上傳操作應設計身份驗證機制，并進行合法身份校驗

,只允許上傳滿足業(yè)務需要的相關(guān)文檔類型

,通過檢查文件頭信息，比如JPEG(jpg)文件頭信息（十六進制）：FFD8FF，驗證上傳文檔是否是所期待的類型

,不要把文件保存在與應用程序相同的Web環(huán)境中，建議將文件保存在專用的文檔服務器中，單獨給文檔服務器配置域名訪問更好

,限制上傳任意可能被Web服務器解析的文件，比如jsp、php等

,上傳文件以二進制形式下載，建議不提供直接訪問（防止木馬文件直接執(zhí)行）

,禁止授予上傳文件存儲目錄的可執(zhí)行權(quán)限

,,

組件安全,在使用隨機數(shù)函數(shù)時，推薦使用強隨機數(shù)函數(shù)（例如java.security.SecureRandom類）

,精簡組件中不需要的功能、方法，以免帶來未知的安全風險

,不可將系統(tǒng)內(nèi)部使用的鎖對象暴露給不可信代碼

,建議使用SSLSocket代替Socket來進行安全數(shù)據(jù)交互

,封裝本地方法調(diào)用（所有的本地方法都應該被定義為私有的，然后僅通過一個封裝方法來調(diào)用）

,使用安全管理器（比如java.security或第三方安全組件）來保護敏感操作

,編寫自定義類加載器必