利用 asp.net 的內(nèi)置功能抵御 Web 攻擊 (1)

摘要： Dino 總結(jié)了最常見的 Web 攻擊類型，并介紹了 Web 開發(fā)人員可以如何使用 ASP.NET 的內(nèi)置功能來改進(jìn)安全性。

一、ASP.NET 開發(fā)人員應(yīng)當(dāng)始終堅(jiān)持的做法　　如果您正在閱讀本文，可能就不需要再向您灌輸 Web 應(yīng)用程序中的安全性愈來愈重要這一事實(shí)了。您需要的可能是一些有關(guān)如何在 ASP.NET 應(yīng)用程序中實(shí)現(xiàn)安全性的實(shí)際建議。壞消息是，沒有任何開發(fā)平臺(tái) — 包括 ASP.NET在內(nèi) — 能夠保證一旦采用了該平臺(tái)，您就能夠編寫百分百安全的代碼。誰要是這么說，一準(zhǔn)在撒謊。好消息是，就 ASP.NET 來說，ASP.NET，特別是版本 1.1 和即將發(fā)行的版本 2.0，集成了一些便于使用的內(nèi)置防御屏障。

　　光是應(yīng)用所有這些功能并不足以保護(hù) Web 應(yīng)用程序，使其免受任何可能和可預(yù)見的攻擊。但是，如果與其他防御技巧和安全策略相結(jié)合，內(nèi)置的 ASP.NET 功能將可以構(gòu)成一個(gè)強(qiáng)大的工具包，有助于確保應(yīng)用程序在安全的環(huán)境中運(yùn)行。

　　Web 安全性是各種因素的總和，是一種范圍遠(yuǎn)超單個(gè)應(yīng)用程序的策略的結(jié)果，這種策略涉及數(shù)據(jù)庫(kù)管理、網(wǎng)路配置，以及社會(huì)工程和 phishing。

　　本文的目的在于說明 ASP.NET 開發(fā)人員為了將安全標(biāo)準(zhǔn)保持到合理的高度，所應(yīng)始終堅(jiān)持的做法。這也就是安全性最主要的內(nèi)容：保持警惕，永不完全放松，讓壞人越來越難以發(fā)起黑客攻擊。

　　下面我們來看看 ASP.NET 提供了哪些可以簡(jiǎn)化這項(xiàng)工作的功能。

二、威脅的來源在表 1 中，我匯總了最常見的 Web 攻擊類型，以及應(yīng)用程序中可能導(dǎo)致這些攻擊得手的缺陷。

攻擊 攻擊的可能發(fā)起人跨站點(diǎn)腳本 (XSS)回顯到頁的不可信用戶輸入SQL 注入串連用戶輸入以形成 SQL 命令會(huì)話劫持會(huì)話 ID 猜測(cè)和失竊的會(huì)話 ID Cookie一次單擊通過腳本發(fā)送的未被察覺的 HTTP 張貼隱藏域篡改未檢查（且受信）的隱藏域被填充以敏感數(shù)據(jù)

表 1. 常見的 Web 攻擊

　　列表中顯現(xiàn)出來的關(guān)鍵性事實(shí)有哪些？在我看來，起碼有以下三點(diǎn)：

　　１.無論您何時(shí)將何種用戶輸入插入瀏覽器的標(biāo)記中，您都潛在地將自己暴露在了代碼注入攻擊（任何 SQL 注入和 XSS 變種）之下。

　?。? 必須以安全的方式實(shí)現(xiàn)數(shù)據(jù)庫(kù)訪問，就是說，應(yīng)當(dāng)為數(shù)據(jù)庫(kù)使用盡可能少的權(quán)限，并通過角色來劃分各個(gè)用戶的職責(zé)。

　?。?永遠(yuǎn)都不通過網(wǎng)絡(luò)發(fā)送敏感數(shù)據(jù)（更別說是明文了），并且必須以安全的方式將敏感數(shù)據(jù)存儲(chǔ)在服務(wù)器上。

　　有意思的是，上面的三點(diǎn)分別針對(duì)的是 Web 安全性的三個(gè)不同方面，而這三個(gè)方面結(jié)合起來，才是唯一的一種生成防攻擊、防篡改應(yīng)用程序的合理方式。Web 安全性的各個(gè)層面可以總結(jié)如下：

　?。?編碼實(shí)踐：數(shù)據(jù)驗(yàn)證、類型和緩沖區(qū)長(zhǎng)度檢查，防篡改措施

　　２.數(shù)據(jù)訪問策略：使用決策來保護(hù)可能最弱的帳戶，使用存儲(chǔ)過程或者至少是參數(shù)化的命令。

