UAPV61-安全編碼規(guī)范

手支術(shù)重塑平臺用友

l=f------14=)0g—gr—^P-IQtw—lyonyou

yonyou

UAP統(tǒng)一應(yīng)用平臺

UAPV61-安全編碼規(guī)范

培訓(xùn)案例集

O

目錄/CONTENT

一術(shù)語表...........................................................1

二基本原貝！I.............................................................................................................................3

2.1輸入驗證...............................................................3

2.2輸出編碼...............................................................5

2.3身份驗證和密碼管理.....................................................5

2.4會話管理...............................................................7

2.5訪問控制...............................................................9

2.6加密規(guī)范..............................................................10

2.7錯誤處理和日志........................................................10

2.8數(shù)據(jù)保護..............................................................11

2.9通訊安全..............................................................12

2.10數(shù)據(jù)庫安全............................................................13

2.11文件管理..............................................................13

2.12通用編碼規(guī)范..........................................................14

三數(shù)據(jù)庫..........................................................15

3.1使用參數(shù)化的SQL..............................................................................................................15

3.1.1簡介.....................................................................15

3.1.2詳細描述.................................................................15

3.2通過"行”級別的訪問控制來使用數(shù)據(jù)庫.....................................16

3.2.1簡介.....................................................................16

3.2.2詳細描述......................................................................................................................17

3.3把數(shù)據(jù)庫中的數(shù)據(jù)作為不能完全相信的輸入對待............................18

3.3.1簡介.....................................................................18

3.3.2詳細描述.................................................................18

四WEB應(yīng)用開發(fā)...................................................19

4.1基本安全...............................................................19

4.1.1使用POST而不是GET.................................................................................................19

4.1.2假設(shè)瀏覽器已被控制.....................................................19

4.1.3假設(shè)瀏覽器是公開的.................................................................................................20

4.1.4使用JavaScript驗證是不安全的...............................................................................21

4.1.5不能依賴Request到達的順序..................................................................................21

4.1.6在惡意環(huán)境中保護瀏覽器.........................................................................................22

4.1.7創(chuàng)建一個默認的錯誤頁面..........................................................................................22

4.1.8使用通用的錯誤消息.....................................................23

4.2會話..................................................................23

4.2.1在每次認證后打開一個新的會話...........................................23

4.2.2保護會話中使用的cookie..........................................................................................24

4.2.3強制執(zhí)行一個會話最大空閑時間..............................................................................25

4.2.4強制執(zhí)行一個會話最大生存周期..............................................................................25

4.2.5允許用戶終止其會話.......................................................................................................25

4.2.6在會話終止時清空其數(shù)據(jù)...............................................................................................26

五代碼安全-JAVA系................................................27

5.1輸入驗證...............................................................27

5.1.1命令注入(CommandInjection)..........................................................................................27

5.1.2跨站腳本(Cross-SiteScripting).........................................................................................29

5.1.3拒絕月艮務(wù)(DenialofService)..............................................................................................32

5.1.4日志偽造(LogForging).....................................................................................................33

5.1.5缺少XML驗證(MissingXMLValidation).........................................................................35

5.1.6路徑操縱(PathManipulation)...........................................................................................35

5.1.7資源注入(ResourceInjection)...........................................................................................37

5.1.8SQL注入(SQLInjection).....................................................................................................38

5.1.9不安全的反射(UnsafeReflection)....................................................................................41

5.1.10整數(shù)溢出...........................................................42

5.2安全特性...............................................................43

5.2.1訪問控制:數(shù)據(jù)庫...................................................43

5.2.2不安全的隨機數(shù)................................................................................................................44

5.2.3加密...............................................................44

5.2.4密碼管理...........................................................45

5.2.5密碼管理:源代碼中的密碼...........................................45

5.2.6密碼管理:重定向中的密碼...........................................46

5.2.7密碼管理:弱加］密............................................................................................................47

5.2.8JAVA對象持有密碼的問題............................................48

5.2.9隱私侵犯...........................................................48

5.2.10固定的會話.........................................................50

5.3系統(tǒng)信息泄露...........................................................51

5.3.1系統(tǒng)信息泄露.......................................................51

5.3.2JSP中的HTML注釋..................................................52

六移動應(yīng)用........................................................52

6.1基本安全...............................................................52

6.1.1本地數(shù)據(jù)保護....................................................................................................................52

6.1.2密鑰安全...........................................................53

6.1.3android組件通信安全................................................53

6.1.4android組件通信安全................................................53

-術(shù)語表

跨站腳本攻擊通過"HTML注入"篡改網(wǎng)頁，插入惡意腳本。在用戶瀏覽網(wǎng)頁時，控制

（XSS）用戶瀏覽器的一種攻擊。XSS防御要點：控制html的輸入和輸出。

在一個網(wǎng)頁中隱藏著對另外一個網(wǎng)頁的非法請求調(diào)用。防御：1、驗證碼；

跨站點請求偽

2、RefererCheck：檢查來源是否合法；3、AntiCSRFToken:利用“不可

造（CSRF）

預(yù)測性原則"，對參數(shù)加密，或者使用隨機數(shù)做參數(shù)以POST力^是交。

基于視覺欺騙。通過透明層或特殊圖片遮擋方式讓客戶點擊觸發(fā)攻擊，或

點擊劫持者誘使用戶拖拽動作竊取數(shù)據(jù)，或者使用具它力式在用戶不知情的情況下

(Clickjacking)觸發(fā)某些交互動作。防御：禁止跨域訪問，禁用iframe等，與反XSS手段

一起使用。

敏感數(shù)據(jù)是指一旦泄露可能會對用戶或金融機構(gòu)造成損失的數(shù)據(jù),包括但

