Web安全(5)

验证机制

• 验证机制是Web应用程序所有安全机制中最简单的一种机制。通常，应用程序必须核实用户提交的用户名和密码是否正确，如果正确，则允许用户登录，否则禁止用户登录。
• 验证机制意识应用程序防御恶意攻击的中心机制。它处在防御未授权访问的最前沿，如果用户能够突破这些防御，他们通常能够控制应用程序的全部功能，自由访问其中保存的数据。

验证技术

当执行验证机制时,Web应用程序开发者可以采用各种不同的技术：

• 基于HTML表单的验证
• 多元机制，如组合型密码和物理令牌
• 客户端SSL证书或智能卡
• HTTP基本和摘要验证
• 使用NTLM或Kerberos整合Windows验证
• 验证服务

实际应用

• Web应用程序中最常用的验证机制是使用HTML表单获取用户名和密码
• 在更加注重安全的应用程序中(电子银行)，这种基本机制扩展到几个阶段，要求用户提交其他证书，如PIN号码或从机密字中选择字符。HTML表单仍主要用于获取相关数据
• 最为注重安全的应用程序(进行巨额交易的私人银行)通常采用使用物理令牌的多元机制，这些令牌通常产生一组一次性口令，或者根据应用程序指定的输入执行一个质询-响应功能。
• 由于成本高昂，只有一些用户不多的安全极其重要的应用程序才会使用客户端SSL证书或在智能卡中执行加密机制，
• 因特网上的应用程序很少采用基于HTTP的验证机制，企业内联网更常采用这种机制。这时，阻止内部用户提供标准的网络或域证书，应用程序通过以上一种技术对其进行处理，再允许用户访问企业应用程序

验证机制设计缺陷

密码保密性不强

许多Web应用程序没有或很少对用户密码的强度进行控制。应用程序常常使用下列形式的密码：

• 非常短或空白的密码
• 以常用的字典词汇或名称为密码
• 密码和用户名完全相同
• 仍然使用默认密码

蛮力攻击登录

• 使用不同的密码重复进行登录尝试，直到找到正确密码。
• 一些应用程序使用客户端控件防止密码猜测攻击，例如，某个应用程序可能会设置cookie-failedlogins=1，如果登录失败，递增这个值，达到某个上限后，服务器将在提交的cookie中检测这个值，并拒绝处理登录尝试。

详细的失败信息

一个典型的登录表单要求用户输入两组信息(用户名或密码),如果应用程序对哪一组信息出错进行提示(如密码错误/用户名错误),就可以利用它显著降低登录机制的防御效能。如果登录时显示用户名出错，攻击者就可以发动一次自动化攻击，遍历大量常见的用户名,确定哪些有效。

证书传输易受攻击

如果应用程序使用非加密的HTTP链接传输登录证书，处于网络适当位置的窃听者当然就能拦截这些证书。根据用户的位置，窃听者可能位于：

• 用户的本地网络中
• 用户的IT部门内
• 用户的ISP内
• 因特网骨干网上
• 托管应用程序的ISP内
• 管理应用程序的IT部门内

即使是通过HTTPS登录，如果应用程序处理证书的方式不安全，证书仍可能被泄露给未授权方

• 如果以查询字符串参数、而不是POST请求主体中传送证书，许多地方都可能记录这些证书(如用户的浏览历史记录中、Web服务器日志以及主机基础架构采用的任何反向代理中)，如果攻击者成功攻破这些资源，就能够获取保存在这些地方的用户证书，从而提升其访问权限
• 虽然大多数Web应用程序确实使用POST请求主体提交HTML提交表单，但是，应用程序常常通过重定向到一个不同的URL来处理登录请求，然后以查询字符串的形式提交证书
• Web应用程序有时将证书保存在cookie中，通常是为了执行设计不佳的登录、密码修改、“记住我”等机制。攻击者通过攻击用户cookie即可获取这些证书(在Web安全(10)中会介绍这种方法)

