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值。
posted @ 2007-03-08 12:13  jason_lb  阅读(...)  评论(...编辑  收藏