不限于：

a）用戶敏感數(shù)據(jù)，如用戶口令、密鑰等；

b）系統(tǒng)敏感數(shù)據(jù)，如系統(tǒng)的密鑰、關(guān)鍵的系統(tǒng)管理數(shù)據(jù)；

敏感數(shù)據(jù)

c）其他需要保密的敏感業(yè)務(wù)數(shù)據(jù)；

d）關(guān)鍵性的操作指令；

e）系統(tǒng)主要配置文件；

f）其他需要保密的數(shù)據(jù)。

密碼規(guī)范一組確保在應(yīng)用程序中密碼的操作被安全處理的控制。

危險字符任何字符或編碼表示的字符，可以影響應(yīng)用程序預(yù)期的操作，或者被解釋

/UAP培訓(xùn)案例系列一1—UAPV61-安全編碼規(guī)范,

為具有特殊的意義、預(yù)期用途以外的字符。這些字符可用于：修改現(xiàn)有代

碼或語句的結(jié)構(gòu)；插入新的非預(yù)期的代碼，?修改路徑；程序功能或程序?qū)?/p>

致非預(yù)期的結(jié)果；導(dǎo)致錯誤的條件；下游應(yīng)用程序或系統(tǒng)擁有上述任何效

果。

用等價的HTML實體取代ASCII字符的過程。比如：編碼過程將用HTML

HTML實體編碼等價"&止"取代小于號HTML實體在大多數(shù)的編譯器中是"無行動

的"，特別是在瀏覽器中，可以緩解某些客戶端攻擊。

保證信息是準確的、完整的和有效的，并且沒有被一個未授權(quán)的行為所修

完整性

改。

為減少一個漏洞的嚴重程度而采取的步驟。這些步驟可以包括：刪除一個

緩解

漏洞、使漏洞更難被利用、減少漏洞被利用后帶來的負面影響。

一個要求用戶處理多種不同種類憑據(jù)的身份驗證過程。通常，該過程基于

多因子身份驗

用戶擁有的信息（比如：智能卡\他們知道的信息（比如：個人識§!!碼1

證

或者他們自身的信息（比如：來自生物方面的數(shù)據(jù)1

輸出編碼一組解決使用編碼技術(shù)以確保應(yīng)用程序輸出的數(shù)據(jù)是安全的控制。

通過使用占位符，保持查詢語句和數(shù)據(jù)相分離。查詢語句結(jié)構(gòu)由占位符定

參數(shù)化查詢（預(yù)義，SQL語句發(fā)送給數(shù)據(jù)庫并做好準備，然后準備好的語句與參數(shù)值相結(jié)

處理語句）合。這樣就防止了查詢被更改，因為參數(shù)值與已編譯的語句相結(jié)合，而不

是SQL字符串。

通過使用刪除數(shù)據(jù)、字符替代、編碼或轉(zhuǎn)義字符，將潛在的有害數(shù)據(jù)變得

凈化數(shù)據(jù)

安全的處理過程。

連續(xù)身份驗證身份驗證數(shù)據(jù)在連續(xù)的網(wǎng)頁上被請求，而不是在一個單獨的網(wǎng)頁中一起被

/UAP培訓(xùn)案例系列一2—UAPV61-安全編碼規(guī)范,

要求。

會話管理一組有助于確保Web應(yīng)用程序以安全的模式處理HTTP會話的控制。

通常，一個信任邊界由您直接控制的系統(tǒng)部件組成。來自您直接控制系統(tǒng)

信任邊界以外的所有連接和數(shù)據(jù)，包括所有由其它各方管理的客戶端和系統(tǒng)，在允

許進一步的系統(tǒng)交互之前,應(yīng)當(dāng)被認為是不可信的，并在邊界被驗證。

漏洞一個導(dǎo)致系統(tǒng)易受攻擊謝員壞的脆弱點。

某種威脅存在利用一種資產(chǎn)或若干資產(chǎn)的脆弱性使這些資產(chǎn)損失或破壞

風(fēng)險risk

的可能性。

主要指為信息系統(tǒng)安全管理制定的行動方針、路線、工作方式、指導(dǎo)原則

安全策略/政策

securitypolicy或程序。

安全需求為使設(shè)備、信息、應(yīng)用及設(shè)施符合安全策略的要求而需要采取的保護類型

security

及保護等級。

requirement

指在計算機使用過程中，設(shè)置的過于簡單或非常容易被破解的口令或密

弱口令weak

password碼。

二基本原則

2.1輸入驗證

在可信系統(tǒng)（比如：服務(wù)器）上執(zhí)行所有的數(shù)據(jù)驗證。

識別所有的數(shù)據(jù)源，并將其分為可信的和不可信的。驗證所有來自不可信數(shù)據(jù)源（比如：

數(shù)據(jù)庫，文件流，等）的數(shù)據(jù)。

一7UAP培訓(xùn)案例系列一3—UAPV61-安全編碼規(guī)范L

應(yīng)當(dāng)為應(yīng)用程序應(yīng)提供一個集中的輸入驗證規(guī)則。

為所有輸入明確恰當(dāng)?shù)淖址?，比如：UTF-8。