许多应用程序对应用程序中未经验证的区域使用HTTP，而在登录时转而使用HTTPS。如果是这样，应在向浏览器加载登录页面时转换到HTTPS，使得用户能够在输入证书之前判断页面是否真实可信。但是，一些应用程序往往使用HTTP加载登录界面，而在提交证书时才转换到HTTPS，这种做法是不安全的，因为用户无法核实登录页面的真实性。这时，处在适当位置的攻击者就能拦截并修改登录界面，更改登录表单的目标URL以及使用的HTTP。

密码修改功能

定期强制修改密码可降低某一密码成为密码猜测攻击目标的可能性，同时降低攻击者不需要检测即可使用被攻破密码的可能性。虽然密码修改功能不需要验证即可访问，但在主要登录功能中特意避免的漏洞通常在密码修改功能中反复出现。许多Web应用程序的密码修改功能不需要验证即可访问，并为攻击者提供某些信息或允许攻击者执行某些操作。

• 提供详细的错误信息，说明被请求的用户名是否有效
• 允许攻击者无限制猜测“现有密码”字段
• 在验证现有密码后，仅检查“新密码”和“确认新密码”字段的值是否相同，允许攻击者不需入侵即可成功查明现有密码
  典型的密码修改功能通常包含一个相对较大的逻辑判定树，应用程序需要确认用户、验证提供现有的密码、集成任何账户锁定防御、对提交的新密码互相进行比较并根据密码强度规则进行比较，以及以适当的方式向用户返回任何错误条件。为此，密码修改功能通常包含难以察觉的用于破坏整个机制的逻辑缺陷。

忘记密码功能

重新获得忘记密码的机制常常会引入已在主要登录功能中避免的问题，如用户名枚举。忘记密码功能设计方面的缺点往往使它成为应用程序总体验证机制最薄弱的环节。下面介绍几种缺点：

• 忘记密码功能常常向用户提出一个次要质询以代替主要登录界面。对于攻击者来说，响应这种质询比猜测用户密码更为简单。
• 当应用程序允许无限制地回答密码恢复质询时，攻击者可以对其发动蛮力攻击
• 一些应用程序在用户成功完成一个质询后，立即让其进入一个不需验证的会话，这使得攻击者在攻破质询后可以无限制地使用该用户，而不会被账号所有者察觉
• 在用户正确响应一个质询后，应用程序允许用户重新控制他们的账户，这种机制非常容易受到攻击。执行这种机制的一个相对安全的方法是向用户在注册阶段提供的电子邮箱中发送一个唯一的、无法猜测的、存在时间限制的恢复URL，用户在几分钟内访问这个URL即可重置一个新密码
• 一些应用程序采用发送一个唯一的恢复URL的机制，但将这个URL发送至用户在完成质询时指定的电子邮箱中，除能够记录攻击者的电子邮箱外，这种方法根本无法提高恢复过程的安全性。
• 一些应用程序允许用户在完成质询后直接重置密码，并不会向用户发送任何电子邮件通知。这意味着直到所有者碰巧再次登录时才会注意到账户被攻击者攻破，或者账号所有者会认为是自己忘记了密码，于是用上述方法重置密码，这种情况下的所有者不会发现自己的账户已被攻破。

注：即使应用程序并未在屏幕上显示字段，要求用户输入接收恢复URL的电子邮箱地址，它仍有可能通过一个隐藏表单字段或cookie传送这个地址。攻击者此时即可以发现用户的电子邮箱，又可以对这个地址进行修改，用自选的地址接收恢复URL地址。

“记住我”功能

为方便用户，避免用户在同一台计算机上重复输入账号与密码，应用程序通常执行“记住我”功能。这项功能在设计上并不安全，致使用户易于遭受本地和其他计算机用户的攻击。

• 一些“记住我”功能通过一个简单的cookie执行，如RememberUser=peterwinener。向初始应用程序界面提交这个cookie时，应用程序信任该cookie，认为其属于通过验证的用户，并为该用户创立一个应用程序会话，从而避开登录过程。攻击者可以使用一组常见或已枚举出的用户名，不需要任何验证即可完全访问应用程序。
• 一些“记住我”功能设置一个cookie，其中并不包含用户名，而是使用一个持久会话标识符，例如RememberUser=1328。向登录页面提交这个标识符时，应用程序查询与其相关的用户，并为该用户建立一个应用程序会话
• 即使cookie中保存的用于识别用户的信息得到适当保护，但攻击者仍可通过跨站点脚本之类的漏洞或本地访问用户的计算机获得这些信息(请参阅Web安全(10)了解相关内容)

