1、1,代碼安全介紹,2,第一章、序言,1.1 背景 1.2編碼中的安全問(wèn)題,據(jù)美國(guó)IDC 公司2006年對(duì)企業(yè)信息安全的調(diào)查和統(tǒng)計(jì)，70%以上的信息安全問(wèn)題是因?yàn)閼?yīng)用系統(tǒng)自身的安全問(wèn)題而遭到黑客的攻擊，而不是因?yàn)榫W(wǎng)絡(luò);同時(shí) NIST對(duì)近幾年的信息安全的事故的跟蹤調(diào)查顯示，幾乎92%的信息安全事故都與軟件相關(guān)。,3,在軟件的編碼階段，主要軟件安全問(wèn)題來(lái)源于如下幾個(gè)方面： 軟件自身的代碼缺陷 用戶惡意輸入 不期望的連接 在整個(gè)軟件系統(tǒng)中主要體現(xiàn)在如下幾個(gè)方面帶來(lái)安全隱患： 輸入驗(yàn)證與表示 API誤用 安全特征 時(shí)間與狀態(tài) 錯(cuò)誤處理 代碼質(zhì)量 封裝和環(huán)境等安全漏洞,第一章、序言,1.1 背景 1.2

2、編碼中的安全問(wèn)題,4,這些威脅主要是由于開(kāi)發(fā)人員缺乏安全編碼的意識(shí)和自身對(duì)軟件安全知識(shí)了解不足、所適用的對(duì)開(kāi)發(fā)語(yǔ)言和開(kāi)發(fā)技術(shù)的缺陷了解不足、沒(méi)有以黑客思維去看待軟件而導(dǎo)致的，表現(xiàn)為攻擊者可以利用開(kāi)發(fā)技術(shù)自身的漏洞、惡意輸入以及異常連接等問(wèn)題，對(duì)應(yīng)用軟件系統(tǒng)進(jìn)行攻擊，發(fā)現(xiàn)并利用軟件中存在的安全漏洞。,第一章、序言,1.1 背景 1.2 編碼中的安全問(wèn)題,5,目前軟件代碼中的風(fēng)險(xiǎn)非常多，根據(jù)CERT的統(tǒng)計(jì)，最近幾年都穩(wěn)定在5000多個(gè)。對(duì)這些安全漏洞的分類目前有很多種，本文主要采用了McGraw提出的分類方法。本文將軟件代碼中存在的安全漏洞分為8類，分別是：輸入驗(yàn)證與表示，API誤用，安全特征，時(shí)

3、間與狀態(tài)，錯(cuò)誤處理，代碼質(zhì)量、環(huán)境和封裝。,第二章、代碼安全問(wèn)題分類介紹,2.1 輸入驗(yàn)證與表示 2.2 API誤用 2.3安全特性 2.4時(shí)間與狀態(tài) 2.5錯(cuò)誤處理 2.6代碼質(zhì)量 2.7環(huán)境和封裝,6,輸入驗(yàn)證和表示問(wèn)題通常是由特殊字符、編碼和數(shù)字表示所引起的，這類安全問(wèn)題的發(fā)生是對(duì)輸入的信任所造成的。一些較大的安全問(wèn)題往往都是由于對(duì)輸入的信息過(guò)度信任造成的。,第二章、代碼安全問(wèn)題分類介紹,2.1 輸入驗(yàn)證與表示 2.2 API誤用 2.3安全特性 2.4時(shí)間與狀態(tài) 2.5錯(cuò)誤處理 2.6代碼質(zhì)量 2.7環(huán)境和封裝,7,API是調(diào)用者與被調(diào)用者之間的一個(gè)約定，大多數(shù)的API誤用是由于調(diào)用者

4、沒(méi)有理解約定的目的所造成的。 比如如果一個(gè)編碼人員繼承了SecureRandom，返回的卻是一個(gè)非隨機(jī)值，那么他就違背了約定。,第二章、代碼安全問(wèn)題分類介紹,2.1 輸入驗(yàn)證與表示 2.2 API誤用 2.3安全特性 2.4時(shí)間與狀態(tài) 2.5錯(cuò)誤處理 2.6代碼質(zhì)量 2.7環(huán)境和封裝,8,安全特征主要關(guān)系認(rèn)證，訪問(wèn)控制，機(jī)密性，密碼，權(quán)限管理等方面的內(nèi)容。,第二章、代碼安全問(wèn)題分類介紹,2.1 輸入驗(yàn)證與表示 2.2 API誤用 2.3安全特性 2.4時(shí)間與狀態(tài) 2.5錯(cuò)誤處理 2.6代碼質(zhì)量 2.7環(huán)境和封裝,9,分布式計(jì)算是與時(shí)間和狀態(tài)有關(guān)的。也就是說(shuō)，為了讓多個(gè)部件之間交互，需要狀態(tài)共享

