zoukankan      html  css  js  c++  java
  • captcha-killer burp验证码识别插件初体验

    0x01 使用背景

    在渗透测试和src挖洞碰到验证码不可绕过时,就会需要对存在验证码的登录表单进行爆破,以前一直使用PKav HTTP Fuzzer和伏羲验证码识别来爆破,但是两者都有缺点PKav HTTP Fuzzer只能对简单的验证码进行识别,伏羲验证码识别需要自己制作验证码识别的模块需要耗费一定时间训练,而captcha-killer可以直接调用云打码平台的验证码识别接口可以带来一定的便利(花费钱的代价)。

    github项目地址:https://github.com/c0ny1/captcha-killer

    0x02 调用百度ocr识别验证码

    首先想到了调用百度ocr识别验证码,一天有5w次免费.

    创建一个应用然后记录API Key Secret Key用来获取Access Token具体可以看

    https://ai.baidu.com/ai-doc/REFERENCE/Ck3dwjhhu

    使用插件captcha-killer自带的baiduocr模板

    更改这两个地方为你的应用的接口地址和access_token

    多次试验以后发现百度OCR用来识别验证码的正确率非常低,而且百度OCR不支持gif格式的图片识别

    0x03 调用云打码平台识别验证码

    首先找了一个打码平台:http://www.ttshitu.com/

    冲了十块钱以后查看开发文档: http://www.ttshitu.com/docs/index.html#pageTitle

    构造http请求模板如下

    POST /base64 HTTP/1.1
    Host: api.ttshitu.com
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: Hm_lvt_d92eb5418ecf5150abbfe0e505020254=1585994993,1586144399; SESSION=5ebf9c31-a424-44f8-8188-62ca56de7bdf; Hm_lpvt_d92eb5418ecf5150abbfe0e505020254=1586146123
    Connection: close
    Content-Type: application/json; charset=UTF-8
    Content-Length: 2658
    
    {"username":"*","password":"*","typeid":"1","image":"<@BASE64><@IMG_RAW></@IMG_RAW></@BASE64>"}
    

    username password填自己的 typeid为识别的类型1代表纯数字,自己填写正则匹配验证码

    识别效果还是可以大概30个错一个的样子

    全部调整好了就可以在Intruder模块调用记住Intruder中的cookie要和验证码插件那里的cookie一样

    然后就可以开始爆破了

    测试后发现多线程会导致大量验证码错误,插件应该不支持多线程,验证码还没识别完成,已经被另一个线程刷新改变了

  • 相关阅读:
    web前端的发展态势
    AngularJs 简单入门
    css代码优化篇
    git提交报错:Please make sure you have the correct access rights and the repository exists.
    Activiti工作流框架学习
    遍历map集合的4种方法
    js设置日期、月份增加减少
    Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
    webservice_rest接口_学习笔记
    相互匹配两个list集合+动态匹配${}参数
  • 原文地址:https://www.cnblogs.com/cwkiller/p/12659549.html
Copyright © 2011-2022 走看看