XX-3-DEV-安全編碼規(guī)范20110501

第10頁共NUMPAGES\*Arabic10頁文檔編號文檔編號XX_安全編碼規(guī)范版本號V2.0密級秘密安全編碼規(guī)范版本控制編號修訂人修訂時間版本號修訂內容說明第10頁共NUMPAGES\*Arabic10頁目錄TOCHYPERLINK\l"__RefHeading__2_470868493"1背景 4HYPERLINK\l"__RefHeading__4_470868493"2目標 4HYPERLINK\l"__RefHeading__6_470868493"3適應范圍 4HYPERLINK\l"__RefHeading__8_470868493"4安全概念 4HYPERLINK\l"__RefHeading__10_470868493"5應用安全編碼規(guī)范 4HYPERLINK\l"__RefHeading__12_470868493"1.1Session使用及處理 4HYPERLINK\l"__RefHeading__14_470868493"1.2Cookie使用及處理 4HYPERLINK\l"__RefHeading__16_470868493"1.3URL參數 5HYPERLINK\l"__RefHeading__18_470868493"1.4表單提交 5HYPERLINK\l"__RefHeading__20_470868493"1.5Ajax 5HYPERLINK\l"__RefHeading__22_470868493"1.6接口簽名 5HYPERLINK\l"__RefHeading__24_470868493"1.7信息驗證 6HYPERLINK\l"__RefHeading__26_470868493"1.8線程控制 6HYPERLINK\l"__RefHeading__28_470868493"1.9業(yè)務邊界及業(yè)務檢測 6HYPERLINK\l"__RefHeading__30_470868493"1.10數據庫 7HYPERLINK\l"__RefHeading__32_470868493"1.11資金處理 7HYPERLINK\l"__RefHeading__34_470868493"1.12數據 7HYPERLINK\l"__RefHeading__36_470868493"1.13遠程調用 7HYPERLINK\l"__RefHeading__38_470868493"1.14口令策略 8HYPERLINK\l"__RefHeading__40_470868493"1.15應用攻擊防守策略 8HYPERLINK\l"__RefHeading__42_470868493"6JVM安全和java語言安全特性 8HYPERLINK\l"__RefHeading__44_470868493"7日常維護發(fā)布檢測規(guī)范 9HYPERLINK\l"__RefHeading__46_470868493"8參考資料 10背景安全編碼規(guī)范可以說是公司安全體系的重要部分，安全編碼做得不好，直接導致系統(tǒng)漏洞，資金賬戶被盜，用戶損失，更重要的是給XXX公司的形象帶來負面的影響。因此安全編碼規(guī)范亟待出爐，來進一步規(guī)范公司的工程師編碼安全意識。本編碼規(guī)范以J2EE相關編程為基礎，進行舉例和解釋。目標從應用系統(tǒng)安全角度出發(fā)，結合過去的編碼經驗和問題總結，給出合適的安全編碼條文實例，突出重點和安全分類，在目前已知的多項重大安全問題上進行總結和目前流行的安全問題做法，當然安全問題的多樣性，也會不斷進行修改本規(guī)范，以持續(xù)的進行指導XXX工程師的編碼安全意識。適應范圍公司相關程序員、工程師及相關技術人員。安全概念不僅僅是被攻擊和解密，造成代碼覆蓋、金額數據錯誤、內存溢出，死鎖，宕機，甚至發(fā)布順序錯誤等等一切非正?，F(xiàn)象，XXX都認為是安全問題。軟件開發(fā)安全應該在幾個階段都有體現(xiàn)，需求，設計，開發(fā)，測試，部署上線等多個階段。本規(guī)范主要描述在研發(fā)編碼階段的注意事項。本標準基本參照OWASPTOP10的相關要求制訂，建議讀者認真閱讀其中具體內容，以加深對信息安全的理解。應用安全編碼規(guī)范Session使用及處理Session修改：除了登錄處理公共類，不允許在代碼中修改Session中的用戶識別信息，如user_id、user_email等，以及用戶操作相關的的內容。(說明：可防止用戶原始ID被覆蓋，造成用戶信息混亂)使用session變量：A：防止放入session的值覆蓋已經存在的變量，要注意命名。B：不允許在session中存放大對象，否則，容易造成系統(tǒng)堆空間溢出。Cookie使用及處理Cookie中的關鍵業(yè)務數據必須進行加密。（建議不要將敏感數據放入cookie）URL參數HTML中通過hidden或者url中的參數來傳遞業(yè)務數據，隱藏字段已經是黑客攻擊的最基本手段之一了，必須做到關鍵業(yè)務數據的加密和防止篡改。不能把關鍵業(yè)務數據直接通過hidden字段傳遞，用戶完全可以通過重寫源代碼的方式修改業(yè)務數據發(fā)送請求從而繞過我們的安全規(guī)范。建議：可以通過session和request中的請求參數一致來處理、參數作加密、或者作摘要的方式。例如：有一個業(yè)務是通過類似下面這樣一個鏈接就可以操作某項業(yè)，我們必須要對這個傳值做一定的防偽，可以在請求之前就把這個user_id記錄在session中，業(yè)務操作的時候做一下比對；或者接口參數中再加入一個參數sign=xxx作為摘要。（防篡改：可使用MD5對關鍵數據做摘要；數據保密：對敏感數據進行加密，算法有BlowfishDES3DES等。）一些頁面的出現(xiàn)必須有前一頁面出現(xiàn)才可以進入下一頁面，禁止出現(xiàn)用戶可以直接輸入下一個頁面URL就可以跨過前面頁面的業(yè)務限制就直接操作。后門調試URL漏洞：開發(fā)人員常常建立一些后門并依靠調試來排除應用程序的故障。在開發(fā)過程中這樣做可以，但這些安全漏洞經常被留在一些放在Internet上的最終應用中。一些常見的后門使用戶不用口令就可以登錄或者訪問允許直接進行應用配置的特殊URL，日常測試的URL在產品上線后必須撤銷。（所有可以在線上環(huán)境訪問到的測試全部放到統(tǒng)一的測試模塊）表單提交避免使用以GET方式提交表單。GET方式提交表單，表單中的參數會在瀏覽器地址欄中顯示，而且瀏覽器不會控制表單提交的刷新操作。在瀏覽器中顯示表單參數，容易造成惡意用戶欺騙對電腦安全不熟悉的用戶復制帶參數的URL供他使用。對于不允許重復提交的表單，必須采用相關框架中的工具控制住表單的重復提交。建議所有的表單都做控制。不允許出現(xiàn)頁面向自身重定向、或者多個頁面間相互重定向的情況。如果控制不當，很容易造成系統(tǒng)宕機。不允許直接將用戶的輸入嵌入在頁面模板中直接輸出。例如，用戶請求user/user_register.htm?registerFrom="><script>alert('xss');</script><"，在頁面上直接輸出$registerFrom，造成了跨站腳本攻擊。疑問:這個要求對開發(fā)人員是否要求過高？研究統(tǒng)一的解決方案，如果可以統(tǒng)一解決，則開發(fā)人員可以避免自行處理這類繁瑣的問題。(說明，目前這樣的問題在系統(tǒng)中是大量存在的，統(tǒng)一解決方案勢在必行)添加新的頁面，必須同時添加權限控制規(guī)則Form提交數據，盡可能使用POST，而避免使用GET方法（容易被人模擬）AjaxAJAX很多時候把service層暴露出去，考慮如何將Service隱藏，來保證自身的業(yè)務安全性。接口簽名外部接口必須要考慮簽名，現(xiàn)在XXX通用的有HMAC，也可以在考慮使用MD5和DSA。特別是通過HTTP請求的外部重定向，只要用一些工具都可以看到重定向信息；通過客戶端（例如網頁嵌套flash）訪問系統(tǒng)也需要簽名。接口、類專人專管：重要的類、接口有專人管理。不要隨便動其他人重要的類，也不要讓別人隨便動我們重要的類。把這些不能隨便改的代碼以及負責人進行統(tǒng)一管理。（建議SVN、CVS權限分開）信息驗證信息公開發(fā)送問題：不能將用戶信息通過郵件或者其他方式發(fā)送到第三方網站！信息雙重驗證機制：輸入信息嚴格禁止僅僅通過客戶端代碼(例如javascript)驗證，程序必須要再次驗證一下。用戶信息獲取和歸屬權驗證：用戶身份信息只允許從session中獲取，不允許通過輸入參數獲??；在進行業(yè)務處理之前，必須校驗用戶操作的數據是他所擁有的數據，而不是他人的數據。（說明：可防止諸如修改了其它人的領獎地址記錄，進行積分兌換等問題）并發(fā)控制多用戶操作的數據必須加并發(fā)控制，分布式應用不宜采用線程安全(synchronized)的方式，目前來說通過鎖定數據庫關鍵記錄是一個不錯的建議。數據資源是單行的情況下，如果涉及到資金操作，必須先鎖定。例如：某用戶的積分，某用戶的余額等（對于非更新操作時，可通過表中增加uniqueindex）更新多條記錄，或者為記錄加鎖需要使用一致的順序，否則會造成死鎖。單例對象或者靜態(tài)Util必須是線程安全的，否則一旦共享對象被破壞，會產生嚴重的業(yè)務錯誤，或者系統(tǒng)不可用。說明：論壇系統(tǒng)中的一個日期靜態(tài)Util類的線程安全問題曾造成論壇宕機；工作流平臺的一個線程安全問題造成線程處理死循環(huán)，服務器load異常升高。（springbean默認為singleton）如果使用了線程上下文變量，必須確保線程上下文變量的設置操作與清除操作是配對的，要求以try{設置線程上下文變量}finally{清除線程上下文變量}的形式確保兩者是配對的。DateFormat類是非線程安全的，類變量使用時會被破壞，每次使用都要構造。線程控制線程統(tǒng)一處理，不允許在應用中自行顯式創(chuàng)建線程，需使用線程池。不允許在響應前臺用戶請求的處理中使用線程的sleep方法，或者wait/notify方法。服務前臺請求的線程在系統(tǒng)中共享使用的寶貴資源，一旦被堵塞，很容易造成系統(tǒng)不可用。異步任務處理中，可以恰當地使用wait/notify等線程同步機制，但必須確保設計的可靠性與魯棒性。業(yè)務邊界及業(yè)務檢測多表的修改或者更新必須要考慮事務機制無論web層是否檢測，核心業(yè)務層必須有完善的檢測機制。業(yè)務邊界檢測：關鍵判斷必須有邊界檢查，例如我們剩余商品都是正整數，那它的邊界檢查就是X<=0或者X>0，X=0的事情，這樣就是通過系統(tǒng)去保證業(yè)務正確性，如果有一個系統(tǒng)代碼有問題就可能破壞業(yè)務的正確性。注：業(yè)務數字與自然數字的區(qū)別在于：業(yè)務數據具有很強的約束；例如不能為負值，不能超過某一額度，累計不能超過某一額度等數據庫批量任務及事務分割：批量任務必須要考慮會不會重復執(zhí)行。避免一個事務中進行大規(guī)模數據處理。批量任務處理時，必須恰當設計事務的大小，一般在500到1000次處理提交一次比較合理。事務長度過小，會造成性能低下；事務長度過大，會大量占用數據庫回滾段（假設有一個每天晚上的認證提現(xiàn)，一次5萬筆。最好拆成1000筆一批，做完一批提交一次。具體視業(yè)務情況而定）事務處理過程中，不允許執(zhí)行可能產生線程阻塞的調用，如文件讀寫、未設置超時的網絡訪問等，否則一旦線程阻塞，會始終占用數據庫連接資源，甚至可能占用數據庫共享記錄，造成其它業(yè)務處理無法繼續(xù)（應用中在事務內生成一個隨機數，結果API調用阻塞了，服務器就掛了。讀取文件的時候,如果文件不可用,那么出現(xiàn)問題）大數據量查詢限制：對于返回多記錄的查詢，如果業(yè)務上不能保證數據量的限制，必須在查詢中加上數據量限制，否則查詢結果集過大會造成數據庫與服務器性能嚴重問題。例如：在登錄時有一個IP地址黑名單檢查操作，操作中查詢出黑名單表中的所有IP地址記錄，隨著黑名單表大小的增加，這樣的操作會產生很大的性能風險數據庫的更新與刪除語句中，盡量不使用動態(tài)條件子句，否則一旦出現(xiàn)SQL的所有動態(tài)條件子句都不滿足的情況，可能出現(xiàn)更新或刪除表中全部記錄的情況，造成災難性的后果。（如wheretrade_no=?），數據庫有時也是不可信的。資金處理資金處理：資金計算與處理必須使用BigDecimal類，而不允許使用浮點數（如double/float等），否則會有精度問題。BigDecimal類的構造不允許使用浮點數，否則，由于Oracledriver的一個bug，會造成數據存儲之后的值產生數量級的變化，產生嚴重的資金風險。DB2目前還不清楚，有待發(fā)現(xiàn)驗證。正確的構造方法是使用整型數或者字符串來構造BigDecimal，如newBigDecimal(“10.00”)。數據數據安全檢查：業(yè)務數據安全檢查時，確保該業(yè)務數據是當前操作用戶的，例如查找某一個訂單時，使用訂單ID、用戶ID一起進行查找，同樣更新某信息時一定也是依據多關鍵字進行更新。必須確?？値祿兔骷殧祿囊恢滦?。對于具有平衡關系的業(yè)務數據，每次進行數據修改之前，進行平衡檢查。必須考慮到發(fā)布期間可能出現(xiàn)的各種問題，如前臺和交易核心的發(fā)布順序問題遠程調用遠程調用中傳輸對象必須序列化。遠程服務接口發(fā)生變更，包括webservice接口方法或者接口參數發(fā)生改變，或者消息體發(fā)生變化，必須測試新舊接口和數據的兼容性，如果兼容性存在問題，必須制定完善的發(fā)布計劃解決這個問題。否則或者造成發(fā)布期間系統(tǒng)不可用，或者由于客戶端與服務端對數據理解不一致引起業(yè)務處理錯誤。使用SSL進行通信：SSL是SecuritySocketLayer的縮寫，技術上稱為安全套接字，可以簡單為加密通訊協(xié)議，使用SSL可以對通訊（包括電子郵件）內容進行高強度的加密，以防止黑客監(jiān)聽您的通訊內容甚至是用戶密碼。SSL協(xié)議指定了一種在應用程序協(xié)議（如HTTP、Telenet、NMTP和FTP等）和TCP/IP協(xié)議之間提供數據安全性分層的機制，它為TCP/IP連接提供數據加密、服務器認證、消息完整性以及可選的客戶機認證。口令策略強制要求和驗證用戶設置的口令強度，如驗證口令長度、身份包含數字、字符、特殊符合等允許用戶更改自己的口令源碼中不出現(xiàn)任何口令口令加密存儲默認口令必須修改使用應用攻擊防守策略SQL注入：例如：SELECT*FROMEMPWHERENAME=”DALEZHU”攻擊者通常會使用特殊含義的字符或字符串利用這些漏洞例如在SQL中單引號是危險的字符；在Shell命令中；分號比較危險；通過對同一段元字符的多種編碼方式及對同一種語言的多種實現(xiàn)方式，這個問題更加危險；使用正確的參數化SQL；SQL特殊字符轉義為了防止他人使用特殊SQL字符破壞SQL的語句結構或植入惡意操作，必須在變量拼接到SQL語句之前對其中的特殊字符進行轉義處理方法入參檢測工具。JVM安全和java語言安全特性假如攻擊者能在一個多用戶共享JVM的環(huán)境中(例如TomcatHTTP服務器)利用以下函數的話,那么就能造成拒絕服務攻擊:java.util.zip.Adler32().update();java.util.zip.Deflater().setDictionary();java.util.zip.CRC32().update();java.util.zip.Deflater().deflate();java.util.zip.CheckedOutputStream().write();java.util.zip.CheckedInputStream().read();盡可能的減小方法和字段的作用域范圍.檢查包私有(package-private)成員是否應該是私有(private),保護(protected)成員是否應該是包私有或私有等等。盡可能不使用非終態(tài)公共靜態(tài)變量，因為沒有機制來檢測改變此變量的代碼是否有適當的權限。注意語言特性(例如整數溢出(IntegerOverflow))注意使用序列化,注意使用特權代碼將字段和方法定義到適當的可見性作用域日常維護發(fā)布檢測規(guī)范不能調用未經過確認的接口，不能想當然的認為某一接口是為了實現(xiàn)什么功能。新加業(yè)務都有良好和規(guī)范的日志,可以避免很多問題，關鍵業(yè)務的日志必須是可以監(jiān)控的。必須要考慮到服務重啟或者機器宕機給業(yè)務帶來的影響。（特別是任務服務器等）關鍵信息保密，關鍵保密信息不允許直接顯示在頁面上。例如用戶的證件號或者銀行信息等代碼合并的時候禁止覆蓋別人代碼。代碼合并時，不能只review有沖突的代碼，還需要reviewSVN自動成功合并的代碼，這是因為SVN能夠判斷同一行的修改沖突，但無法判斷不同行的修改是否在邏輯上存在沖突。這樣的問題潛在會造成嚴重后果。預發(fā)布一定需要開發(fā)人員自己確認發(fā)布內容，并且要跟蹤日志。開發(fā)完代碼后，開發(fā)人員交叉review開發(fā)人員要保證24小時開機對其他人員提供支持時，要全力配合（出現(xiàn)問題，共同承擔責任）修改別人代碼，必須要熟悉現(xiàn)有業(yè)務流程并通知測試，如果能找到相關開發(fā)負責人，最好和最近一次修改的開發(fā)工程師有效的溝通一下。修改別人代碼時，記得對修改的代碼添加注釋，包括時間，原因，作者。修改一個bug或者function的時候都可能造成新的bug，因此在修改之前首先要考慮的是對其他業(yè)務的影響。發(fā)現(xiàn)可