在輸入驗證前，將數(shù)據(jù)按照常用字符集進行編碼(規(guī)范化X

丟棄任何沒有通過輸入驗證的數(shù)據(jù)。

在處理以前，驗證所有來自客戶端的數(shù)據(jù)，包括：所有參數(shù)、URL、HTTP頭信息(比如：

cookie名字和數(shù)據(jù)值X

3僉證在請求和響應(yīng)的報頭信息中只含有ASCII字符。

核實來自重定向輸入的數(shù)據(jù)(一個攻擊者可能向重定向的目標(biāo)直接提交惡意代碼，從而

避開應(yīng)用程序邏輯以及在重定向前執(zhí)行的任何驗證1

3僉證正確的數(shù)據(jù)類型。

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

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

盡可能采用“白名單”形式，驗證所有的輸入。

如果任何潛在的危險字符必須被作為輸入，請確保您執(zhí)行了額外的控制，比如：輸出編

碼、特定的安全API、以及在應(yīng)用程序中使用的原因。部分常見的危險字符包括：<>"，％()

如果您使用的標(biāo)準驗證規(guī)則無法驗證下面的輸入，那么它們需要被單獨驗證：驗證空字

節(jié)(%00)；驗證換行符(％0d,%0a,\r,\n)；驗證路徑替代字符"點-點-斜杠"(或,.\\如果

支持UTF-8擴展字符集編碼，驗證替代字符：％cO%ae%cO%ae/(使用規(guī)范化驗證雙編碼或

其他類型的編碼攻擊)。

/UAP培訓(xùn)案例系列—4—UAPV61-安全編碼規(guī)范,

2.2輸出編碼

在可信系統(tǒng)（比如：服務(wù)器）上執(zhí)行所有的編碼。

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

通過語義輸出編碼方式,對所有返回到客戶端的來自于應(yīng)用程序信任邊界之外的數(shù)據(jù)進

行編碼。HTML實體編碼是一個例子，但不是在所有的情況下都可用。

除非對目標(biāo)編譯器是安全的，否則請對所有字符進行編碼。

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

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

2.3身份驗證和密碼管理

除了那些特定設(shè)為“公開”的內(nèi)容以外，對所有的網(wǎng)頁和資源要求身份驗證。

所有的身份驗證過程必須在可信系統(tǒng)（比如：服務(wù)器）上執(zhí)行。

在任何可能的情況下，建立并使用標(biāo)準的、已通過測試的身份驗證服務(wù)。

為所有身份驗證控制使用一個集中實現(xiàn)的方法，其中包括利用庫文件請求外部身份驗證

服務(wù)。

將身份驗證邏輯從被請求的資源中隔離開，并使用重定向到或來自集中的身份驗證控制。

所有的身份驗證控制應(yīng)當(dāng)安全的處理未成功的身份驗證。

所有的管理和賬戶管理功能至少應(yīng)當(dāng)具有和主要身份驗證機制一樣的安全性。

如果您的應(yīng)用程序管理著憑證的存儲，那么應(yīng)當(dāng)保證只保存了通過使用強加密單向

salted哈希算法得到的密碼，并且只有應(yīng)用程序具有對保存密碼和密鑰的表/文件的寫權(quán)限

（如果可以避免的話，不要使用MD5算法X

密碼哈希必須在可信系統(tǒng)（比如：服務(wù)器）上執(zhí)行。

〃UAP培訓(xùn)案例系列一5—UAPV61-安全編碼規(guī)范為

只有當(dāng)所有的數(shù)據(jù)輸入以后，才進行身份驗證數(shù)據(jù)的驗證，特別是對連續(xù)身份驗證機制。

身份驗證的失敗提示信息應(yīng)當(dāng)避免過于明確。比如：可以使用“用戶名和/或密碼錯誤”,

而不要使用"用戶名錯誤"或者"密碼錯誤"。錯誤提示信息在顯示和源代碼中應(yīng)保持一致。

為涉及敏感信息或功能的外部系統(tǒng)連接使用身份驗證。

用于訪問應(yīng)用程序以外服務(wù)的身份驗證憑據(jù)信息應(yīng)當(dāng)加密，并存儲在一個可信系統(tǒng)（比

如：服務(wù)器）中受到保護的地方。源代碼不是一個安全的地方。

只使用HTTPPost請求傳輸身份驗證的憑據(jù)信息。

非臨時密碼只在加密連接中發(fā)送或作為加密的數(shù)據(jù)（比如，一封加密的郵件X通過郵

件重設(shè)臨時密碼可以是一個例外。

通過政策或規(guī)則加強密碼復(fù)雜度的要求（比如：要求使用字母、數(shù)字和/或特殊符號X

身份驗證的憑據(jù)信息應(yīng)當(dāng)足夠復(fù)雜以對抗在其所部署環(huán)境中的各種威脅攻擊。

通過政策和規(guī)則加強密碼長度要求。常用的是8個字符長度，但是16個字符長度更好，

或者考慮使用多單詞密碼短語。

輸入的密碼應(yīng)當(dāng)在用戶的屏幕上模糊顯示（比如：在Web表單中使用"password”輸入類

型1

當(dāng)連續(xù)多次登錄失敗后（比如：通常情況下是5次），應(yīng)強制鎖定賬戶。賬戶鎖定的時

間必須足夠長，以阻止暴力攻擊猜測登錄信息，但是不能長到允許執(zhí)行一次拒絕服務(wù)攻擊。

密碼重設(shè)和更改操作需要類似于賬戶創(chuàng)建和身份驗證的同樣控制等級。

密碼重設(shè)問題應(yīng)當(dāng)支持盡可能隨機的提問（比如："最喜爰的運動”是一個壞的問題，因

為籃球是最常見的答案X

如果使用基于郵件的重設(shè)，只將臨時鏈接或密碼發(fā)送到預(yù)先注冊的郵件地址。

臨時密碼和鏈接應(yīng)當(dāng)有一個短暫的有效期。

/UAP培訓(xùn)案例系列一6—UAPV61-安全編碼規(guī)范/一

當(dāng)再次使用臨時密碼時，強制修改臨時密碼。

當(dāng)密碼重新設(shè)置時，通知用戶。

阻止密碼重復(fù)使用。

密碼在被更改前應(yīng)當(dāng)至少使用了一天，以阻止密碼重用攻擊。（如果有阻止密碼重復(fù)使

用的政策）

根據(jù)政策或規(guī)則的要求，強制定期更改密碼。關(guān)鍵系統(tǒng)可能會要求更頻繁的更改。更改

時間周期必須進行明確。

為密碼填寫框禁用“記住密碼”功能。

用戶賬號的上一次使用信息（成功或失?。?yīng)當(dāng)在下一次成功登錄時向用戶報告。

在執(zhí)行關(guān)鍵操作以前，對用戶再次進行身份驗證。

為高度敏感或重要的交易賬戶使用多因子身份驗證機制。

如果使用了第三方身份驗證的代碼，仔細檢查代碼以保證其不會受到任何惡意代碼的影

響。

2.4會話管理

使用服務(wù)器或者框架的會話管理控制。應(yīng)用程序應(yīng)當(dāng)只識別有效的會話標(biāo)識符。

會話標(biāo)識符必須總是在一個可信系統(tǒng)（比如：服務(wù)器）上創(chuàng)建。

會話管理控制應(yīng)當(dāng)使用通過審查的算法以保證足夠的隨機會話標(biāo)識符。

為包含已驗證的會話標(biāo)識符的cookie設(shè)置域和路徑，以為站點設(shè)置一個恰當(dāng)?shù)南拗浦怠?/p>

注銷功能應(yīng)當(dāng)完全終止相關(guān)的會話或連接。

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

在平衡的風(fēng)險和業(yè)務(wù)功能需求的基礎(chǔ)上，設(shè)置一個盡量短的會話超時時間。通常情況下,

―一UAP培訓(xùn)案例系列一7—UAPV61-安全編碼規(guī)范/一

應(yīng)當(dāng)不超過幾個小時。

禁止連續(xù)的登錄并強制執(zhí)行周期性的會話終止，即使是活動的會話。特別是對于支持富

網(wǎng)絡(luò)連接或連接到關(guān)鍵系統(tǒng)的應(yīng)用程序。終止時機應(yīng)當(dāng)可以根據(jù)業(yè)務(wù)需求調(diào)整，并且用戶應(yīng)

當(dāng)收到足夠的通知已減少帶來的負面影響。

如果一個會話在登錄以前就建立，在成功登錄以后，關(guān)閉該會話并創(chuàng)建一個新的會話。

在任何重新身份驗證過程中建立一個新的會話標(biāo)識符。

不允許同一用戶ID的并發(fā)登錄。

不要在URL、錯誤信息或日志中暴露會話標(biāo)識符。會話標(biāo)識符應(yīng)當(dāng)只出現(xiàn)在HTTPcookie

頭信息中。比如，不要將會話標(biāo)識符以GET參數(shù)進行傳遞。

生成一個新的會話標(biāo)識符并周期性地使舊會話標(biāo)識符失效（這可以緩解那些原標(biāo)識符被

獲得的特定會話劫持情況X

在身份驗證的時候，如果連接從HTTP變?yōu)镠TTPS，則生成一個新的會話標(biāo)識符。在應(yīng)

用程序中，推薦持續(xù)使用HTTPS,而非在HTTP和HTTPS之間轉(zhuǎn)換。

為服務(wù)器端的操作執(zhí)行標(biāo)準的會話管理，比如，通過在每個會話中使用強隨機令牌或參

數(shù)來管理賬戶。該方法可以用來防止跨站點請求偽造攻擊。

通過在每個請求或每個會話中使用強隨機令牌或參數(shù)，為高度敏感或關(guān)鍵的操作提供標(biāo)

準的會話管理。

為在TLS連接上傳輸?shù)腸ookie設(shè)置"secure"屬性。