5、，而這要花費(fèi)時(shí)間。 大多數(shù)程序員將他們的工作人格化。他們認(rèn)為控制器的一個(gè)線程會(huì)按照他們所想的方式來(lái)執(zhí)行整個(gè)程序。然而，現(xiàn)在的計(jì)算機(jī)能在多任務(wù)之間快速切換，采用多核、多CPU或者說(shuō)分布式系統(tǒng)，兩個(gè)事件甚至能在同一時(shí)間發(fā)生。這樣一 來(lái)，在程序員所想的程序執(zhí)行模式和實(shí)際發(fā)生的情況之間就會(huì)產(chǎn)生問(wèn)題。 這些問(wèn)題可能涉及到線程、進(jìn)程、時(shí)間和信息之間的非法交互。這些交互通過(guò)共享的狀態(tài)產(chǎn)生：如信號(hào)量、變量、文件系統(tǒng)以及任何能夠存儲(chǔ)信息的東西。,第二章、代碼安全問(wèn)題分類介紹,2.1 輸入驗(yàn)證與表示 2.2 API誤用 2.3安全特性 2.4時(shí)間與狀態(tài) 2.5錯(cuò)誤處理 2.6代碼質(zhì)量 2.7環(huán)境和封裝,10,錯(cuò)誤

6、和錯(cuò)誤處理代表了一類API。與錯(cuò)誤處理有關(guān)的錯(cuò)誤是很常見(jiàn)的。與API誤用相比，和錯(cuò)誤處理相關(guān)的安全漏洞一般是兩種方式造成的： 第一種是：根本忘記處理錯(cuò)誤或者只是簡(jiǎn)單的處理，并沒(méi)有徹底解決； 第二種則是：程序?qū)赡艿墓粽咝孤读诉^(guò)多的信息或者涉及面太廣沒(méi)有人愿意去處理這些問(wèn)題。,第二章、代碼安全問(wèn)題分類介紹,2.1 輸入驗(yàn)證與表示 2.2 API誤用 2.3安全特性 2.4時(shí)間與狀態(tài) 2.5錯(cuò)誤處理 2.6代碼質(zhì)量 2.7環(huán)境和封裝,11,低劣的代碼質(zhì)量會(huì)導(dǎo)致不可預(yù)測(cè)的行為。從用戶的角度來(lái)看，這通常會(huì)表現(xiàn)為低劣的可用性。對(duì)于攻擊者而言，低劣的代碼使他們可以以意想不到的方式威脅系統(tǒng)。,第二章、代碼

7、安全問(wèn)題分類介紹,2.1 輸入驗(yàn)證與表示 2.2 API誤用 2.3安全特性 2.4時(shí)間與狀態(tài) 2.5錯(cuò)誤處理 2.6代碼質(zhì)量 2.7環(huán)境和封裝,12,封裝就是劃定強(qiáng)力的分界線。在 web瀏覽器中，這就意味著你的代碼模塊不能被其他代碼模塊濫用。在服務(wù)端，這意味著要區(qū)分校驗(yàn)過(guò)的數(shù)據(jù)和未經(jīng)校驗(yàn)的數(shù)據(jù)，區(qū)分不同用戶的數(shù)據(jù)，或者區(qū)分用戶能看到的和不能看到的數(shù)據(jù)。,第二章、代碼安全問(wèn)題分類介紹,2.1 輸入驗(yàn)證與表示 2.2 API誤用 2.3安全特性 2.4時(shí)間與狀態(tài) 2.5錯(cuò)誤處理 2.6代碼質(zhì)量 2.7環(huán)境和封裝,13,把輸入驗(yàn)證作為軟件框架的一部分。 集中處理輸入驗(yàn)證框架帶來(lái)的好處如下： 1.

8、所有的輸入使用一致的輸入驗(yàn)證： 如果每個(gè)模塊各自獨(dú)立實(shí)現(xiàn)自己的輸入驗(yàn)證，將會(huì)很難建立一個(gè)統(tǒng)一的輸入驗(yàn)證策略。 2. 有效降低工作量： 輸入驗(yàn)證比較靈活，分別實(shí)現(xiàn)輸入驗(yàn)證會(huì)導(dǎo)致其工作量成倍的增加。 3. 對(duì)輸入驗(yàn)證進(jìn)行統(tǒng)一的升級(jí)和修改： 這樣如果在輸入驗(yàn)證邏輯里發(fā)現(xiàn)問(wèn)題時(shí)就可以比較方便的修改。 4. 失敗控制： 如果一個(gè)集中處理輸入驗(yàn)證框架收到它不知道如何處理的輸入，很容易就拒絕掉該輸入，如果沒(méi)有采取集中輸入驗(yàn)證，開(kāi)發(fā)者很容易忘記進(jìn)行輸入驗(yàn)證。,第三章、安全建議輸入處理,3.1集中輸入驗(yàn)證 3.2保證所有輸入信息被驗(yàn)證過(guò) 3.3建立可信邊界 3.4檢測(cè)輸入長(zhǎng)度 3.5拒絕驗(yàn)證失敗數(shù)據(jù) 3.6驗(yàn)證

