《黑客攻防技术宝典·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%的有效率。

易受攻击的账号密码的传输

现如今的绝大部分的鉴权口令采用的都是HTTPS加密后的post传输手段，可任然有一定数量的网站采用的是明文传输的方式。攻击者可以轻易的通过监听一些节点（如本地的wifi，用户的ISP内）即可得到用户的账号信息。

密码修改功能

其功能的必要性

• 定期强制修改密码可降低某一密码成为密码猜测攻击目标的可能性，同时降低攻击者不需要检测即可使用被攻破密码的可能性
• 怀疑自己密码被攻破的用户需要立即修改密码，以降低未授权使用频率

可能存在的问题

• 提供详细的错误消息，允许攻击者猜测用户名信息
• 允许攻击者猜测现有密码字段（不允许新密码与旧密码重复）

忘记密码功能

该书著于10年前，10年前的一些验证逻辑在如今有些已经不再采用，书中所提到的质询—回答的验证方式在如今已经几乎消失不见，曾记得在12年左右这种验证机制还是被普遍采用，如今忘记密码即修改密码。

用户伪装功能

一些应用程序允许管理用户伪装成其他用户，以该用户的权限来访问数据和执行操作。这个功能对于我这样一个小白而言其实并不常见，稍微能够理解一点的就是管理用户可以从高权限组进入到低权限组，就如linux中的root可以进入到其他用户，而其他用户若是要进入到root则需要输入相应的密码。

伪装逻辑中存在的任意缺陷都可能导致垂直越权漏洞，攻击者不仅可以访问其他用户的数据，甚至可以获得管理员权限。

可预测的初始用户名和密码

系统可能会一次性或大批量的创建用户，用户名之间可能是某种可预测的顺序，密码则可能是某一初始密码或者也是某种可预测的顺序。

攻击者查看几个少数初始密码样本即可确定或猜解密码序列。

这种设置逻辑如果没有强制要求用户在第一次登录的过程中修改密码的话，那么大部分用户是不会修改初始密码的。

账号密码的确认不完善

有一些应用程序为了节省资源，在确认的过程中截断密码，仅确认前n个字符、或者并不对密码进行大小写检查、甚至允许输入密码规定范围之外的字符。

这种机制能够显著减少暴力破解的数量。

然而这种机制大部分应该都已经被时代给淘汰掉了，现如今这种服务器开销根本就不算事，也没必要去牺牲安全去节省这一点资源。

验证机制执行缺陷

故障开放登录机制

这是一种十分严重的逻辑漏洞，即使是没有正确的账号密码我们也可以利用这个漏洞进行登录，利用了用户的请求中没有用户名或密码参数出现的空指针异常。

多阶段登录机制中出现的缺陷

执行多次检查认证可能会显著提升登录机制的安全性，但相应的这个登录的过车也可能会存在更多的问题。

最常见的问题是可能应用程序在进行一次的身份验证后在后续的阶段就选择了信任上阶段的验证结果，而放弃了身份的确认，或者说信任上一个阶段所处理的一些数据。

总而言之就是各个阶段的信任的问题。