　?。?有效的存儲(chǔ)和管理：不將關(guān)鍵性數(shù)據(jù)發(fā)送到客戶端，使用哈希代碼來檢測(cè)操作，對(duì)用戶進(jìn)行身份驗(yàn)證并保護(hù)標(biāo)識(shí)，應(yīng)用嚴(yán)格的密碼策略

　　如您所看到的，只有可以通過開發(fā)人員、架構(gòu)師和管理員的共同努力，才可以產(chǎn)生安全的應(yīng)用程序。請(qǐng)不要假定您能夠以其他方式達(dá)到同樣目的。

　　編寫 ASP.NET 應(yīng)用程序時(shí)，您并不是獨(dú)自面對(duì)黑客大軍：唯一的武器是通過自己的大腦、技能和手指鍵入的代碼行。ASP.NET 1.1 和更高版本都會(huì)施加援手，它們具有一些特定的功能，可以自動(dòng)提高防御以上列出的某些威脅的屏障。下面我們對(duì)它們進(jìn)行詳細(xì)的檢視。

三、ViewStateUserKey　　從 ASP.NET 1.1 開始引入，ViewStateUserKey 是 Page 類的一個(gè)字符串屬性，只有很少數(shù)開發(fā)人員真正熟悉該屬性。為什么呢？讓我們看看文檔中是怎么說的。

　　在與當(dāng)前頁相關(guān)聯(lián)的視圖狀態(tài)變量中將一個(gè)標(biāo)識(shí)符分配給單個(gè)用戶

　　除了有些累贅，這個(gè)句子的意思相當(dāng)清楚；但是，您能老老實(shí)實(shí)地告訴我，它說明了該屬性原本的用途嗎？要理解 ViewStateUserKey 的角色，您需要繼續(xù)往下讀，直到 Remarks 部分。

　　該屬性有助于防止一次單擊攻擊，因?yàn)樗峁┝烁郊拥妮斎胍詣?chuàng)建防止視圖狀態(tài)被篡改的哈希值。換句話說，ViewStateUserKey 使得黑客使用客戶端視圖狀態(tài)的內(nèi)容來準(zhǔn)備針對(duì)站點(diǎn)的惡意張貼困難了許多?？梢詾樵搶傩苑峙淙魏畏强盏淖址詈檬菚?huì)話 ID 或用戶的 ID。為了更好地理解這個(gè)屬性的重要性，下面我們簡(jiǎn)短介紹一下一次單擊攻擊的基本知識(shí)。

　　一次單擊攻擊包括將惡意的 HTTP 表單張貼到已知的、易受攻擊的 Web 站點(diǎn)。之所以稱為“一次單擊”，是因?yàn)樗ǔＪ且允芎φ卟唤?jīng)意的單擊通過電子郵件發(fā)送的或者在擁擠的論壇中瀏覽時(shí)發(fā)現(xiàn)的誘惑性鏈接而開始的。通過點(diǎn)擊該鏈接，用戶無意中觸發(fā)了一個(gè)遠(yuǎn)程進(jìn)程，最終導(dǎo)致將惡意的<form>提交到一個(gè)站點(diǎn)。大家都坦白些吧：您真能告訴我，您從未因?yàn)楹闷娑鴨螕暨^ Click here to win $1,000,000 這樣的鏈接嗎？顯然，并沒有什么糟糕的事情發(fā)生在您身上。讓我們假定的確是這樣的；您能說 Web 社區(qū)中的所有其他人都幸免于難了嗎？誰知道呢。

　　要想成功，一次單擊攻擊需要特定的背景條件：

　?。?攻擊者必須充分了解該有漏洞的站點(diǎn)。這是可能的，因?yàn)楣粽呖梢?ldquo;勤奮地”研究該文件，或者他/她是一位憤怒的內(nèi)部人員（例如，被解雇而又不誠(chéng)實(shí)的雇員）。因此，這種攻擊的后果可能是極其嚴(yán)重的。

　　２.站點(diǎn)必須是使用 Cookie（如果是持續(xù)性 Cookie，效果更好）來實(shí)現(xiàn)單次登錄，而攻擊者曾經(jīng)收到過有效的身份驗(yàn)證 cookie。

　?。?該站點(diǎn)的某些用戶進(jìn)行了敏感的事務(wù)。

　　４.攻擊者必須能夠訪問目標(biāo)頁。