9、HTTP請(qǐng)求中的所有組成 3.7對(duì)來(lái)自命令行、環(huán)境以及配置文件的輸入進(jìn)行校驗(yàn) 3.8控制寫入日志信息 3.9輸入驗(yàn)證時(shí)使用最強(qiáng)的形式 3.10防范元字符攻擊,14,確保在輸入驗(yàn)證之前，新輸入的數(shù)據(jù)不要被添加到程序中（輸入的數(shù)據(jù)不能進(jìn)入程序代碼中被執(zhí)行）。也就是說(shuō)，程序默認(rèn)情況下就要對(duì)輸入的信息進(jìn)行驗(yàn)證，不能通過(guò)驗(yàn)證的數(shù)據(jù)將會(huì)被拒絕。這樣的話，開(kāi)發(fā)者就不會(huì)忘記進(jìn)行輸入驗(yàn)證了。,第三章、安全建議輸入處理,3.1集中輸入驗(yàn)證 3.2保證所有輸入信息被驗(yàn)證過(guò) 3.3建立可信邊界 3.4檢測(cè)輸入長(zhǎng)度 3.5拒絕驗(yàn)證失敗數(shù)據(jù) 3.6驗(yàn)證HTTP請(qǐng)求中的所有組成 3.7對(duì)來(lái)自命令行、環(huán)境以及配置文件的輸入進(jìn)

10、行校驗(yàn) 3.8控制寫入日志信息 3.9輸入驗(yàn)證時(shí)使用最強(qiáng)的形式 3.10防范元字符攻擊,15,將可信和不可信數(shù)據(jù)分別儲(chǔ)存來(lái)保證輸入驗(yàn)證總是被執(zhí)行。 可信邊界可以被認(rèn)為是在程序中劃定的一條分隔線，一邊的數(shù)據(jù)是不可信的而另一邊則是可信的。當(dāng)數(shù)據(jù)要從不可信的一側(cè)到可信一側(cè)的時(shí)候，需要使用驗(yàn)證邏輯進(jìn)行判斷。 需要在程序中定義清晰的可信邊界。在一些代碼中使用的保存可信數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)，不能被用來(lái)在其它代碼中存儲(chǔ)不可信數(shù)據(jù)。使數(shù)據(jù)穿越可信邊界的次數(shù)降到最低。 當(dāng)程序混淆了可信和不可信數(shù)據(jù)的界限時(shí)會(huì)導(dǎo)致安全邊界發(fā)生問(wèn)題，最容易導(dǎo)致這種錯(cuò)誤的情況是把可信和不可信數(shù)據(jù)混合在一個(gè)數(shù)據(jù)結(jié)構(gòu)里。這里舉了一個(gè)例子：,第三

11、章、安全建議輸入處理,3.1集中輸入驗(yàn)證 3.2保證所有輸入信息被驗(yàn)證過(guò) 3.3建立可信邊界 3.4檢測(cè)輸入長(zhǎng)度 3.5拒絕驗(yàn)證失敗數(shù)據(jù) 3.6驗(yàn)證HTTP請(qǐng)求中的所有組成 3.7對(duì)來(lái)自命令行、環(huán)境以及配置文件的輸入進(jìn)行校驗(yàn) 3.8控制寫入日志信息 3.9輸入驗(yàn)證時(shí)使用最強(qiáng)的形式 3.10防范元字符攻擊,16,驗(yàn)證的時(shí)候應(yīng)該驗(yàn)證允許輸入的最小和最大長(zhǎng)度 如果對(duì)最大輸入長(zhǎng)度進(jìn)行限制，攻擊者就很難對(duì)系統(tǒng)的其它弱點(diǎn)進(jìn)行攻擊。譬如，對(duì)于一個(gè)很可能被用來(lái)進(jìn)行跨站腳本攻擊的輸入域，如果攻擊者可以輸入任意長(zhǎng)度的腳本，那么這顯然要比限制輸入長(zhǎng)度更加危險(xiǎn)。而對(duì)最短長(zhǎng)度的檢測(cè)可以使攻擊者無(wú)法忽略強(qiáng)制要求輸入的域，