將cookie設(shè)置為HttpOnly屬性，除非在應(yīng)用程序中明確要求了客戶端腳本程序讀取或

者設(shè)置cookie的值。

/UAP培訓(xùn)案例系列一8—UAPV61-安全編碼規(guī)范,

2.5訪問控制

只使用可信系統(tǒng)對象（比如：服務(wù)器端會話對象）以做出訪問授權(quán)的決定。

安全的處理訪問控制失敗的操作。

如果應(yīng)用程序無法訪問其安全配置信息，則拒絕所有的訪問。

在每個請求中加強授權(quán)控制，包括：服務(wù)器端腳本產(chǎn)生的請求「includes"和來自象AJAX

和FLASH那樣的富客戶端技術(shù)的請求。

限制只有授權(quán)的用戶才能訪問文件或其他資源，包括那些應(yīng)用程序外部的直接控制。

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

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

限制只有授權(quán)的用戶才能訪問直接對象引用。

限制只有授權(quán)的用戶才能訪問服務(wù)。

限制只有授權(quán)的用戶才能訪問應(yīng)用程序數(shù)據(jù)。

限制通過使用訪問控制來訪問用戶、數(shù)據(jù)屬性和策略信息。

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

服務(wù)器端執(zhí)行的訪問控制規(guī)則和表示層實施的訪問控制規(guī)則必須匹配。

如果狀態(tài)數(shù)據(jù)必須存儲在客戶端，使用加密算法，并在服務(wù)器端檢查完整性以捕獲狀態(tài)

的改變。

強制應(yīng)用程序邏輯流程遵照業(yè)務(wù)規(guī)則。

如果長的身份驗證會話被允許，周期性的重新驗證用戶的身份，以確保他們的權(quán)限沒有