用户伪装功能

一些应用程序允许特权用户伪装成其他用户，以在该用户的权限下访问数据和执行操作(例如，一些银行应用程序允许服务台操作员口头验证一名电话用户，然后将银行的应用程序会话转换到该用户的权限下，以为其提供帮助)，这种功能存在的缺陷主要有：

• 伪装功能可以通过“隐藏”功能的形式执行，不受常规访问控制管理。(例如，任何知道或猜测出URL/admin/ImpersonateUser.jsp的人都能利用该功能伪装成任何其他用户(请参阅Web安全(7)了解相关内容)
• 当判定用户是否进行伪装时，应用程序可能会信任由用户控制的数据。例如，除有效会话令牌外，用户可能会提交一个指定其会话当前所使用的账户的cookie。攻击者可以修改这个值，不需验证即可通过其他用户的账户访问应用程序
• 某种伪装功能能够以简单的“后门”密码的形式执行，改密码可和任何用户名一起向标准登录页面提交，以作为该用户进行验证。如果攻击者对登录机制发动暴力攻击，并在匹配真实密码之前成功匹配后门密码，那么攻击者就可能发现后门密码功能，从而访问每一名用户的账户。

验证机制执行缺陷

多阶段登录机制中的缺陷

• 输入用户名和密码
• 响应一个质询，答案是PIN中的特殊数字或一个值得纪念的词
• 提交在不断变化的物理令牌上显示的某个值
  通常，多阶段登录机制首先要求用户通过用户名或类似数据项确认自己的身份，随后，登录阶段再执行各种验证检查，这种机制常常存在安全漏洞，特别是逻辑缺陷

注：多阶段登录机制不一定比标准的用户名/密码登录安全，如果一个多阶段登录机制存在多个执行缺陷，它甚至没有标准登录安全

在执行过程中，一些多阶段登录机制对用户与早先阶段的交互做出潜在的不安全的假设，比如：

• 应用程序可能认为访问第三阶段的用户已经完成第一、二阶段的验证。因此，它可能允许直接由第一阶段直接进入到第三阶段并且提供正确证书的攻击者通过验证，使仅拥有部分正常登录所需的各种证书的攻击者能够成功登录
• 应用程序可能会信任第二阶段处理的一些数据，因为这些数据已经在第一阶段得到确认。但是，攻击者能够在第二阶段操纵这些数据，提供一个不同于第一阶段的值。

不安全的证书存储

Web应用程序常常以危险的方式将用户证书存储在数据库中，这包括以明文形式存储密码。但是，即使使用MD5或SHA-1等标准算法对密码进行散列处理，攻击者仍然可以在预先计算的散列值数据库中查找观察到的散列。因为应用程序使用的数据库必须随时读/写这些证书，攻击者可以利用应用程序中的许多其他漏洞访问这些证书，例如，命令、SQL注入漏洞或访问控制漏洞

保障验证机制的安全

使用可靠的证书

• 应强制执行适当的最小密码强度要求
• 应使用唯一的用户名
• 系统生成的任何用户名和密码应具有足够随机性，其中不包含任何顺序，即使攻击者访问大量连续生成的实例也无法对其进行预测
• 允许用户设置足够强大的密码

安全处理证书

• 应以不会造成非授权泄露的方式创建、保存和传送所有证书
• 应使用公认的加密技术(如SSL)保护客户端与服务器端的所有通信。既无必要也无需要使用定制解决方案保护传输中的数据
• 如果认为最好在应用程序的不需验证的区域使用HTTP，必须保证使用HTTPS加载登录表单，而不是在提交登录信息时才转到HTTPS
• 只能使用POST请求向服务器传输证书，绝不能将证书放在URL参数或cookie中(即使临时放置也不行)。绝不能将证书返回给客户端，即使是通过重定向参数传送也不行。