12、同時(shí)也無(wú)法輸入與預(yù)期不符的數(shù)據(jù)。 對(duì)輸入長(zhǎng)度的檢測(cè)是輸入驗(yàn)證最基本的要求，但是，好的輸入驗(yàn)證并不是僅僅檢測(cè)輸入長(zhǎng)度，還可以根據(jù)被驗(yàn)證程序的上下文進(jìn)行更深入的檢測(cè)。如果程序需要驗(yàn)證一個(gè)輸入域，驗(yàn)證邏輯對(duì)該域的合法值限定得越詳細(xì)，驗(yàn)證邏輯就能越好地工作。,第三章、安全建議輸入處理,3.1集中輸入驗(yàn)證 3.2保證所有輸入信息被驗(yàn)證過(guò) 3.3建立可信邊界 3.4檢測(cè)輸入長(zhǎng)度 3.5拒絕驗(yàn)證失敗數(shù)據(jù) 3.6驗(yàn)證HTTP請(qǐng)求中的所有組成 3.7對(duì)來(lái)自命令行、環(huán)境以及配置文件的輸入進(jìn)行校驗(yàn) 3.8控制寫入日志信息 3.9輸入驗(yàn)證時(shí)使用最強(qiáng)的形式 3.10防范元字符攻擊,17,拒絕驗(yàn)證失敗的數(shù)據(jù)，不試圖對(duì)其進(jìn)

13、行修復(fù) 通過(guò)設(shè)置默認(rèn)值來(lái)保存一個(gè)丟失的輸入，處理密碼域時(shí)自動(dòng)剪裁掉超過(guò)最大長(zhǎng)度的輸入，替換掉在輸入框輸入的 JavaScript字符等行為是很危險(xiǎn)的，不要試圖修復(fù)一個(gè)未能通過(guò)輸入驗(yàn)證的請(qǐng)求，直接拒絕掉，這樣才是安全的。 輸入驗(yàn)證本身就很復(fù)雜，如果和自動(dòng)錯(cuò)誤恢復(fù)的代碼混合在一起的話，將會(huì)造成更大的復(fù)雜性，自動(dòng)錯(cuò)誤恢復(fù)代碼很可能改變請(qǐng)求的含義或者截?cái)囹?yàn)證邏輯。 如果我們能夠引導(dǎo)用戶，使他們提交的請(qǐng)求能夠通過(guò)輸入驗(yàn)證，就能比專注于自動(dòng)錯(cuò)誤恢復(fù)代碼有效得多。,第三章、安全建議輸入處理,3.1集中輸入驗(yàn)證 3.2保證所有輸入信息被驗(yàn)證過(guò) 3.3建立可信邊界 3.4檢測(cè)輸入長(zhǎng)度 3.5拒絕驗(yàn)證失敗數(shù)據(jù) 3

14、.6驗(yàn)證HTTP請(qǐng)求中的所有組成 3.7對(duì)來(lái)自命令行、環(huán)境以及配置文件的輸入進(jìn)行校驗(yàn) 3.8控制寫入日志信息 3.9輸入驗(yàn)證時(shí)使用最強(qiáng)的形式 3.10防范元字符攻擊,18,驗(yàn)證來(lái)自HTTP請(qǐng)求中的所有數(shù)據(jù)，惡意數(shù)據(jù)可以從表單域，URL參數(shù)，cookie，http頭以及 URL自身傳入。 無(wú)論一個(gè) HTTP請(qǐng)求看起來(lái)多么的“正常”，都應(yīng)該對(duì)它進(jìn)行完整的檢查。 攻擊者可以在你提供給他們的 web頁(yè)面里輸入任何內(nèi)容，他們可以完全脫離瀏覽器和瀏覽器的一切驗(yàn)證，修改 Cookie、隱藏區(qū)域、 name與 value的對(duì)應(yīng)關(guān)系，他們可以為了“錯(cuò)誤”的目的在“錯(cuò)誤”的時(shí)間按“錯(cuò)誤”的順序提交 URL請(qǐng)求。,

15、第三章、安全建議輸入處理,3.1集中輸入驗(yàn)證 3.2保證所有輸入信息被驗(yàn)證過(guò) 3.3建立可信邊界 3.4檢測(cè)輸入長(zhǎng)度 3.5拒絕驗(yàn)證失敗數(shù)據(jù) 3.6驗(yàn)證HTTP請(qǐng)求中的所有組成 3.7對(duì)來(lái)自命令行、環(huán)境以及配置文件的輸入進(jìn)行校驗(yàn) 3.8控制寫入日志信息 3.9輸入驗(yàn)證時(shí)使用最強(qiáng)的形式 3.10防范元字符攻擊,19,不要使你的軟件的安全性依賴于配置和維護(hù)它的人 對(duì)來(lái)自命令行、系統(tǒng)屬性，環(huán)境變量以及配置文件的輸入都需要進(jìn)行校驗(yàn)來(lái)保證它們是一致的和健全的。如果攻擊者對(duì)系統(tǒng)的屬性進(jìn)行修改，可以通過(guò)命令行，環(huán)境以及配置文件來(lái)威脅軟件系統(tǒng)，這里要求軟件開(kāi)發(fā)者不要相信來(lái)自命令行、環(huán)境以及配置文件的輸入。,第

