渗透之路 思路【第二篇】爆破总结

暴力猜解简介

暴力猜解简单来说就是将密码进行逐个推算，直到找出真正的密码为止。

C/S 架构暴力猜解

C/S 即客户端/服务器,基于 C/S 架构的应用程序 如 ssh ftp sql-server mysql 等， 这些服务往往提供一个高权限的用户，而这个高权限的用户往往可以进行执行命令的操作， 如 sql-server 的 sa ，mysql 的 root，oracle 的 sys 和 system 帐号，使用这些高权限的用户能在很大程度上给开发人员带来方便，但如果口令被破解带来的危害也是相当大的。
C/S 架构主要使用的破解工具 Hydra、Bruter、X-scan

B/S 架构暴力猜解

一般是对 web 应用程序中的高权限用户进行猜解，如网站的内容管理系统账户。一般针对 B/S 的暴力猜解，使用 BurpSuit 进行表单爆破。

API 接口暴力猜解参考 https://xz.aliyun.com/t/6330

防范暴力猜解

防止暴力破解是非常简单的，无论是 B/S 架构或者是 C/S 架构，下面总结出以下几点。
1、密码的复杂性
2、验证码措施
3、登陆日志（限制登录次数）

验证码验证与绕过

验证码客户端验证与绕过

1.客户端生成验证码

验证码由客户端 js 生成并且仅仅在客户端用 js 验证

浏览器关闭js验证或者burp抓包

2.验证码输出客户端

输出在 html 中（神一样的程序员），无论出于什么考虑，都不应该把验证码的内容发送到客户端 cookie 或输出到 response headers 的其他字段。比如，写入验证码的 MD5 值、Base64 转码等，太容易被攻击者逆向破解，得到原值。即便是加固定 salt 后输出，都是很不好的。

3.验证码输出在cookie 中

有些系统默认不显示验证码，而是在用户校验错误一定次数之后再出现。那如何判断用户已经错误几次了呢？没有经验的开发可能这样做：

1.在 cookie 中写入一个标记，比如 loginErr = 1，后续错误累加
2.在 session 中写入一个标记，例如 loginErr = 1，后续错误累加

问题在于，要是攻击者不带 Cookie 提交 HTTP 请求呢？或者是，攻击者不更新 Cookie 中 loginErr 的值反复提交呢？这样程序会因为无从获取 Cookie/sessionID，会认为攻击者是首次访问。无论什么时候，验证码都不会出现！

验证码服务端验证与绕过

1、验证码不过期，没有及时销毁会话导致验证码复用(这个是最常见的,php 默认有 23 分钟才能自动销毁验证码)

多数时候，验证码在 web 服务器上对应一个 session 值。如果完成一次校验，不标记这个 session 已失效，就会造成同一验证码反复可用。此时，验证码将不再有用。攻击者在
cookie 中带固定的 sessionID 和固定的一个验证码字符串，即可轻松爆破。

另一种很常见的代码实现，更新 session 的工作是通过重新下载验证码达到的。而开发人员容易犯的一个失误，是把更新 session 的任务交给客户端浏览器。比如 302 重定向， 甚至是通过 js、meta refresh 重定向页面，来引导用户重新下载验证码。这些做法实际是错误的，要是用户拦截了重定向，没有发出新的下载请求呢？ 这样，上次的验证码是否还可以使用？

基本的认识是： 一张验证码，只能使用一次。使用之后，立即过期，不可再次使用

2、没有进行非空判断

很多时候，我们会遗留掉了验证过程中验证码为空的情况,比如去掉 cookie 中的某些值或者请求中验证码参数。

3、产生的验证码问题集内的答案非常有限

其它验证码验证与绕过

基于 Token 破解（参考 token 破解文档）

由于 token 值输出在前端源代码中，容易被获取，因此也就失去了防暴力破解的意义，一般
Token 在防止 CSRF 上会有比较好的功郊。

注意：线程数设为 1；Grep-Extract 设置好开始 token" value="    结束为" /> ；有郊载荷设为递归搜索

验证码太简单，容易被机器识别

一般，出现逻辑错误的验证码，同样存在太弱的通病，使用开源的 tessertact OCR 引擎，不经任何训练，不人工去噪处理，能识别互联网上的大部分验证码！

实战

一句话爆破

有时候我们可能有意外收获，得到很多初级黑客留下的马，那么可以直接捡漏