• 【web-攻击验证机制】(3.2.3)验证机制设计缺陷:“记住密码” 功能、用户伪装功能、证书确认不完善


    目录

    验证机制设计缺陷:

    1.1、“记住密码” 功能

    简述:

    过程:

    1.2、用户伪装功能

    简述:

    各种设计缺陷

    过程:

    1.3、证书确认不完善

    简述:


    验证机制设计缺陷:

    1.1、“记住密码” 功能

    简述:

    为方便用户, 避免他们每次在一台特定的计算机上使用应用程序时需要重复输入用户名和密码,应用程序通常执行“记住密码” 功能。这个功能在设计上并不安全, 致使用户易于遭受本地和其他计算机用户的攻击。

    一些“记住密码” 功能通过一个简单的cookie执行,如RememberUser=peterwiener,向初始应用程序页面提交这个cookie时, 应用程序信任该cookie, 认为其属于通过验证的用户,并为该用户建立一个应用程序会话,从而避开登录过程。攻击者可以使用一组常见或已枚举出的用户名, 不需要任何验证即可完全访问应用程序

    一些“记住密码” 功能设置一个cookie, 其中并不包含用户名, 而是使用一个持久会话标识符, 例如RememberUser=1。向登录页面提交这个标识符时, 应用程序查询与其相关的用户, 并为该用户建立一个应用程序会话。和普通会话令牌一样, 如果可预测或推断出其他用户的会话标识符攻击者就可以遍历大量可能的标识符, 找到与应用程序用户相关联的标识符, 不经验证即可访问他们的账户。

    即使oookie中保存的用于重新识别用户的信息,得到适当保护(如被加密) , 以防止其他用户对此进行推断或猜测, 但攻击者通过跨站脚本之类的漏洞或本地访问用户的计算机依然可以轻易获得这些信息


    过程:

    1、激活所有“记住密码” 功能, 确定应用程序是否完全"记住" 用户名和密码, 还是仅记住用户名, 仍然要求用户在随后的访问中输人密码。如果采用前一种设置, 该功能就很大可能存在安全漏洞

    2、仔细检查应用程序设定的所有持久性cookie, 以及其他本地存储机制中的持久性数据,如UserData、Seilverlight的隔离存储、Flash的本地共享对象。寻找其中保存的任何明确标识出用户或明显包含可预测的用户标识符的数据

    3、即使其中保存的数据经过严密编码或模糊处理, 仔细分析这些数据,并比较"记住"几个非常类似的用户名或密码的结果, 找到任何可对原始数据进行逆向工程的机会

    4、试图修改持久性cookie的内容, 并设法让应用程序确信·另一名用户已经将其资料保存在你的计算机中

    1.2、用户伪装功能

    简述:

    一些应用程序允许特权用户伪装成其他用户, 以在该用户的权限下访问数据和执行操作。如银行应用程序允许服务台操作员口头验证一名电话用户, 然后将银行的应用程序会话转换到该用户的权限下, 以为其提供帮助。


    各种设计缺陷

    1、伪装功能可以通过“隐藏” 功能的形式执行, 不受常规访问控制管理。任何知道或猜测出URL/admin/ImpersonateUser.jsp的人都能够利用该功能伪装成任何其他用户

    2、当判定用户是否进行伪装时, 应用程序可能会信任由用户控制的数据。除有效会话令牌外, 用户可能还会提交一个指定其会话当前所使用的账户的cookie。攻击者可以修改这个值, 不需验证即可通过其他用户的账户访问应用程序

    3、如果应用程序允许管理用户被伪装,那么伪装逻辑中存在的任何缺陷都可能导致垂直权限提升漏洞。攻击者不仅可以访间其他普通用户的数据, 甚至可以完全控制应用程序

    4、某种伪装功能能够以简单”后门” 密码的形式执行, 该密码可和任何用户名一起向标准登录页面提交, 以作为该用户进行验证。由于许多原因, 这种设计非常危险, 但攻击者所获得的最大好处是他们可在实施标准攻击(如对登录机制进行蛮力攻击)的过程中发现这个密码。如果后门密码在用户的真实密码前得到匹配, 那么攻击者就可能发现后门密码功能, 从而访问每一名用户的账户。一次蛮力攻击可能导致两个不同的"触点”, 因而揭示后门密码


    过程:

    1、确定应用程序中的所有伪装功能。即使公布的内容中没有明确的伪装功能链接, 应用程序仍然可能实施这种功能

    2、尝试使用伪装功能直接伪装成其他用户

    3、设法操纵任何由伪装功能处理的用户提交的数据,尝试伪装成其他用户(特别留意任何不通过正常登录页面提交用户名的情况)

    4、如果能够成功利用伪装功能, 尝试伪装成任何已知的或猜测出的管理用户, 以提升用户权限

    5、实施密码猜测攻击时, 查明是否有用户使用多个有效密码, 或者某个特殊的密码是否与几个用户名匹配。另外, 用在蛮力攻击中获得的证书以许多不同的用户登录, 检查是否一切正常。特别注意任何“以X登录”的状态消息。

    1.3、证书确认不完善

    简述:

    1、精心设计的验证机制强制要求密码满足各种要求, 如最小密码长度和同时使用大小写字符。一些设计不佳的验证机制不仅没有强制执行这些最佳实践, 而且对用户遵守这些要求没有严格控制

    2、一些应用程序截短密码, 只确认前n个字符, 一些应用程序并不对密码进行大小写检查, 一些应用程序在检查密码之前删除不常用的字符(有时以执行输入确认为借口)。一些相当有名的应用程序都被确认具有此类行为,一些好奇用户的试验和错误致使人们发现了这一问题

    3、密码确认限制可显著减少可能的密码数量。使用一个现有的账户, 尝试用密码的各种变化形式进行登录删除最后一个字符、改变字符大小写、删除任何特殊排版的字符。如果其中一些尝试取得成功, 继续实验过程, 尝试了解完整的证书确认过程

    4、通过测试,可以判定一个密码是否得到完全确认, 或者某个限制是否生效。然后就可以针对登录机制的自动攻击方法进行调整, 删除不必要的测试, 大量减少攻破用户账户所需提交的请求的数量。

  • 相关阅读:
    【C#语言】WinForm窗体
    python非线性规划
    WPF的由来
    Monitoring techniques in AWS
    ABAP MR21: BAPI_MATVAL_PRICE_CHANGE
    sitemap.xml生成(go语言版)
    【Vue】水果购物车-基本渲染
    分布式任务调度项目xxl-job
    WEB攻防【4】——JavaWeb项目/JWT身份攻击/组件安全/访问控制
    后端接口性能差,该从哪些方面进行优化?
  • 原文地址:https://blog.csdn.net/qq_53079406/article/details/126331451