16、三章、安全建議輸入處理,3.1集中輸入驗(yàn)證 3.2保證所有輸入信息被驗(yàn)證過(guò) 3.3建立可信邊界 3.4檢測(cè)輸入長(zhǎng)度 3.5拒絕驗(yàn)證失敗數(shù)據(jù) 3.6驗(yàn)證HTTP請(qǐng)求中的所有組成 3.7對(duì)來(lái)自命令行、環(huán)境以及配置文件的輸入進(jìn)行校驗(yàn) 3.8控制寫入日志信息 3.9輸入驗(yàn)證時(shí)使用最強(qiáng)的形式 3.10防范元字符攻擊,20,不要允許攻擊者能夠?qū)懭我獾臄?shù)據(jù)到日志里 正確的和長(zhǎng)期的記錄對(duì)于在已部署的軟件系統(tǒng)中尋找缺陷和發(fā)現(xiàn)安全弱點(diǎn)是很重要的。我們可以手工或者自動(dòng)的分析日志來(lái)查找重要的事件、一段時(shí)間內(nèi)的趨勢(shì)，它是檢測(cè)系統(tǒng)和用戶行為的寶貴資源。 由于日志的價(jià)值，它也成為了攻擊者的目標(biāo)。如果攻擊者可以控制寫進(jìn)日志文

17、件的信息，他們就可以在輸入中混入偽造的日志條目來(lái)偽造系統(tǒng)事件，更嚴(yán)重的是，如果負(fù)責(zé)進(jìn)行日志分析的代碼存在漏洞，特定的有惡意的輸入很可能觸發(fā)該漏洞，并引發(fā)更加嚴(yán)重的危害。,第三章、安全建議輸入處理,3.1集中輸入驗(yàn)證 3.2保證所有輸入信息被驗(yàn)證過(guò) 3.3建立可信邊界 3.4檢測(cè)輸入長(zhǎng)度 3.5拒絕驗(yàn)證失敗數(shù)據(jù) 3.6驗(yàn)證HTTP請(qǐng)求中的所有組成 3.7對(duì)來(lái)自命令行、環(huán)境以及配置文件的輸入進(jìn)行校驗(yàn) 3.8控制寫入日志信息 3.9輸入驗(yàn)證時(shí)使用最強(qiáng)的形式 3.10防范元字符攻擊,21,在指定的環(huán)境中使用最強(qiáng)的輸入驗(yàn)證方式。按照間接選擇，白名單以及黑名單的順序進(jìn)行驗(yàn)證。 有很多方法來(lái)校驗(yàn)一段數(shù)據(jù)。根

18、據(jù)安全的觀點(diǎn)，輸入驗(yàn)證的過(guò)程需要非常清晰，但是在一些復(fù)雜的環(huán)境中，那些“最安全的輸入驗(yàn)證”并不一定切實(shí)可行。所以應(yīng)該在特定的場(chǎng)景中選擇一個(gè)相對(duì)“最強(qiáng)”的輸入驗(yàn)證的形式，一方面滿 足需求，另一方面防止欺詐。 不要為了平衡輸入驗(yàn)證的安全性與可用性而困惑。正常的輸入驗(yàn)證過(guò)程只需要捕獲通用的錯(cuò)誤并提供易于理解的輸入驗(yàn)證反饋。而以安全為目標(biāo)的輸入驗(yàn)證過(guò)程則只針對(duì)那些不正常的輸入。,第三章、安全建議輸入處理,3.1集中輸入驗(yàn)證 3.2保證所有輸入信息被驗(yàn)證過(guò) 3.3建立可信邊界 3.4檢測(cè)輸入長(zhǎng)度 3.5拒絕驗(yàn)證失敗數(shù)據(jù) 3.6驗(yàn)證HTTP請(qǐng)求中的所有組成 3.7對(duì)來(lái)自命令行、環(huán)境以及配置文件的輸入進(jìn)行校

19、驗(yàn) 3.8控制寫入日志信息 3.9輸入驗(yàn)證時(shí)使用最強(qiáng)的形式 3.10防范元字符攻擊,22,不允許攻擊者控制發(fā)送給文件系統(tǒng)、瀏覽器、數(shù)據(jù)庫(kù)或者其它子系統(tǒng)的命令。 所有類似腳本語(yǔ)言以及標(biāo)記語(yǔ)言之類的強(qiáng)調(diào)易用性與交互性的技術(shù)都有一個(gè)共性：其可以接受可變的控制結(jié)構(gòu)與數(shù)據(jù)。例如，SQL查詢： select * from emp where name = Brian 由“select”, “from”, “where”, and “=” with the data “*”, “emp”, “name” 以及 Brian這些關(guān)鍵字組合?？刂平Y(jié)構(gòu)與數(shù)據(jù)的組合可以保證這些語(yǔ)言易于被使用。,第三章、安全建議輸入處

