业务逻辑漏洞挖掘随笔开篇【身份认证篇】

在厂家的时候出来跟客户聊安全，老是喜欢把漏洞分为“传统漏洞”、“业务逻辑漏洞”。现在听到这词还蛮新鲜的。最近要让学弟们去帮忙挖漏洞，结合自己的测试经验顺便给他们归纳了下业务逻辑挖掘，于是有了本文....

 

由于这些年的测试并没有完整的汇总渗透案例中的图片，个别有的报告也属于客户隐私不好晒出来。没法图文并茂所以只能想到哪说到哪了。以文字描述为主。

思路：

　　1.概况：个人理解来说挖掘业务逻辑要先熟悉目标系统的“业务”。你可以动动鼠标流量下模板系统的大致功能和数据传输方式。这就像代码审计一样。先翻翻目录，整体了解下源码构造（总得知道函数放哪里、配置放哪里吧）。然后也可以本地把源码搭起来，从业务（功能）的角度去分析他。

　　2.不走寻常路：接触安全后就算是业余浏览网站，碰到些奇怪的url时会不自觉的加个单引号试试（好像没救了....）。也就是说要保持颗“好奇心”。大胆假设，谨慎验证。

　　3.善于总结：一个朋友当年的一句话让我印象深刻。“这个站看起来就像有洞的样子...”

 

为了不那么空洞，网上盗个图先（图上的提纲是别人总结的。但我会根据这些提纲分享自己的体会...）：

 

 纯科普，大牛请无视

 

暴力破解：

实习的时候帮客户检查系统，当实在没找到漏洞的时候最爱挑这个毛病，“该系统可被暴力破解”。因为内网中这问题比比皆是，暴力破解确实是个敲门砖。

　　01：没有验证码

　　　　

　　　　可选工具：burpsuite

       

 

      当然了，也可以选择同时爆破多个参数

 

02：形同虚设的验证码      

 　　另一种情况是有验证码，但是验证码却可以被重复利用。最简单的判断就是重复刷新页面，你会发现验证码没有改变。这类的目标你可以尝试下爆破。

　　 还曾经见过内网中的一套系统，有验证码，但是在抓包后，把验证码删掉。即使在没有验证码的情况下也能提交成功。

 

session & cookie类

　　会话固定攻击：利用服务器的session不变机制，借他人之手获得认证和授权，冒充他人。

　　场景一：某系统认证登录后，session存在于url中。我们通过伪造一个session+url的链接。发给对方，对方通过这个链接登录后。测试者本地即可直接利用该session。

　　场景二：在CTF比赛中和早期一些低级的留言系统可以碰到。用户是否具备访问权限，仅仅通过cookie中的参数来判断。此时，uid=admin，即可赋予admin的权限。（不要觉得傻逼，还真有==）

　　　　　　

 

 都是JS惹的祸：

　　场景一：给客户做安全培训的时候必讲的一个题。可以理解成越权访问。在未登陆的情况下直接访问某些管理员页面，会提示”未登陆，请重新登陆“然后跳转到登陆页面。这时候只要将浏览器的js禁用即可。这个问题在某国企多年内网漏洞挖掘中也发现多次。

　　场景二：在给某客户做安全评估，一套图书馆系统。都快睡着了。开着burpsuite一边抓包一边浏(踩)览(点)页面。在登录框输入一个存在的账号后发现有提交请求一次（看起来没毛病）。右键查看源码，问题来了。在密码框原来的 value=“” 居然变成了 value=“邪恶的密码”....。所以我已经猜到了这位开发同学的小九九。