攻击验证机制

访客 2021年10月21日 09:26 317 0

本文来源:rongser

《黑客攻防技术宝典·web实战篇》第6章总结以及自己的一些拓展

前言

我在日常的挖掘edu以及公益src的过程中，各种漏洞扫描工具扫一遍后，若是没有明显的入手点，则会来到前期信息搜集的门户网站中进行更深一层次的挖掘。大部分企业高校的后台都布置在内网，一般我们是无法直接访问到的。并且常理而言，系统内部的安全机制会比系统外部的更加薄弱，更有可能拿到shell。

验证机制处于防御未授权访问的最前沿，攻破了这些防御，我们通常能够控制应用程序的全部功能（比如我们攻破了网站后台程序我们就可以随意在网站添加信息，而且一般网站后台也会有文件上传功能，甚至有网站管理人员或者公司的敏感信息），缺乏安全稳定的验证机制，其他的核心安全机制（会话管理和访问控制）都无法有效的实施。

验证技术

目前市面上大部分的站点都是采用的基于HTML表单的验证，也就是在web页面输入账号密码的验证方式，在这里就不再赘述。

除此之外书中还补充了一些其他的验证技术，如：多元机制（如组合型密码和物理令牌），客户端SSL证书或智能卡，HTTP基本和摘要验证，使用NTLM或kerberos整合Windows的验证，验证服务。

这些验证技术我都没有遇到过（太菜了），入门尚浅，还希望有大佬在评论区能描述一二。

验证机制设计缺陷

弱口令

本书是10年前出版的了，当时有相当一部分的web程序还没有对账号的密码的强度做安全控制，有相当一部分的用户喜欢设置类似于123456或者password这种口令，或者以自己的名字，自己的生日作为自己的密码。

这就导致攻击者可以轻易通过猜测或者对被攻击者的社交网站进行分析得到的信息来生成一个用户的密码字典，从而攻破账户。

而如今绝大部分的网站都对密码的强度做了要求，要求密码长度在8位以上，并需要同时含有大小写字母以及数字。这使纯暴力破解门户网站的难度大大增加，同时网站也采用了锁定机制，即短时间内访问速度过快或者访问次数达到某一限制就会封锁账号。

允许爆破攻击

如上文所说，网站没有做任何的锁定机制，允许外来用户通过枚举的方式确定密码。

这类设计在一些很偏僻的后台系统上还有经常会出现，若是面向客户的门户系统，几乎不可能出现。

若是应用程序在锁定账户后，任然会对登录尝试做出响应，这意味着即使目标账户被锁定，攻击者依旧可以完成对密码的猜测。

若是登录失败计数器保留在本地（如cookie或者session）我们可以通过修改cookie的值如（cookie：failedlogins=1）或者获得一个全新的会话，来继续实行密码猜测攻击。

详细的失败消息

有时候服务端返回的失败的消息中会告诉你信息出错的位置，例如：用户名不存在，密码错误。

这种情况下，我们可以发动自动化攻击来遍历大量的常见的用户名，我们可以将枚举出来的用户名作为随后各种攻击的基础。

PS：这种漏洞可能以更加隐蔽的方式出现，两个返回包渲染的结果可能看起来完全相同，但是它们两个包之间可能存在一些细微的差异。即使应用程序对包含有效与无效用户名登录尝试的响应完全相同，我么依然可以通过根据应用程序响应的时间来枚举出用户名。应用程序通常依据登录请求是否包含有效用户名，对其进行不同的后端处理，即使这种操作会产生大量的无效用户名，但是100个用户名的50%的有效率远远强于10000个用户名0.5%的有效率。