ASP.NET程式安全的基礎知識

成員關係的概念在人類社會中是一個層次比較低的概念，源於希望屬於某個群組的意識。我們希望能覺得自己是某個團隊的一部分，讓別人知道我們是誰，因此Web搭上這個流行趨勢，採用這個概念只是時間早晚的問題。如果坐下來想一想曾經登入過多少個站點並在這些站點上儲存了簡單的使用者資訊，可能會發現自己所屬的群組比一開始想象的要多得多。從出售書籍和小器具的站點到討論擁有一輛Ford Puma的好處的社群，或者宣傳一個名為Look Around You的BBC TV喜劇節目的站點，作者發現自己是會員的站點多得無法一一列舉。接下來就會碰到一個熟悉的困難“登入這個站點要使用哪個使用者名稱和口令?”

　　Web上最成功的站點之一，Amazon.com，一開始只是一個書店，但後面經營的範圍越來越大。現在當使用者登入Amazon時，將發現整個頁面上全是與該使用者的消費習慣有關的商品。

　　在開始開發涉及到成員關係的應用程式時，必須首先理解幾個關鍵的概念，這些概念是身份、驗證和授權。

　　1、身份——我是誰

　　在考慮身份時，我們可以用幾種獨一的特性來描述自己。例如，我是一個頭發金黃的女人，喜歡看科幻電影和組裝PC機，但這些資訊對於對我的羽毛球技術感興趣的人來說並不是必需的。儲存在站點中的身份資訊很可能只與一個人的某些方面相關。例如，一個購物站點會儲存使用者的姓名、電話號碼、電子郵件地址和家庭地址，這些資訊都與商品的銷售有關。它們可能不會關心您的個人興趣(除非它們和Amazon的規模一樣大)，所以它們並不需要儲存關於使用者的這類資訊，但是這並不妨礙它們擁有這些方面的身份資訊。

　　因此身份，也就是我是誰的概念，是一組範圍很廣的實際情況的集合。您可能曾經在簡歷裡寫下了很多實際情況，但這些情況同樣只與潛在的僱主相關。在簡歷中儲存和刪除哪些情況由自己決定。在儲存一個站點的成員的資訊時，情況也是一樣的，必須在開發階段就確定要儲存成員的哪些實際情況。

　　2、身份驗證——這就是我

　　在試圖登入一個網站的時候，使用者要輸入某些證書; 例如，郵件地址及其口令的組合。網站接下來必須判斷使用者是否就是自己宣告的那個人，因此使用者輸入的郵件地址和口令的組合必須與儲存在伺服器檔案中特定的郵件地址和口令組合相匹配。

　　身份驗證的過程就是證明自己是自己所宣告的那個人的過程。很多站點，不論它們是零售商品還是提供社群服務，都使用郵件地址和口令的組合作為身份驗證方法，這是一種經過反覆考驗的方法。雖然這種方法不是絕對安全，但是隻要選擇一個足夠可靠的口令並嚴格保密，同時站點的程式碼經過嚴格的測試，那麼使用者的配置檔案將只能由使用者本人使用。

　　3、授權——這是我能做的

　　在向網站輸入使用者名稱和口令之後，Web伺服器將不僅會驗證口令和使用者名稱是否匹配，還將檢視站點管理員給使用者授予了什麼許可權。身份驗證之後的下一個步驟是授權，這個步驟將檢索您所擁有的使用者賬戶型別的更多資訊。

　　例如，以一個銀行網站為例。在使用者的登入資訊通過驗證之後，伺服器將檢視使用者在該站點上的許可權。與大多數使用者一樣，您可以查詢賬戶、在賬戶之間轉賬或者支付賬單。然而，如果銀行受到某個安全方面的恐嚇(類似於Internet上到處流傳的網路釣魚(phishing)電子郵件)，您可能會發現自己突然無法通過這個線上應用程式新增任何第三方代理訂單，直到安全危機解除為止。功能的關閉很可能是由管理員為一些或所有使用者設定一個特殊的標記而進行控制的，在頁面上告訴使用者他們不再有許可權修改他們賬戶的詳細資訊。

　　4、登入站點

　　登入站點的過程，從使用者的角度看，就是輸入一組證書，然後根據自己的配置檔案看到不同使用者介面的過程。通常，使用者所使用的證書是使用者名稱加口令的組合; 然而，對於安全性更高的站點，例如銀行站點，可以使用其他的方式登入，包括PIN和安全認證。如果不考慮向伺服器傳送身份驗證證書的方法，那麼身份驗證的基本原則是一樣的。一旦驗證完成之後，通過身份驗證機制查詢使用者具有什麼樣的許可權就比較簡單了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-545134/，如需轉載，請註明出處，否則將追究法律責任。