表单身份验证中的安全性问题，欢迎大家讨论！

给予表单的身份验证中，验证信息是保存在Cookie中的，或是保存在Session中的。
如果用户通过某些手段获得了这个Cookie内容或是获得了这个SessionID，那么该用户岂不可以伪造成了该会话用户，而且也通过了身份验证。
也就是说如果A用户登陆了，通过了身份验证。那么保存在客户端的Cookie如果被B用户获得了。或者SessionID被B用户获得了。那么B用户岂不成了系统中的已授权的A用户？如何避免这点，请大家讨论，谢谢！

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

有没有办法获得客户端机器的某些特有的固定信息。比如网卡等，这就可以解决了哟！//这样必须写客户端控件，可是要是别人写了另一个控件来蒙骗服务器呢？所以还是要在服务器上下功夫，客户机上的任何东西，我们都应该认为是不可靠的Session是服务器和客户端联合作用的，也涉及到IP验证什么的，应该好比较安全
cookie就不好说了
那ASP.NET可以获得哪些客户端可以标志唯一用户的信息？谢谢！
用户登陆时或用户更改密码时，采用将输入的密码用客户端javascript的MD5加密后再提交到服务器端。
这种方式有没有一定的效果？
我想如果用户得到密码的MD5字符串，似乎同样可以用来登陆。因为他并不需要知道密码原文，用密码的MD5字符串提交，也是一样的呀。
SessionID其实没有好的办法保密。当然那种把SessionID放在url中的办法更不可行。复制了SessionID就可以在冒名顶替，至少在真正的退出后立刻冒名顶替进服务器。好在SessionID是每一个会话随机分配的，而且超时可以自动过期。这比使用Cookie来保存用户登录帐号或者给SessionID一个过长的超时时间要好（千万不要嫌20分钟时间短呀！应该嫌长才对）。记录每一个SessionID第一次登录的IP，以后同一SessinID如果换IP就踢出去。这加强了一些安全性。真正对安全性来说，最应该关心的用户注入攻击。例如在提交数据上录入隐藏脚本，或者是私自后改__ViewState使得程序带毒运行等等。
记录每一个SessionID第一次登录的IP，以后同一SessinID如果换IP就踢出去。这加强了一些安全性。我也这么想的，但是如果提供给用户永久登陆的选择的话。这样用户如果采用ADSL上网，那么每次上网的IP都是变的。那么选择永久登陆（用Cookie保存信息）的用户将会没办法实现永久登陆哟。
私自更改__ViewState，大家有什么好的办法没有嘛？防止站外提交大家也有什么办法没有？
其实有个方法,但是速度上有点损失,可以采用数据库和session双认证,比如两者都满足时才能通过,但是就是要连接数据库,还有种方法就是用asp.net自造.htm文件,将它也服务器隔开,具体没试过
其实不用操那么多的心。用Session验证：请问怎么获得SessionID？截取网络数据吗？如果安全性不是很高的话，根本就不用想这么多！
那么选择永久登陆（用Cookie保存信息）的用户将会没办法实现永久登陆哟。
-----------------------------------------------------------------------
每一个会话的SessionID都是不同的。不存在你说的问题。也正因为如此，所以才应该用SessionID，而千万不要把用户的登录名保存在Cookie里作为标识，那样作在设计上就是为“永久盗版”提供了坚实基础了。
利用 __ViewState 攻击其实是很可怕的。因为大多数程序不在回发时验证它。修改它其实是很好玩的，你们可以试试写个小程序读取一个商务网站的页面然后处理它的ViewState再Post回给它，你可以轻易绕过它的验证措施，甚至可以指挥它的下一步处理流程。因此asp.net有现成的措施，EnableViewStateMac，可惜大家都不重视，注意使用的又有几人？我将 __ViewState 保存在服务器端而不输出到客户端，因此此类问题基本上可以全不去担心。
我将 __ViewState 保存在服务器端而不输出到客户端，因此此类问题基本上可以全不去担心。我想过这个问题。
是怎么做的？是不是生成很多的临时文件？那么这些临时文件多了如何清理呢？请说说你的实现方法，万分感谢！
将 __ViewState 保存在服务器端而不输出到客户端，这还有一个问题就是担心会加重服务器负担哟（读取文件的负担）
那么选择永久登陆（用Cookie保存信息）的用户将会没办法实现永久登陆哟。
-----------------------------------------------------------------------
每一个会话的SessionID都是不同的。不存在你说的问题。也正因为如此，所以才应该用SessionID，而千万不要把用户的登录名保存在Cookie里作为标识，那样作在设计上就是为“永久盗版”提供了坚实基础了。
========================================================================
如果要实现永久登陆，你怎么做？如果不保存用户名和密码。只保存SessionID吗？这样如果Session超时，已经从服务器删除了，那么你保存的Cookie中的SessionID也不是没有用了吗？也就没法自动登陆了哟？谢谢指点！如果分不够可以提出，我可以另外加分，谢谢！
读写本地文件肯定比从网络上读写划算。保存在windows临时目录中，在页面回发的时候 LoadPageStateFromPersistenceMedium 中删除文件就可以了，这样丢失（未删除）的文件很少。当然也可以在application启动的时间中删除那些丢失的文件，或者干脆不管，反正windows的临时文件目录会自动清理。实际上，我同时还在 cache 中缓存 30 秒，所以30秒钟内回发到服务器的页面ViewState并不从文件中读取，只是删除文件。
“永久登录”与“判断SessionID并踢出IP改变的用户”并不矛盾，并不会因为提出错误IP的用户就会妨碍“永久登录”的实现。因为每一次登录，即使是“永久登录”，会话的SessionID也是不同的。
永久登录当然存在假冒问题，我上面说过使用Cookie保存用户登录帐号机器危险。只要拥有cookie数据文件复制品就可以假冒了。不过我说的“提出不同IP用户”是对假冒SessionID那种情况而言的。
谢谢！对你的
--------------------------------------------------------------------------
“永久登录”与“判断SessionID并踢出IP改变的用户”并不矛盾，并不会因为提出错误IP的用户就会妨碍“永久登录”的实现。因为每一次登录，即使是“永久登录”，会话的SessionID也是不同的。
--------------------------------------------------------------------------
不是很理解！
如果要实现永久登陆，你怎么做？如果不保存用户名和密码。只保存SessionID吗？这样如果Session超时，已经从服务器删除了，那么你保存的Cookie中的SessionID也不是没有用了吗？也就没法自动登陆了哟？谢谢指点！比如：用户选择了永久登陆，那么如果用户几天后再来访问，理应自动登陆。但是如果仅仅保存了SessionID的话，这是SessionID指定的Session肯定早就删除了，那么如何才能知道这个用户是登陆了的呢？
当然如果保存用户名和密码就可以利用用户名和密码还恢复Session
永久登录当然存在假冒问题，我上面说过使用Cookie保存用户登录帐号机器危险。只要拥有cookie数据文件复制品就可以假冒了。不过我说的“提出不同IP用户”是对假冒SessionID那种情况而言的。
-----------------------------------------------------------------------------
这样的话如果用户用的是ADSL上网，如果掉线了，然后又连上了，IP发生了改变。这样也就会变成未登陆用户了哟？
“踢出用户”不是指把他变成“未登录用户”，而是显示错误页面。如果ADSL掉线，那么当然就要在浏览器地址栏上打个回车键。
很多软件都是这样的，例如QQ。我不知道浏览器是否会在ADSL掉线的时候重新生成SessionID，我的从来没有掉过。但是显示一个错误页面，要求客户重新打开浏览器窗口还算正常。
实际上我上面一直没有去讨论“永久登录”问题。我的意见就是“永久登录”肯定要cookie中保存用户的帐户信息，这已经是非常容易假冒的了（注意，加密不起任何作用，这是由于这个信息的效力太长引起的，而SessionID只有20分钟有效期，所以安全一点），但是功能上一定要求这个当然就没办法只好这样，所以我上面着重谈防止SessionID假冒，并且说明哪个方法并不与“永久登录”矛盾。并没有说有什么办法取代“永久登录”所使用的方法。