20、理,3.1集中輸入驗(yàn)證 3.2保證所有輸入信息被驗(yàn)證過(guò) 3.3建立可信邊界 3.4檢測(cè)輸入長(zhǎng)度 3.5拒絕驗(yàn)證失敗數(shù)據(jù) 3.6驗(yàn)證HTTP請(qǐng)求中的所有組成 3.7對(duì)來(lái)自命令行、環(huán)境以及配置文件的輸入進(jìn)行校驗(yàn) 3.8控制寫入日志信息 3.9輸入驗(yàn)證時(shí)使用最強(qiáng)的形式 3.10防范元字符攻擊,23,開(kāi)發(fā)安全的 web應(yīng)用程序是很有挑戰(zhàn)性的，主要原因如下： 1由于用戶可以很容易的訪問(wèn)應(yīng)用程序，惡意用戶也可以這樣做。 2 HTTP不是為應(yīng)用設(shè)計(jì)的，自然更不是為安全的應(yīng)用設(shè)計(jì)的。HTTP的安全問(wèn)題與標(biāo)準(zhǔn) C庫(kù)中的字符串函數(shù)帶來(lái)的緩沖區(qū)溢出問(wèn)題一樣麻煩。程序員需要通過(guò)自己的方法來(lái)確認(rèn)應(yīng)用是安全的。 3應(yīng)用不

21、只需要防護(hù)惡意用戶，還需要幫助正常用戶防御惡意用戶。換句話說(shuō)，惡意用戶希望通過(guò)應(yīng)用作為其攻擊的跳板。,第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.2會(huì)話,24,使用 HTTP POST方法來(lái)保證 Request參數(shù)的安全。 使用 Get方法傳遞的參數(shù)包含在 URL里，所以他們理所當(dāng)然的可以被記錄在日志文件里，通過(guò) HTTP頭的 referrer發(fā)送到其它站點(diǎn)上，被存儲(chǔ)在瀏覽器歷史記錄里。而 Post方法幾乎在所有情況下都需要被使用，很顯然，它需要驗(yàn)證表單來(lái)確保賬戶信息的安全。 禁止使用 Get方法可以防止很多跨站腳本攻擊漏洞，因?yàn)檫@樣可以使攻擊者無(wú)法向用戶發(fā)送含有惡意Get參數(shù)的URL。,

22、第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.1.1使用 POST而不是 GET 4.1.2使用 SSL 4.1.3假設(shè)瀏覽器被控制 4.1.4假設(shè)瀏覽器是公開(kāi) 4.1.5使用JavaScript是不安全的 4.1.6不能依賴Request到達(dá)的順序 4.1.7在惡意環(huán)境中保護(hù)瀏覽器 4.1.8創(chuàng)建一個(gè)默認(rèn)的錯(cuò)誤頁(yè)面 4.1.9使用通用錯(cuò)誤消息 4.2會(huì)話,25,SSL對(duì)所有涉及保密信息的通信都使用SSL，拒絕不使用SSL的請(qǐng)求。 SSL確實(shí)能夠帶來(lái)一定的好處。如果合理的使用，它就能對(duì)嗅探攻擊和中間人攻擊做出有效的防御，同時(shí)它還可以為主機(jī)和客戶機(jī)提供可信的驗(yàn)證，但是大部分的終端用戶并不使用主

23、機(jī)驗(yàn)證，也很少有站點(diǎn)使用SSL來(lái)驗(yàn)證終端用戶。 SSL并不應(yīng)該是可選的方案：一個(gè)安全的程序不應(yīng)該在使用443端口（SSL通信端口）的同時(shí)也接受80端口（一般的HTTP服務(wù)端口）請(qǐng)求，不應(yīng)允許用戶選擇安全級(jí)別。,第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.1.1使用 POST而不是 GET 4.1.2使用 SSL 4.1.3假設(shè)瀏覽器被控制 4.1.4假設(shè)瀏覽器是公開(kāi) 4.1.5使用JavaScript是不安全的 4.1.6不能依賴Request到達(dá)的順序 4.1.7在惡意環(huán)境中保護(hù)瀏覽器 4.1.8創(chuàng)建一個(gè)默認(rèn)的錯(cuò)誤頁(yè)面 4.1.9使用通用錯(cuò)誤消息 4.2會(huì)話,26,不管在客戶端是否經(jīng)過(guò)輸

24、入驗(yàn)證，在服務(wù)端仍要進(jìn)行驗(yàn)證。 Web程序總會(huì)接收到來(lái)自攻擊者的請(qǐng)求，對(duì)客戶習(xí)慣做出的任何假設(shè)都有可能會(huì)被用來(lái)對(duì)你的程序發(fā)起攻擊。在驗(yàn)證之前請(qǐng)不要相信來(lái)自客戶端的任何數(shù)據(jù)，包括那些不常被客戶修改的值（如cookies，隱藏的域）。只使用客戶端的某些特性（如JavaScript代碼）來(lái)給合法用戶提供反饋是不安全的。 開(kāi)發(fā)者有很多方法來(lái)創(chuàng)建動(dòng)態(tài)和交互的web頁(yè)面，包括JavaScript,、Flash、Java Applets、ActiveX等，這些技術(shù)有一個(gè)共同的弱點(diǎn)：攻擊者可以繞過(guò)他們而直接與服務(wù)器通信。,第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.1.1使用 POST而不是 GET 4.