　　前已提及，攻擊包括將惡意的 HTTP 表單提交到等待表單的頁。可以推知，該頁將使用張貼來的數(shù)據(jù)執(zhí)行某些敏感操作?？上攵粽咔宄亓私馊绾问褂酶鱾€(gè)域，并可以想出一些虛假的值來達(dá)到他的目的。這通常是目標(biāo)特定的攻擊，而且由于它所建立的三角關(guān)系，很難追本溯源 — 即黑客誘使受害者單擊該黑客站點(diǎn)上的一個(gè)鏈接，而這又會(huì)導(dǎo)致惡意代碼被張貼到第三個(gè)站點(diǎn)。（請(qǐng)參閱圖 1。）

圖 1. 一次單擊攻擊

　　為什么是不抱懷疑的受害者？這是因?yàn)?，這種情況下，服務(wù)器日志中所顯示的發(fā)出惡意請(qǐng)求的 ip 地址，是該受害者的 IP 地址。如前所述，這種工具并不像“經(jīng)典”的 XSS 一樣常見（和易于發(fā)起）；但是，它的性質(zhì)決定了它的后果可能是災(zāi)難性。如何應(yīng)對(duì)它？下面，我們審視一下這種攻擊在 ASP.NET 環(huán)境下的工作機(jī)理。

　　除非操作編碼在 Page_Load 事件中，否則 ASP.NET 頁根本不可能在回發(fā)事件之外執(zhí)行敏感代碼。要使回發(fā)事件發(fā)生，視圖狀態(tài)域是必需的。請(qǐng)牢記，ASP.NET 會(huì)檢查請(qǐng)求的回發(fā)狀態(tài)，并根據(jù)是否存在 _VIEWSTATE 輸入域，相應(yīng)地設(shè)置 IsPostBack。因此，無論誰要向 ASP.NET 頁發(fā)送虛假請(qǐng)求，都必須提供一個(gè)有效的視圖狀態(tài)域。

　　一次單擊攻擊要想得手，黑客必須能夠訪問該頁。此時(shí)，有遠(yuǎn)見的黑客會(huì)在本地保存該頁。這樣，他/她就可以訪問 _VIEWSTATE 域并使用該域，用舊的視圖狀態(tài)和其他域中的惡意值創(chuàng)建請(qǐng)求。問題是，這能行嗎？

　　為什么不能？如果攻擊者可以提供有效的身份驗(yàn)證 cookie，黑客就可以進(jìn)入，請(qǐng)求將被照常處理。服務(wù)器上根本不會(huì)檢查視圖狀態(tài)內(nèi)容（當(dāng) EnableViewStataMac 為 off 時(shí)），或者只會(huì)檢查是否被篡改過。默認(rèn)情況下，試圖狀態(tài)中沒有機(jī)制可以將該內(nèi)容與特定的用戶關(guān)聯(lián)起來。攻擊者可以輕松地重用所獲取的視圖狀態(tài)，冒充另一個(gè)用戶合法地訪問該頁，以生成虛假請(qǐng)求。這正是 ViewStateUserKey 介入的地方。

　　如果選擇準(zhǔn)確，該屬性可以將用戶特定的信息添加到視圖狀態(tài)。處理請(qǐng)求時(shí)，ASP.NET 會(huì)從視圖狀態(tài)中提取秘鑰，并將其與正在運(yùn)行的頁的 ViewStateUserKey 進(jìn)行比較。如果兩者匹配，請(qǐng)求將被認(rèn)為是合法的；否則將引發(fā)異常。對(duì)于該屬性，什么值是有效的？

　　為所有用戶將 ViewStateUserKey 設(shè)置為常量字符串，相當(dāng)于將它保留為空。您必須將它設(shè)置為對(duì)各個(gè)用戶都不同的值 — 用戶 ID，會(huì)話 ID 更好些。由于一些技術(shù)和社會(huì)原因，會(huì)話 ID 更為合適，因?yàn)闀?huì)話 ID 不可預(yù)測(cè)，會(huì)超時(shí)失效，并且對(duì)于每個(gè)用戶都是不同的。

　　以下是一些在您的所有頁中都必不可少的代碼：

void Page_Init (object sender, EventArgs e) {ViewStateUserKey = session.SessionID;:}

　　為了避免重復(fù)編寫這些代碼，您可以將它們固定在從 Page 派生的類的 OnInit 虛擬方法中。（請(qǐng)注意，您必須在 Page.Init 事件中設(shè)置此屬性。）

PRotected override OnInit(EventArgs e) {base.OnInit(e);ViewStateUserKey = Session.SessionID;}

　　總體說來，使用基 page 類始終都不失為一件好事，我在 Build Your ASP.NET Pages on a Richer Bedrock 一文中已經(jīng)進(jìn)行了說明。如果您要了解更多有關(guān)一次單擊攻擊者的伎倆的信息，可以在 aspnetpro.com 找到一篇非常好的文章。