7. 用户管理
— 几乎每个web应用都必须去处理授权和认证。避免你自己重复造轮子，建议你去使用通用的插件。但是请保持它们是最新的。一些额外的 预防措施可以让你的应用更加安全。
有一些Rails可用的授权和认证插件。密码加密以后保存好于直接保存纯文本密码。最流行的插件是可以避免session定制的 restful_authentication。 然而早期的版本在某些情况下你即使没有用户名和密码也可以登陆。
每个新用户可以通过一个带激活码链接的电子邮件来激活他的帐户。帐户激活之后，数据库里激活码那一列的值会被设为NULL, 如果某人发 送一个这样的请求，他将被以第一次激活的用户身份记录到数据库里。 (有机会成为管理员):
http://localhost:3006/user/activate
http://localhost:3006/user/activate?id=
这是可能的，因为在某些服务器上， 以id为参数的这种方式，如params[:id], 将会是nil。然而，这里有以个activation action里的 finder方法:
User.find_by_activation_code(params[:id])
如果参数是nil，那么SQL查询的结果会是：
SELECT * FROM users WHERE (users.`activation_code` IS NULL) LIMIT 1
这样，在数据库记录里的第一个激活用户就被查到，返回这个结果，攻击者就登陆了. 你能找到更多的信息在我的blog帖子里。 不时的更 新你的插件是明智的. 此外，你可以查看你的应用找到更多的这样的漏洞。
7.1.暴力猜解帐户
— 暴力猜解帐户攻击是使用错误的登陆证书去尝试。用更通用的错误信息来阻断这种攻击，可能需要输入一个验证码.
你web应用的用户名列表可能会被拿去用一组密码来做暴力猜解, 因为大多数的人不使用复杂的密码。大多数的密码是字典里单词和数字组 合。因此配备一组用户名名单和一个黑客字典，一个自动程序，可能在几分钟之内就能找到正确的密码。
因为这个，大多数的web应用会在它们不正确的时候显示一个通用的错误信息 “用户名或密码不正确”。如果显示的错误信息是“用户名没 有被找到”，那么攻击者就会自动编制一份用户名名单。
然而，大多数的web应用设计者都忽视了忘记密码页。 当输入用户名或email地址的时候，这些网页往往很诚实的就显示找到（没有找到） 的消息。这使攻击者能够编制一份可以暴力猜解帐号的用户名名单。
在忘记密码这个网页上也显示一个通用的错误消息可以减轻这种攻击。此外，在某一个ip地址多次登陆失败之后你可以要求输入一个验证码 。但是请注意，这不是一个完全防弹的做法， 这些自动的程序也可以频繁的改变自己的ip地址。只是给攻击增加障碍。
7.2.帐户劫持
— 很多web应用很容易劫持帐户。为什么不能使它变得更困难呢 ？
7.2.1. 密码
想想这种情况，一个攻击者窃取了一个用户的session cookie，因此他们可以共用同一个应用。如果这个应用可以很容易就修改了密码，那 么攻击者只需要几个鼠标点击就劫持了这个用户的帐号。或者，如果修改密码的表单容易受到CSRF攻击的话，那么攻击者就会通过引诱受害者 到一个藏有制作好的CSRF IMG -TAG的网页来修改他的密码。对策是，让修改密码的表单不能被CRSF攻击，当然在改变密码的时候，也需要用户 去输入旧密码。
7.2.2. E-Mail
然而，攻击者也可以通过修改email地址来接管帐户。当他修改email地址之后，他会去一个忘记密码网页，可能一个新的密码就会被发送到 攻击者的电子邮箱里了。对策是，当修改email地址的时候，也需要输入一个密码。
7.2.3. 其他
依靠不同的web应用，可能有更多的劫持用户帐户的方法。在许多情况下，CSRF和XSS都有助于这样做。例如，Google Mail的一个CSRF漏洞 ，在这个概念验证的攻击中，受害者会被引诱到一个被攻击者控制的站点。在这个站点有一个制作好的IMG-tag, 该tag的结果是，发送一个 http get请求去改变Google Mail的邮件过滤器设置。如果这个受害者登陆到Google Mail，攻击者会改变过滤器设置将他的所有邮件转发到攻 击者的邮箱里。这几乎和劫持整个帐户一样邪恶。对策是, 审核你的web应用逻辑来堵上所有的XSS和CSRF漏洞。