25、1.2使用 SSL 4.1.3假設(shè)瀏覽器被控制 4.1.4假設(shè)瀏覽器是公開(kāi) 4.1.5使用JavaScript是不安全的 4.1.6不能依賴Request到達(dá)的順序 4.1.7在惡意環(huán)境中保護(hù)瀏覽器 4.1.8創(chuàng)建一個(gè)默認(rèn)的錯(cuò)誤頁(yè)面 4.1.9使用通用錯(cuò)誤消息 4.2會(huì)話,27,要假設(shè)攻擊者可以了解學(xué)習(xí)你發(fā)送給他們的任何數(shù)據(jù)，即使這些信息沒(méi)有在瀏覽器中顯示。 攻擊者在進(jìn)行攻擊之前會(huì)先了解你的程序運(yùn)作方式，觀察程序返回的HTTP應(yīng)答包是最容易的一種方法了，他們通過(guò)這種方式來(lái)尋找URL的格式，URL的參數(shù)，隱藏的表單，cookie值等，還可以讀取頁(yè)面源碼、HTML中的注釋（包括錯(cuò)誤頁(yè)面的HTML）

26、，解析JavaScript，根據(jù)命名習(xí)慣進(jìn)行預(yù)測(cè)，還會(huì)使用搜索引擎發(fā)掘該程序其它用戶的信息。 你不但不能相信來(lái)自客戶端的任何數(shù)據(jù)，而且不能在應(yīng)答包中包含任何秘密信息。,第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.1.1使用 POST而不是 GET 4.1.2使用 SSL 4.1.3假設(shè)瀏覽器被控制 4.1.4假設(shè)瀏覽器是公開(kāi) 4.1.5使用JavaScript是不安全的 4.1.6不能依賴Request到達(dá)的順序 4.1.7在惡意環(huán)境中保護(hù)瀏覽器 4.1.8創(chuàng)建一個(gè)默認(rèn)的錯(cuò)誤頁(yè)面 4.1.9使用通用錯(cuò)誤消息 4.2會(huì)話,28,不要信任在客戶端進(jìn)行的驗(yàn)證 攻擊者很容易就可以繞過(guò)你設(shè)定的那些請(qǐng)

27、求頁(yè)面和瀏覽器，直接與你的應(yīng)用服務(wù)器通信。這就意味著他們可以繞過(guò)在客戶端所做的任何設(shè)置，譬如 JavaScript驗(yàn)證邏輯。JavaScript可以幫助合法的用戶對(duì)不正常的輸入信息進(jìn)行檢測(cè)，但是不能確保服務(wù)器接收到數(shù)據(jù)的安全性。所以，要在服務(wù)器端進(jìn)行安全驗(yàn)證。,第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.1.1使用 POST而不是 GET 4.1.2使用 SSL 4.1.3假設(shè)瀏覽器被控制 4.1.4假設(shè)瀏覽器是公開(kāi) 4.1.5使用JavaScript是不安全的 4.1.6不能依賴Request到達(dá)的順序 4.1.7在惡意環(huán)境中保護(hù)瀏覽器 4.1.8創(chuàng)建一個(gè)默認(rèn)的錯(cuò)誤頁(yè)面 4.1.9使用通

28、用錯(cuò)誤消息 4.2會(huì)話,29,攻擊者可以通過(guò)改變請(qǐng)求順序繞過(guò)有設(shè)計(jì)缺陷的系統(tǒng)的驗(yàn)證 攻擊者可以隨意控制 request到達(dá)的順序來(lái)適合自己的需要。例如，如果你的程序通過(guò)不同頁(yè)面來(lái)搜集信息，在較早的表單里驗(yàn)證了信息，而在修改信息的表單則沒(méi)有進(jìn)行驗(yàn)證，那么攻擊者就可以利用后者來(lái)繞過(guò)你的輸入驗(yàn)證。,第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.1.1使用 POST而不是 GET 4.1.2使用 SSL 4.1.3假設(shè)瀏覽器被控制 4.1.4假設(shè)瀏覽器是公開(kāi) 4.1.5使用JavaScript是不安全的 4.1.6不能依賴Request到達(dá)的順序 4.1.7在惡意環(huán)境中保護(hù)瀏覽器 4.1.8創(chuàng)建一個(gè)