改變。如果發(fā)生改變，注銷該用戶，并強制他們重新執(zhí)行身份驗證。

應(yīng)用程序必須支持帳戶失效，并在帳戶停止使用時終止會話（比如：角色、職務(wù)狀況、

/UAP培訓(xùn)案例系列一9一UAPV61-安全編碼規(guī)范/一

業(yè)務(wù)處理的改變，等等X

服務(wù)帳戶，或連接到或來自外部系統(tǒng)的帳號，應(yīng)當(dāng)只有盡可能小的權(quán)限。

2.6加密規(guī)范

所有用于保護來自應(yīng)用程序用戶秘密信息的加密功能都必須在一個可信系統(tǒng)（比如：服

務(wù)器）上執(zhí)行。為了在客戶端和服務(wù)器之間保護秘密信息，在客戶端加密秘密信息也是必須

的。

保護主要秘密信息免受未授權(quán)的訪問。

安全的處理加密模塊失敗的操作。

為防范對隨機數(shù)據(jù)的猜測攻擊，應(yīng)當(dāng)使用加密模塊中已驗證的隨機數(shù)生成器生成所有的

隨機數(shù)、隨機文件名、隨機GUID和隨機字符串。

應(yīng)用程序使用的加密模塊應(yīng)當(dāng)遵從FIPS140-2或其他等同的標(biāo)準（請見：

/groups/STM/cmvp/validation.html\

2.7錯誤處理和日志

不要在錯誤響應(yīng)中泄露敏感信息，包括：系統(tǒng)的詳細信息、會話標(biāo)識符或者帳號信息。

使用錯誤處理以避免顯示調(diào)試或堆棧跟蹤信息。

使用通用的錯誤消息并使用定制的錯誤頁面。

應(yīng)用程序應(yīng)當(dāng)處理應(yīng)用程序錯誤，并且不依賴服務(wù)器配置。

在默認情況下，應(yīng)當(dāng)拒絕訪問與安全控制相關(guān)聯(lián)的錯誤處理邏輯。

所有的日志記錄控制應(yīng)當(dāng)在可信系統(tǒng)（比如：服務(wù)器）上執(zhí)行。

日志記錄控制應(yīng)當(dāng)支持記錄特定安全事件的成功或者失敗操作。

/UAP培訓(xùn)案例系列一10—UAPV61-安全編碼規(guī)范/一

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

確保日志記錄中包含的不可信數(shù)據(jù)，不會在查看界面或者軟件時以代碼的形式被執(zhí)行。

限制只有授權(quán)的個人才能訪問日志。

不要在日志中保存敏感信息，如密碼。

確保一個執(zhí)行日志查詢分析機制的存在。

記錄所有失敗的輸入驗證。

記錄所有的身份驗證嘗試，特別是失敗的驗證。

記錄所有失敗的訪問控制。

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

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

記錄所有的系統(tǒng)例外。

記錄所有的管理功能行為，包括對于安全配置設(shè)置的更改。

記錄加密模塊的錯誤。

使用加密哈希功能以驗證日志記錄的完整性。

2.8數(shù)據(jù)保護

保護所有存放在服務(wù)器上緩存的或臨時拷貝的敏感數(shù)據(jù)，以避免非授權(quán)的訪問，并在臨

時工作文件不再需要時被盡快清除。

即使在服務(wù)器端，任然要加密存儲的高度機密信息，比如，身份驗證的驗證數(shù)據(jù)?？偸?/p>

使用已經(jīng)被很好驗證過的算法。

保護服務(wù)器端的源代碼不被用戶下載。

不要在客戶端上以明文形式或其他非加密安全模式保存密碼、連接字符串或其他敏感信

/UAP培訓(xùn)案例系列一11—UAPV61-安全編碼規(guī)范/一

刪除用戶可訪問產(chǎn)品中的注釋，以防止泄露后臺系統(tǒng)或者其他敏感信息。

不要在HTTPGET請求參數(shù)中包含敏感信息。

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

禁止客戶端緩存網(wǎng)頁，因為可能包含敏感信息。"Cache-Control:no-store",可以和HTTP

報頭控制"Pragma:no-cache"一起使用，該控制不是非常有效，但是與HTTP/1.0向后兼容。

應(yīng)用程序應(yīng)當(dāng)支持，當(dāng)數(shù)據(jù)不再需要的時候，刪除敏感信息（比如：個人信息或者特定

財務(wù)數(shù)據(jù)1

為存儲在服務(wù)器中的敏感信息提供恰當(dāng)?shù)脑L問控制。這包括緩存的數(shù)據(jù)、臨時文件以及

只允許特定系統(tǒng)用戶訪問的數(shù)據(jù)。

2.9通訊安全

為所有敏感信息采用加密傳輸。其中應(yīng)該包括使用TLS對連接的保護，以及支持對敏感

文件或^基于HTTP連接的不連續(xù)加密。

沒有成功的TLS連接不應(yīng)當(dāng)后退成為一個不安全的連接。

為所有要求身份驗證的訪問內(nèi)容和所有其他的敏感信息提供TLS連接。

為包含敏感信息或功能、目連接到外部系統(tǒng)的連接使用TLS。

使用配置合理的單一標(biāo)準TLS連接。

為所有的連接明確字符編碼。

當(dāng)鏈接到外部站點時，過濾來自HTTPreferer中包含敏感信息的參數(shù)。

/UAP培訓(xùn)案例系列一12—UAPV61-安全編碼規(guī)范,

2.10數(shù)據(jù)庫安全

使用強類型的參數(shù)化查詢方法。

