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值。