对某旅游网一次授权的漏洞挖掘

0x00走马观花

打开网页，我们先走一遍正常流程，然后注册了两个账号。因为我有短信接收平台，所以用的不是自己的手机号

我们注册的账号有

账号:nanfang1密码:nanfang1

账号:nanfang2密码:nanfang2

0x01马不失蹄-CSRF

  CSRF概念：CSRF跨站点请求伪造(Cross—Site Request Forgery)，跟XSS攻击一样，存在巨大的危害性，你可以这样来理解：
    攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。 如下：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。

      CSRF攻击攻击原理及过程如下：

• 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

• 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

• 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

• 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

• 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。 

常见的CSRF易于挖掘和使用。但大多数系统都会向它们添加保护，例如：每个用户都有相应的令牌

如果我们的CSRF漏洞请求模式发布，那么我们可以尝试修改它以获取请求模式。如果是get请求，它将修改为帖子请求，如上所述。在这样做时，系统可能没有适当的保护手段。

Hypothesis：

可更改为：

绕过CSRF令牌保护

我们可以删除或发送空白令牌

Deleting or sending a blank token to bypass is usually due to a system logic error.

As shown below:

Delete token:

Or send a blank token:

那么我们就来开始我们的攻击

我们打开抓包工具bp，先修改一下密码，发现修改成功

会发现修改成功，而且不需要原密码。我们直接配置代理，看看是否存在csrf漏洞

抓包看看

会发现并不存在token校验，直接制作一个poc进行利用

本地打开

登录另外一个账号，看看能否修改成功

可以看见成功修改而且成功登录，证明存在csrf漏洞

0x02马不失蹄-短信任意轰炸

    短信验证码常被用于网站用户注册、账户安全登录以及忘记密码、确认下单等应用场景，特别是一些涉及到用户个人敏感行为时候，为了确认操作是用户本人执行的通常会使用短信验证码进行二次认证。

    在实际应用中，有很多产品的短信验证码接口存在诸多逻辑漏洞，针对手机短信验证码可能存在的问题，这里总结常见的逻辑漏洞如下，供大家参考：

    1、短信验证码接口没有设置下发频次

    ①无限制，任意下发；

    ②有一定时间间隔，无限下发；

   短信验证码接口没设频次上限导致短信轰炸。这种情况往往出现在一些小站或者子站，这几年很少看到通过GET请求发送短信验证码了，基本都是使用POST请求，使用抓包软件可以重放请求对于后端没有做限制的网站就可以达到短信轰炸的效果。

   危害：对用户来说个人生活受到骚扰，对企业来说造成一定的负面影响，很多小公司因为短信验证码接口被大量调用出现运营问题，对于公司没有安全工程师的情况下，一般都是业务方发现了数据异常向上汇报，最后和开发一起反溯才会找到这个问题，那么在这段时间中对企业所损失的钱也是无法挽回的。

   预防：这里主要是针对两种攻击场景来进行防御，第一种是对单用户的短信轰炸，即重放发送请求且phonenum为一个值。第二种是对多用户发送短信骚扰的场景，即将phonenum参数设置为字典，重放短信验证码接口。

    ①设置发送间隔，即单一用户发送请求后，与下次发送请求时间需要间隔60秒。

    ②设置单用户发送上限，即设置每个用户单位时间内发送短信数的上限，如果超过阈值就不允许今天再次调用短信接口（阈值根据业务情况设置）。

    ③设置单IP发送上限，这种情况是预防第二种攻击场景的，由于IP的特殊性可能存在所处IP是大出口，一旦误杀后果会很验证，所以这个限制根据自身情况酌情考虑，对于有风控的团队来说，当发现发送IP存在异常可以对该IP增加二次认证来防止机器操作，也可以降低误杀情况。

    2、无效验证

    有验证码模块，但验证模块与业务功能没有关联性，此为无效验证，一般在新上线的系统中比较常见。

    ①获取短信验证码后，随意输入验证码，直接输入两次密码，可成功更改用户密码，没有对短信验证码进行验证，可能导致CSRF等问题。

    ②任意用户注册

    第一步，利用自己的手机号接收验证码进行验证，下一步跳转到一个设定密码的页面

    第二步，抓包，篡改手机号，使用任意手机号进行注册

    问题剖析：业务一致性存在安全隐患，身份验证与密码修改过程分开，验证无效。

    3、客户端验证绕过

    客户端验证是不安全的，可能导致任意账号注册、登录及重置任意用户密码等一系列问题。

    ①直接返回明文验证码

    ②返回密文验证码

    ③拦截替换返回包

    4、验证码与手机号未绑定

    一般来说短信验证码仅能使用一次，验证码和手机号未绑定，验证码一段时期内有效，那么就可能出现如下情况：

    1、A手机的验证码，B可以拿来用；

    2、A手机在一定时间间隔内接到两个验证码，都可以用。

    案例一：任意用户密码重置

    a、使用自己手机号收取验证码

    b、自己的验证码和对方的手机号填上，下一步城管设置新密码

    解决方案：

    1.在服务器进行有效验证，手机号和验证码在服务器进行唯一性绑定验证。

    2.在服务端限制验证码发送周期，设置时效，限制次数。

开始实战

我们去重新注册一个账号，用的是自己的手机号:1311*******

账号:nanfang

然后去找回密码的地方看看，能不能任意发送短信

看得到这是一个GET请求，FindMobile=这里是我们的手机号

放到repeater看看多次重复有什么效果

可以多次重放且回显都是如此

可以看见，他并没有对短信发送间隔进行后端设置，导致了攻击者可以进行多次重放验证码短信