使用輸入驗證和輸出編碼，并確保處理了元字符。如果失敗，則不執(zhí)行數(shù)據(jù)庫命令。

確保變量是強類型的。

當(dāng)應(yīng)用程序訪問數(shù)據(jù)庫時，應(yīng)使用盡可能最低的權(quán)限。

為數(shù)據(jù)庫訪問使用安全憑證。

連接字符串不應(yīng)當(dāng)在應(yīng)用程序中硬編碼。連接字符串應(yīng)當(dāng)存儲在一個可信服務(wù)器的獨立

配置文件中，并且應(yīng)當(dāng)被加密。

盡可能地快速關(guān)閉數(shù)據(jù)庫連接。

2.11文件管理

不要把用戶提交的數(shù)據(jù)直接傳送給任何動態(tài)調(diào)用功能。

在允許上傳一個文檔以前進行身份驗證。

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

通過檢查文件報頭信息，驗證上傳文檔是否是所期待的類型。只驗證文件類型擴展是不

夠的。

不要把文件保存在與應(yīng)用程序相同的Web環(huán)境中。文件應(yīng)當(dāng)保存在內(nèi)容服務(wù)器或者數(shù)

據(jù)庫中。

防止或限制上傳任意可能被Web服務(wù)器解析的文件。

當(dāng)引用已有文件時，使用一個白名單記錄允許的文件名和類型。驗證傳遞的參數(shù)值，如

果與預(yù)期的值不匹配，則拒絕使用，或者使用默認的硬編碼文件值代替。

不要將用戶提交的數(shù)據(jù)傳遞到動態(tài)重定向中。如果必須允許使用，那么重定向應(yīng)當(dāng)只接

/UAP培訓(xùn)案例系列一13—UAPV61-安全編碼規(guī)范/一

受通過驗證的相對路徑URL。

不要傳遞目錄或文件路徑，使用預(yù)先設(shè)置路徑列表中的匹配索引值。

絕對不要將絕對文件路徑傳遞給客戶。

2.12通用編碼規(guī)范

使用校驗和或哈希值驗證編譯后的代碼、庫文件、可執(zhí)行文件和配置文件的完整性。

通過了解您使用的編程語言的底層表達式以及它們是如何進行數(shù)學(xué)計算，從而避免計算

錯誤。密切注意字節(jié)大小依賴、精確度、有無符合、截尾操作、轉(zhuǎn)換、字節(jié)之間的組合、

“not-a-number”計算、以及對于編程語言底層表達式如何處理非常大或者非常小的數(shù)。

不要將用戶提供的數(shù)據(jù)傳遞給任何動態(tài)運行的功能。

限制用戶生成新代碼或更改現(xiàn)有代碼。

確保產(chǎn)品中不要包含調(diào)試代碼。

產(chǎn)品中不要包含后門代碼。

保持一個干凈的空間。確保未使用的，臨時的以及備份的文件不能出現(xiàn)在產(chǎn)品中。

不能允許復(fù)活節(jié)彩蛋存在。隱藏的代碼不容易被測試到，很容易帶來安全漏洞。復(fù)活節(jié)

彩蛋會導(dǎo)致兩個問題。首先，其很少被測試或者安全檢測。第二，在安全弱點背后很難診斷

其動機。

/UAP培訓(xùn)案例系列—14—UAPV61-安全編碼規(guī)范,

三據(jù)庫

3.1使用參數(shù)化的SQL

3.1.1簡介

參數(shù)化的SQL請求是防止SQL注入的最好方法。

3.1.2詳細描述

導(dǎo)致SQL諸多漏洞的原因就是攻擊者可以改變SQL請求的內(nèi)容，使開發(fā)者認為本應(yīng)當(dāng)是

數(shù)據(jù)的值變成了SQL執(zhí)行命令的一部分。在構(gòu)造SQL請求時，開發(fā)者應(yīng)當(dāng)知道哪些應(yīng)該被

翻譯為數(shù)據(jù)而哪些應(yīng)該被翻譯為命令的一部分。如果正確的使用參數(shù)化的SQL語句，就可

以通過不允許數(shù)據(jù)指向改變的方法來防御幾乎所有的SQL注入攻擊。參數(shù)化的SQL語句通

常是由SQL字符構(gòu)造的，但是來自客戶的數(shù)據(jù)是需要與一些綁定參數(shù)組合在一起的。也就

是說，開發(fā)者使用這些綁定參數(shù)來準確的向數(shù)據(jù)庫指出哪些應(yīng)該被當(dāng)作數(shù)據(jù)，哪些應(yīng)該被當(dāng)

作命令。當(dāng)程序要執(zhí)行該語句的時候，它就會告知數(shù)據(jù)庫這些綁定參數(shù)的運行值，這樣的操

作避免了數(shù)據(jù)被認為是命令語句而被執(zhí)行的錯誤。

但是，參數(shù)化的SQL語句并不能完全的避免SQL注入攻擊的發(fā)生，看以下的例子：

這是一個javaweb應(yīng)用程序，讓用戶在數(shù)據(jù)庫中搜索一些信息，用戶可以指定要搜尋的

對象的名稱，并用以下代碼執(zhí)行這些查詢：

Stringitem=request.getParamater("item");

Stringq="SELECT*FROMrecordsWHEREitem="+item;

PreparedStatementstmt=conn.prepareStatement(q);

ResultSetresults=stmt.execute();

/UAP培訓(xùn)案例系列一15—UAPV61-安全編碼規(guī)范,

雖然本例程序使用了參數(shù)化的接口，但是它犯了一個很常見的錯誤：把用戶的輸入作為

prepareStatement()的參數(shù)傳入，如果允許用戶控制PreparedStatement的內(nèi)容，參數(shù)化SQL

