pikachu靶场-1 暴力破解

暴力破解

暴力破解=连续性尝试+字典+自动化

一个有效的字典,可以大大提高暴力破解的效率

  • 常用的账号密码(弱口令),比如常用用户名/密码TOP 500等;
  • 互联网上被脱库后账号密码(社工库),比如CSDN当年泄露的约600万用户信息;
  • 使用指定的字符使用工具按照指定的规则进行排列组合算法生成的密码;

如果一个网站没有对登录接口实施防暴力破解的措施,或者实施了不合理的措施。则该网站存在暴力破解漏洞。

  • 是否要求用户设置了复杂的密码;

  • 是否每次认证都使用安全的验证码;

  • 是否对尝试登陆的行为进行判断和限制;

  • 是否在必要的情况下采用了双因素认证;

    等等… …

存在暴力破解漏洞的网站可能会遭受暴力破解攻击,但该暴力破解攻击成功的可能性并不是100%!所以有些网站虽然存在暴力破解漏洞,但其管理员可能会忽略它的危害。

但作为一个搞安全的,我们应该在系统设计的时候,就应该将这些措施加入到对应的认证场景中,绝不能为了妥协开发人员或者业务人员,有半点侥幸心理,否则被干了,哭的就是你了。

暴力破解漏洞测试流程:

  1. 确认登录接口的脆弱性

    确认目标是否存在暴力破解漏洞。(确认被暴力破解的可能性)

    比如:尝试登陆——抓包——观察验证元素和response信息,判断是否存在被暴力破解的可能。

  2. 对字典进行优化

    根据实际的情况对字典进行优化,提高爆破过程的效率。

  3. 工具自动化操作

    配置自动化工具(比如线程,超时时间,重试次数等),进行自动化操作。

字典优化技巧:

  1. 根据注册提示信息进行优化

    对目标站点进行注册,搞清楚账号密码的一些限制,比如目标站点要求密码必须是6位以上,字母数字组合,则可以按照此优化字典,比如去掉不符合要求的密码;

  2. 如果爆破的是管理后台,往往这种系统的管理员是admin/administrator/root的几率比较高,可以使用这三个账号+随便一个密码,尝试登陆,观看返回的结果,确定用户名。

    比如:

    • 输入xxx/yyy返回“用户名或密码错误”
    • 输入admin/yyy返回“密码错误”,则基本可以确定用户名是admin;

    因此可以只对密码进行爆破即可,提高效率。

实验

实验环境:Burp suite,pikachu

实验工具:Pikachu-暴力破解-基于表单的暴力破解

测试工具:burp suite(一个集成的web安全测试系统,有free和pro两个版本)

burp suite-intruder介绍

Intruder模块可以通过对http request的数据包以变量的方式自定义参数,然后根据对应策略进行自动化的重放。常用于自动化猜测,暴力破解过程中。

  • target选项卡

    设置攻击目标,可以通过proxy发送

  • Pasitions选项卡

    指定需要暴力破解的参数并设置成变量,同时选择攻击模式:

    • Sniper:狙击手

      设置一个payload,先将第一个变量使用字典进行测试,然后再将第二个变量使用字典进行测试;

    • Battering ram:冲撞车

      设置一个payload,所有的变量一起用字典内容被替换,然后一起尝试;

    • Ptichfork:草叉型

      每个变量设置一个payload,分别使用对应的字典对变量进行同时替换;

    • Cluster bomb:焦束炸弹

      需要为每个变量设置一个payload,分别使用字典内容组合对变量进行替换;

  • Payloads选项卡

    设置字典,并可以对字典进行统一的策略处理;

  • options选项卡

    对扫描的线程,失败重试等进行配置;

    对结果设置匹配的flag:通过一个标识符来区别结果,并在结果栏中flag出来

暴力破解的绕过与防范(验证码&Token)

我们一般用验证码来做什么?

  • 登陆暴力破解
  • 防止机器恶意注册

搞清楚验证码的认证流程:

  • 客户端request登陆页面,后台生成验证码:
    1. 后台使用算法生成图片,并将图片respose给客户端;
    2. 同时将算法生成的值全局赋值存到SESSION中;
  • 校验验证码:
    1. 客户端将认证信息和验证码一同提交;
    2. 后台对提交的验证码与SESSION里面的进行比较;
  • 客户端重新刷新页面,再次生成新的验证码
    • 验证码算法中一般包含随机函数,所以每次刷新都不一样

验证码可以防暴力破解,但你的验证码安全吗?

  • 不安全的验证码-on client常见问题
    • 使用前端js实现验证码(纸老虎);
    • 将验证码在cookie中泄露,容易被获取;
    • 将验证码在前端源代码中泄露,容易被获取;
  • 不安全的验证码-on server常见问题
    • 验证码在后台不过期,导致可以长期被使用;
    • 验证码校验不严格,逻辑出现问题;
    • 验证码设计的太过简单和有规律,容易被猜解;
防暴力破解的措施总结
  • 设计安全的验证码(安全的流程+复杂而又可用的图形);
  • 对认证错误的提交进行计数并给出限制,比如连续5次密码错误,锁定2个小时;
  • 必要的情况下,使用双因素认证;

token对防暴力破解的意义:

//生成一个token,以当前微秒时间+1个5位的前缀
function set_token(){
	if(isset($_SESSION['token'])){
	   unset($_SESSION['token']);
	}
	$_SESSION['token']=str_replace('.','',uniqid(mt_rand(10000,99999),true));
}

一般做法:

  1. 将token以 “type= ‘hidden’ ” 的形式输出在表单中;
  2. 在提交的认证的时候一起提交,并在后台对其进行校验;

但由于其token值输出在了前端源码中,容易被获取,因此也就失去了防暴力破解的意义。一般Token在防止CSRF上会有比较好的功效,具体在CSRF中在详细说说。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

游子无寒衣

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值