ASP.NET中考慮到安全性，使用url參數和Session的方法

1.      
url參數並非完全不能用

由於url參數對於用戶端是明文形式，相當不安全，應盡量不使用url傳遞一些敏感的資訊。但因url參數是web畫面間交換資訊的重要途徑，故可以用url傳遞一些看上去無意義的文字。

使用url參數的要求：

a.url參數必須要通過urlDecode和urlEncode處理。

b.url參數不能用于敏感資訊或機密資訊。（如果說對這些資訊加密後傳遞，這個效率不如直接用Session，代碼也不如寫Session簡便。）

c.在取得url參數後必須經過資料有效性驗證後才能使用。

 

2.      
服務端Session的使用

因Session是服務端的，很好的解決了安全性問題，所以用Session可以儲存安全等級比較高的資訊。但Session不能濫用。

使用Session的要求：

a.項目中應該通過專屬於Session的類（暫訂名為SessionManager）來統一管理Session的取值賦值及清理，嚴禁直接自行調用Session類，要調用必須通過這個SessionManager類來調用。

b. SessionManager類不直接提供自訂名稱的Session的使用。（例如如果要使用Session[“NAME”]則通過在SessionManager添加，直接提供使用，比如SessionManager.NAME這種靜態屬性方式）；清理Session的方法也類似。

c. 應盡量減少Session的使用，SessionManager提供3到5個即可（具體個數根據項目大小適當調整），相似作用的Session可以合并，以一個Session儲存，儲存內容可通過一定方式組合，使用時再解析即可。

d.某些Session儲存的資訊肯在使用後就沒用了，就要在第一時間清理，不能馬上清理的，也要從全域考慮找到合適的地方進行清理。以上為手工方式。還有IIS自身的Session有效期間設定，不宜過大，一般20分鐘為好，區域網路內的管理系統可適當放寬。

e.Session異常的問題。Session是不穩定，但卻並不是傳說的很不穩定。Session由於其使用上靈活，從而相對的，它管理上就容易混亂，所以大多數時候Session異常是程式本身的代碼問題，合理的管理才能保證使用的簡便及安全，使用SessionManager類統一管理的目的即在此。

如果判定某Session失效則由此類拋出異常，請登入者重新登入。

 

3.      
使用Session時的用戶端多視窗問題

問題：

例如，某畫面中顯示公司職員列表，通過點擊某職員連結開啟新畫面從而顯示該職員資訊，點擊多個職員的連結則會開啟多個視窗，web上開啟新視窗是通過指令碼來實現的，若使用url參數傳遞此職員id則顯的不安全。但改成用Session儲存職員id，然後在開啟視窗中擷取該Session，顯然在多視窗時會造成混亂。

解決：

為解決開啟多個子頁面而產生的不同頁面中參數值不同的問題，Session名要採用動態名。當在父頁面中點擊產生子頁面時，根據子頁面的開啟時間計數值（tick），產生相應的Session名。例如要產生NAME的Session為Session[“NAME”+tick]。

這樣，從父頁面開啟子頁面時，只需用url傳這個tick值，如果在子頁面需要取NAME的Session值時，可直接由“NAME”+tick來確定Session。

實現：

為保證各個子畫面取到各自對應的Session值，各個子畫面在開啟時都要帶有tick 的url參數，在每個子畫面中取Session時只要先取得該tick值即可確定該畫面對應Session值。