提供的安全特性就會失去效果，很多SQL注入攻擊的關(guān)鍵字也會被包含在之前構(gòu)造的語句

中。

將前面的問題改正，合理的使用參數(shù)化SQL,具體代碼如下：

Stringitem=request.getParamater("item");

Stringq="SELECT*FROMrecordsWHEREitem=?";

PreparedStatementstmt=conn.prepareStatement(q);

stmt.setString(l,item);

ResultSetresults=stmt.execute();

你很可能經(jīng)常發(fā)現(xiàn)自己不能有效地使用參數(shù)化SQL語句。在更加復(fù)雜的情況會出

現(xiàn)要求用戶輸入影響SQL語句結(jié)構(gòu)的情況，譬如：要求在where子句里增加一個動態(tài)約束。

但是不要使用這些方法來把用戶的輸入連接為請求語句。用戶的輸入也可以以一種間接的方

法來影響命令的結(jié)構(gòu)，例如：構(gòu)造一組與可能包含在SQL語句中的元素對應(yīng)的字符串，在

構(gòu)造語句時來自用戶的輸入就可以得到本應(yīng)由程序控制的值。

3.2通過“行”級別的訪問控制來使用數(shù)據(jù)庫

3.2.1簡介

不要依賴應(yīng)用程序訪問控制能夠保護數(shù)據(jù)庫的數(shù)據(jù)，限制每個請求使用戶只能訪問他們

自己的數(shù)據(jù)。

/UAP培訓(xùn)案例系列一16—UAPV61-安全編碼規(guī)范,

3.2.2詳細描述

例如：在一個使用戶在線訪問記錄的javaweb程序中，在用戶認證后，與用戶ID有關(guān)

的所有信息都會被顯示在一個HTML表格里。但是如果代碼實現(xiàn)如下面所示，會導(dǎo)致用戶可

以查看任意用戶的信息。

StringrecID=request.getParamater("reclD");

Stringq="SELECT*FROMrecordsWHEREreclD=?";

PreparedStatementstmt=conn.prepareStatement(q);

stmt.setString(l,recID);

ResultSetresults=stmt.execute();

雖然程序在recID的值上正確地使用了參數(shù)化SQL語句來防止注入攻擊，這段代碼仍然

是不安全的。程序邏輯上是要實現(xiàn)recID的值是按照用戶ID從一個表中讀出的。但是攻擊者

可以提交一個任意值的recID,這樣的話如果recID值在表中存在就越過了訪問控制。

解決這種缺陷的方法是使用額外的邏輯來限制recID的值，使它是只有某個特定用戶能

夠提交的。但是一個聰明的攻擊者也可以利用定位一個在程序意料外的路徑或者提交無序的

請求來達到攻擊目的，更好的辦法是在數(shù)據(jù)庫語句本身進行訪問控制，這樣攻擊者就很難越

過這個限制。所以上面的代碼可以作以下的改進：

StringrecID=request.getParamater("reclD");

Stringq="SELECT*FROMrecordsWHEREreclD=?ANDusr=?";

PreparedStatementstmt=conn.prepareStatement(q);

stmt.setString(l,recID);

stmt.setString(2,ctx.getAuthenticatedUserName());

ResultSetresults=stmt.execute();

這段代碼對WHERE塊增加了一個約束，使返回的結(jié)果必須是與當(dāng)前認證的用戶關(guān)聯(lián)的。

/UAP培訓(xùn)案例系列一17—UAPV61-安全編碼規(guī)范,

3.3把數(shù)據(jù)庫中的數(shù)據(jù)作為不能完全相信的輸入對待

3.3.1簡介

確保從數(shù)據(jù)庫讀出的數(shù)據(jù)符合預(yù)期。

3.3.2詳細描述

相比不可信的外部輸入，系統(tǒng)會對數(shù)據(jù)庫給予一定的信任，所以對來自數(shù)據(jù)庫的數(shù)據(jù)也

需要進行驗證會顯得不可理解。但是建議還是要對來自數(shù)據(jù)庫的數(shù)據(jù)進行驗證，確保其格式

正確且能夠安全的使用，不要盲目的信賴數(shù)據(jù)庫。下面就是一些對數(shù)據(jù)庫數(shù)據(jù)進行簡單有效

驗證的例子。

1、要返回的單值數(shù)據(jù)只能在一行出現(xiàn)，如果存在多行的話很可能被攻擊者插入了注入

語句，而數(shù)據(jù)庫的單值約束很可能不起作用。

2、使用安全可信的內(nèi)容，而不要使用意料之外的可能具有惡意的信息（如常用系統(tǒng)或

者瀏覽器的關(guān)鍵字），如果出現(xiàn)了這樣的字符，就很可能說明攻擊者已經(jīng)成功地越過了輸入

驗證，正在試圖發(fā)動注入或者跨站腳本攻擊。即使你的輸入驗證機制很完美，攻擊者也可能

有其它的渠道從數(shù)據(jù)庫中得到數(shù)據(jù)。例如，你可能發(fā)現(xiàn)用戶的某些信息里含有〈script〉標(biāo)簽，

這很可能就是來自web的問題。

攻擊者可能在完全控制數(shù)據(jù)庫之前找到一些方法向數(shù)據(jù)庫寫入一些惡意數(shù)據(jù)。如果不加

以防范，就很可能真的導(dǎo)致數(shù)據(jù)庫被攻擊者完全控制。對你認為的程序安全的部分再加以驗

證絕對不是多余，最重要的一點是你的程序很可能并不是唯一能向數(shù)據(jù)庫寫入數(shù)據(jù)的程序。