29、默認(rèn)的錯(cuò)誤頁(yè)面 4.1.9使用通用錯(cuò)誤消息 4.2會(huì)話,30,在數(shù)據(jù)發(fā)送給客戶前進(jìn)行編碼或者加密 瀏覽器一直以來(lái)就有很多問(wèn)題。攻擊者可以通過(guò)有問(wèn)題的程序攻擊存在漏洞的客戶端。因此不要讓你的程序成為這種工具。很多情況下這種問(wèn)題可以理解為輸入驗(yàn)證的問(wèn)題，但是從深度防御的角度考慮，它也是一個(gè)輸出編碼（加密）的問(wèn)題。 例如，你可以通過(guò)對(duì) HTTP請(qǐng)求進(jìn)行校驗(yàn)來(lái)防御來(lái)自外部的跨站腳本攻擊，但是如果你對(duì) HTTP應(yīng)答都進(jìn)行了編碼，這樣就可以防御來(lái)自外部和內(nèi)部的跨站腳本。,第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.1.1使用 POST而不是 GET 4.1.2使用 SSL 4.1.3假設(shè)瀏覽器被控制

30、4.1.4假設(shè)瀏覽器是公開(kāi) 4.1.5使用JavaScript是不安全的 4.1.6不能依賴Request到達(dá)的順序 4.1.7在惡意環(huán)境中保護(hù)瀏覽器 4.1.8創(chuàng)建一個(gè)默認(rèn)的錯(cuò)誤頁(yè)面 4.1.9使用通用錯(cuò)誤消息 4.2會(huì)話,31,對(duì)所有的異常構(gòu)造統(tǒng)一的錯(cuò)誤頁(yè)面，包括 HTTP錯(cuò)誤和未經(jīng)處理的異常 為 HTTP錯(cuò)誤建立一個(gè)默認(rèn)的錯(cuò)誤頁(yè)面，丟棄掉所有的異常，這樣的話就能夠防止攻擊者從應(yīng)用程序的默認(rèn)出錯(cuò)頁(yè)面中得到系統(tǒng)信息。,第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.1.1使用 POST而不是 GET 4.1.2使用 SSL 4.1.3假設(shè)瀏覽器被控制 4.1.4假設(shè)瀏覽器是公開(kāi) 4.1.5使

31、用JavaScript是不安全的 4.1.6不能依賴Request到達(dá)的順序 4.1.7在惡意環(huán)境中保護(hù)瀏覽器 4.1.8創(chuàng)建一個(gè)默認(rèn)的錯(cuò)誤頁(yè)面 4.1.9使用通用錯(cuò)誤消息 4.2會(huì)話,32,要確定你的應(yīng)用錯(cuò)誤提示信息不會(huì)泄露系統(tǒng)信息以及出錯(cuò)原因等敏感信息 精心構(gòu)造錯(cuò)誤提示信息來(lái)防止諸如用戶 id，網(wǎng)絡(luò)，應(yīng)用程序以及服務(wù)器環(huán)境的細(xì)節(jié)等重要的敏感信息的泄漏。主要包括: 不區(qū)分錯(cuò)誤的用戶名和錯(cuò)誤的密碼； 在返回的報(bào)告中不包含主機(jī)信息、網(wǎng)絡(luò)信息、 DNS信息、軟件版本信息、錯(cuò)誤代碼或者其它發(fā)生的錯(cuò)誤的詳細(xì)信息； 不要把錯(cuò)誤的細(xì)節(jié)放在錯(cuò)誤頁(yè)面的注釋里。,第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.

32、1.1使用 POST而不是 GET 4.1.2使用 SSL 4.1.3假設(shè)瀏覽器被控制 4.1.4假設(shè)瀏覽器是公開(kāi) 4.1.5使用JavaScript是不安全的 4.1.6不能依賴Request到達(dá)的順序 4.1.7在惡意環(huán)境中保護(hù)瀏覽器 4.1.8創(chuàng)建一個(gè)默認(rèn)的錯(cuò)誤頁(yè)面 4.1.9使用通用錯(cuò)誤消息 4.2會(huì)話,33,使用最具限制性的域和路徑來(lái)限制對(duì)會(huì)話使用的 cookie的訪問(wèn) 如果出于結(jié)構(gòu)要求需要與 cookie有關(guān)的域或者路徑是開(kāi)放的，請(qǐng)?jiān)谥貥?gòu)時(shí)候注意安全性。出于安全性的考慮，應(yīng)該在建立 Session時(shí)要求用戶以 SSL方式連接，并且將該會(huì)話的安全標(biāo)識(shí)設(shè)置為 cookie只能通過(guò)安全連接進(jìn)行傳輸。,第四章、安全建議web應(yīng)用程序,4.1基礎(chǔ) 4.2會(huì)話 4.2.1保護(hù)會(huì)話中使用的cookie 4.2.2強(qiáng)制執(zhí)行一個(gè)會(huì)話最大空閑時(shí)間 4.2.3強(qiáng)制執(zhí)行一個(gè)會(huì)話最大生存周期 4.2.4允許用戶終止其會(huì)話 4.2.5在會(huì)話終止時(shí)清空其數(shù)據(jù),34,使用最具限制性的域和路徑來(lái)限制對(duì)會(huì)話使用的 cook