所以，也就不能指望來自數(shù)據(jù)庫的信息能夠完全滿足你的需要。

/UAP培訓(xùn)案例系列—18—UAPV61-安全編碼規(guī)范,

見WEB應(yīng)用開發(fā)

4.1基本安全

4.1.1使用POST而不是GET

簡介

使用HTTPPOST方法來保證Request參數(shù)的安全。

詳細描述

使用Get方法傳遞的參數(shù)包含在URL里，它們可以被記錄在日志文件里（如apache的

accessjog）,通過HTTP頭的referrer發(fā)送到其它站點上,被存儲在瀏覽器歷史記錄里。而

Post方法幾乎在所有情況下都需要被使用很顯然，它需要驗證表單來確保賬戶信息的安全。

禁止使用Get方法可以防止很多跨站腳本攻擊漏洞，因為這樣可以使攻擊者無法向用戶發(fā)送

含有惡意Get參數(shù)的URL。

4.1.2假設(shè)瀏覽器已被控制

簡介

不管在客戶端是否經(jīng)過輸入驗證，在服務(wù)端仍要進行驗證。

詳細描述

Web程序總會接收到來自攻擊者的請求，對客戶習(xí)慣做出的任何假設(shè)都有可能會被用來

對你的程序發(fā)起攻擊。在驗證之前請不要相信來自客戶端的任何數(shù)據(jù)，包括那些不常被客戶

/UAP培訓(xùn)案例系列一19—UAPV61-安全編碼規(guī)范/一

修改的值（如cookies，隱藏的域X只使用客戶端的某些特性（如JavaScript代碼）來給合

法用戶提供反饋是不安全的。

開發(fā)者有很多方法來創(chuàng)建動態(tài)和交互的web頁面包括JavaScript,、Flash、JavaApplets,

ActiveX等，這些技術(shù)有一個共同的弱點：攻擊者可以繞過他們而直接與服務(wù)器通信。

攻擊之前，攻擊者會故意構(gòu)造有針對性的試探，并使用嗅探技術(shù)。由于這臺機器被他們

所控制，嗅探SSL通信完全沒有問題。這就意味著不可能存在一個“秘密的"隱藏域或者一個

用戶不知道具體含義的特殊表單。攻擊者完全了解瀏覽器端和服務(wù)器端的通信以及他們的運

作方式。攻擊者很容易偽造出能與原始交互界面幾乎相同HTTP請求的腳本，所以來自客戶

端的數(shù)據(jù)根本不能“默認具有某種屬性”，在客戶端進行的輸入驗證只是為了加強程序的可用

性，并不是為服務(wù)器接收的數(shù)據(jù)提供安全保證。

HTTP協(xié)議是無狀態(tài)的，開發(fā)者應(yīng)該想出方法來避免它的這種缺陷。兩種流行的解決方

法是使用cookie和使用隱藏表單。這兩種方法都有一些誘人的特性：對一般的用戶而言，

它們發(fā)送返回給服務(wù)器的數(shù)據(jù)在瀏覽器中是不可見的而且是不能直接操作的。當(dāng)然，如果是

惡意用戶，這兩種方法都會失效，因為惡意用戶可以輕易偽造cookie或者隱藏表單。但這

并不是說使用隱藏表單或者cookie是沒用的或者不安全的，而是說著必須對兩種方法接收

到的數(shù)據(jù)進行校驗。

4.1.3假設(shè)瀏覽器是公開的

簡介

要假設(shè)攻擊者可以了解學(xué)習(xí)你發(fā)送給他們的任何數(shù)據(jù)，即使這些信息沒有在瀏覽器中顯

/UAP培訓(xùn)案例系列—20—UAPV61-安全編碼規(guī)范,

詳細描述

攻擊者在進行攻擊之前會先了解你的程序運作方式，觀察程序返回的HTTP應(yīng)答包是最

容易的一種方法了，他們通過這種方式來尋找URL的格式，URL的參數(shù)，隱藏的表單，cookie

值等,還可以讀取頁面源碼、HTML中的注釋（包括錯誤頁面的HTML）,解析JavaScript,根

據(jù)命名習(xí)慣進行預(yù)測，還會使用搜索引擎發(fā)掘該程序其它用戶的信息。你不但不能相信來自

客戶端的任何數(shù)據(jù)，而且不能在應(yīng)答包中包含任何秘密信息。

4.1.4使用JavaScript驗證是不安全的

簡介

不要信任在客戶端進行的驗證。

詳細描述

攻擊者很容易就可以繞過你設(shè)定的那些請求頁面和瀏覽器，直接與你的應(yīng)用服務(wù)器通信。

這就意味著他們可以繞過在客戶端所做的任何設(shè)置，譬如JavaScript驗證邏輯。JavaScript可

以幫助合法的用戶對不正常的輸入信息進行檢測，但是不能確保服務(wù)器接收到數(shù)據(jù)的安全性。

所以，要在服務(wù)器端進行安全驗證。

4.1.5不能依賴Request到達的順序

簡介

攻擊者可以通過改變請求順序繞過有設(shè)計缺陷的系統(tǒng)的驗證。

/UAP培訓(xùn)案例系列一21—UAPV61-安全編碼規(guī)范/----

詳細描述

攻擊者可以隨意控制request到達的順序來適合自己的需要。例如，如果你的程序通過

不同頁面來搜集信息，在較早的表單里驗證了信息，而在修改信息的表單則沒有進行驗證,

那么攻擊者就可以利用后者來繞過你的輸入驗證。

4.1.6在惡意環(huán)境中保護瀏覽器

簡介

在惡意環(huán)境中保護