1.11 逻辑漏洞

逻辑漏洞是指程序员开发的程序在逻辑上不严谨，欠缺对安全因素的考虑，导致产生了一些不可预知的情况，从而形成漏洞。

对于逻辑漏洞的挖掘，通常依靠人工检测，准确率高但是效率很低，而常规的漏洞检测工具很难检测出来逻辑漏洞。逻辑漏洞的利用过程通常是正常访问流量，找到漏洞利用点之后一般不需要发送恶意请求，这导致常规的防护手段或者防护设备无法起效。单个的逻辑漏洞危害也许不大，如果几个逻辑漏洞组合起来往往能扩大危害。

1.11.1 登录体系安全

1.验证码安全

验证码安全问题比较常见，一般是指网站登录页面的验证码不生效，仅前端对用户输入的验证码进行校验，后端未验证，或者验证码可以被工具轻松识别，导致的安全问题是攻击者可以对网站前台或后台进行暴力破解。

案例分析：某信息管理系统验证码不生效导致暴力破解问题。

在找到网站管理员后台后，我们可以尝试暴力破解管理员的账号和密码。发现登录页面有验证码，为了测试验证码是否生效，我们可以随意输入账号、密码和正确的验证码，然后登录并用Burp Suite抓包，将抓到的包多次发送到Repeater模块。查看服务端返回的信息，如果服务端提示验证码无效，证明后端对用户输入的验证码进行了校验，如果只是提示账号或密码错误，基本可以判断后端没有对验证码进行校验。如图1-242所示，根据服务端的返回值，判断后端没有对验证码进行校验，我们可以尝试暴力破解账号和密码。

经过一番暴力破解，发现管理员账号的确是弱口令，登录成功。

2.登录凭证安全

有些App或网站为了让用户体验更好，采用手机号验证码登录或注册的方式。如果使用的是比较弱的登录凭证，比如纯数字的4位手机验证码，并且后端没有对验证码尝试次数和有效时间进行限制，那么这个凭证就是不安全的。

案例分析：某App存在任意用户登录漏洞。

在某App的漏洞挖掘中，发现可以直接用手机号接收短信验证码的方式登录。经测试发现，输入手机号发送验证码时服务端会进行判断，如果账号不存在，输入正确的凭证就会自动注册，如果账号存在，输入正确的凭证就会成功登录。

根据手机实际收到的短信验证码，发现短信验证码为4位数字，并且有效时间为30分钟。猜想可能存在任意用户注册和任意用户登录漏洞，使用验证码登录时直接抓包爆破验证码的值，结果不出所料，如图1-243所示，成功实现任意用户登录。

1.11.2 业务数据安全

在众测中，如果碰到电商类线上支付的项目可以尝试挖掘支付漏洞，涉及金额的漏洞一直是企业重点关注的问题。

1.订单金额篡改

订单金额篡改漏洞是一种支付漏洞，一般是指攻击者通过技术手段篡改订单的金额，使攻击者以极低的价格购买商品。订单金额篡改漏洞产生的原因往往是服务器没有对生成订单的商品金额进行校验，从而使商品金额可以被攻击者控制。

常见的测试流程一般是生成订单时或生成订单后在支付时抓包，直接修改数据包中的金额。这个金额参数也可能被改成负数，有些网站在以负数金额支付订单时，甚至会反向将金额充值到攻击者的账户余额里。

案例分析：某电商平台因订单金额篡改而导致低价购物。

攻击目标是一个电商类网站，在商城中选好商品并且填写收货信息后，点击微信支付时抓包进行查看，如图1-244所示，发现o参数是Base64编码的订单信息。

将此数据包发送后，服务端会返回一个链接，该链接为支付接口加订单编号，用微信访问就可以正常支付了。由于订单信息是经过Base64加密的，因此将信息解密后逐一分析，如图1-245所示。

从解析结果我们可以大致分析出，productId参数是商品ID, buyCount参数是商品数量，productFee参数是商品金额。攻击思路是将订单信息进行Base64解密后修改productFee参数的值，修改后重新进行Base64加密，将重新加密后的订单信息发送给服务器，获取订单号并支付。

实际测试后发现这种办法行不通，从解密结果来看有一部分是乱码信息，因为订单信息中包含了中文姓名、收货地址等内容，修改价格后重新编码会出现乱码，导致服务器不能正常解析。一个简单的绕过方法是将Base64加密后的订单信息进行截取，只保留带有价格的部分，解密后修改价格并重新编码，将Base64字符串进行拼接，如图1-246所示。

将修改好的Base64字符串发送给服务器，发现成功获取支付链接，如图1-247所示。

用微信访问服务器返回的URL进行低价支付。在测试订单金额篡改这类漏洞时，切记测试过程中点到为止，可以证明漏洞危害即可。

2.商品数量篡改

商品数量篡改漏洞是指攻击者通过技术手段篡改订单内商品的数量，如果服务端没有经过校验就直接计算商品价格与商品数量（商品单价×商品数量=商品价格），很可能会导致此问题。

测试方法比较简单，与订单金额篡改类似，例如将一个售价100元的商品A加入购物车时抓包，将商品A的数量改为0.01个，此时去购物车里查看，发现有一个售价为1元的商品A，商品A的数量为0.01个。

案例分析：某电商平台因商品数量篡改而导致低价购物。

攻击目标是一个中老年人体检的电商网站，首先尝试篡改金额，发现商品ID是和价格绑定的，直接篡改金额会提示价格错误。继续尝试将商品加入购物车时修改商品数量，发现购物车里的商品价格会随着商品数量而变化。

首先选定一个商品，添加到购物车时抓包，将商品数量改为小数例如0.00001，如图1-248所示。

修改后查看购物车，发现商品价格变为0.01元，如图1-249所示，可以直接支付。

在这个案例中，我们首先尝试了直接修改商品价格，发现修改失败，因为每个商品都有一个ID值，并且这个值与商品价格绑定，随后尝试将商品加入购物车时修改商品数量，最终成功利用。

3.并发漏洞

在操作系统中，程序并发执行是指一组程序的执行在时间上是重叠的。并发进程可能是无关的，也可能是交互的，无关的并发进程是指分别在不同的变量集合上操作，而交互的并发进程共享某些变量，一个进程执行可能会影响其他进程的执行结果，交互的并发进程之间具有制约关系。因此，交互的并发进程必须是受控制的，否则会出现不正确的计算结果，从而产生并发漏洞。

从业务逻辑方面举例，假设在某个网站上有1000元的账户余额，并且网站提供余额提现功能。正常情况下，如果每次提现100元，最多可提现10次，共到账1000元。如果攻击者进行多线程并发请求提现，每次提现100元，提现程序因为数据库没有加锁或没有进行同步互斥等原因存在并发漏洞，那么攻击者在极短的时间内共发起申请提现请求12次，预计到账1200元，超过了原有的1000元余额。

案例分析：某商城兑换功能存在并发漏洞。

用户A的账户中有1000个金币，某天他看到商城上线了他心仪已久的商品FLAG，每个FLAG售价100个金币。

正常情况下用户A只能兑换10个FLAG，如图1-250所示。贪心的他并不知足，打算尝试新学到的并发漏洞，看能否兑换更多的FLAG。

首先在兑换页面填好信息，兑换商品时抓包，如图1-251所示。

然后将数据包发送到Burp Suite的Intruder模块中，将系统自动设置的参数全部清除，Payloads设置为Null payloads，如图1-252所示。此次并发漏洞场景不需要爆破任何参数，只需要Burp Suite多线程一直发包。

然后在Options选项页面将线程数修改为20，如图1-253所示。基本设置完毕后点击Start attack按钮，开始发包。

最后成功利用并发漏洞兑换了20个FLAG商品，查看金币记录可以发现，这些数据有一部分是错误的。正常情况下购买商品后金币数量应当每次减少100个，而利用并发漏洞兑换商品时，兑换完一个商品后金币没有发生变化，甚至金币降为0后也能继续兑换几个商品，如图1-254所示。

这就是一个简单的并发漏洞案例，据笔者所知，国内多家漏洞平台的积分兑换系统曾经存在类似的并发漏洞，目前早已修复。建议读者多学习公开的漏洞报告，相信会有所收获。

1.11.3 会话权限安全

1.未授权访问

未授权访问漏洞一般指用户在没有通过认证或无任何凭证的情况下能够直接访问需要通过认证才能访问的页面或网站数据信息。

未授权访问漏洞往往是因为没有强制对用户所访问的页面或资源进行验证，未授权访问不单指网站的资源未授权访问，它是一种漏洞类型的统称。常见的未授权访问漏洞还可能出现在各类组件中，往往都是由于管理员配置错误导致的，例如Redis、Docker、JBoss等。

对于未授权访问漏洞的危害，主要看未授权漏洞发生在哪里，如果是未授权访问网站后台，影响就会比较大，攻击者可以利用这个漏洞点继续进行深入攻击。

案例分析：某企业运营后台存在未授权访问漏洞。

通过对该企业主域名进行爆破，得到了一个子域名，访问后发现是该企业的运营系统后台。运营系统后台登录页面中规中矩，看起来没什么问题。通过对网站的URL进行爆破，得到了一个后台页面的未授权访问，结果如图1-255所示，在这个后台页面泄露了大量的用户信息，并且可以直接编辑，利用这些信息成功打点得以深入攻击。

对于未授权访问漏洞的挖掘技巧，这里列举三点。

● 利用搜索引擎搜索站点，寻找可疑的URL。

● 重点关注一下API接口，可以通过Fuzz、查看JavaScript文件等手段进行测试。

● 有时未授权访问后台页面，会有后台页面一闪而过，这时可以尝试用Burp Suite等工具丢弃Token认证请求包。

2.水平越权

水平越权指的是相同用户角色级别之间发生越权操作，即用户A可以访问或修改用户B的个人信息。一般的水平越权测试方法是修改ID值后查看页面返回结果，比如在某个网站注册了账号，查看个人用户信息时发现页面的URL为http://xxx.com/getUserinfo.php?userid=1122，此时显示的是自己的个人信息，我们发现URL中存在一个userid参数，这时尝试修改userid的值为1，即URL变更为http://xxx.com/getUserinfo.php?userid=1，页面显示的信息就变成了其他人的个人信息，这就是一个简单的水平越权漏洞。

水平越权的发生场景很多，涉及对数据进行增删改查的功能就容易出现水平越权，比如用户信息遍历、订单遍历、收货地址遍历、使用他人收货地址下单、使用他人简历投递等。

水平越权漏洞产生的原因是用户在请求对数据进行增删改查时，后端程序没有对该用户是否可以合法操作此数据进行校验。

案例分析：某购物App存在水平越权漏洞。

我们首先注册账号并登录这个购物App，接着在收货地址处写两条正常的收货地址。

在编辑收货地址或删除收货地址时抓包，发现有id、loginMemid、loginToken参数，并且id参数的值是纯数字类型，如图1-256所示，这意味着我们可以尝试遍历id值。

我们修改id值为5711并不会越权访问成功，因为程序对loginToken参数进行了校验。我们只须删除另外两个参数，只留下一个id参数即可越权成功，再次查看发现可以编辑其他人的地址信息，如图1-257、图1-258所示。

在这个案例中，常规的修改id参数值的方式并不可行，因为服务端对数据包里的loginToken也进行了校验，为的就是防止发生越权漏洞，可是程序员忽视了攻击者可以抓包删除校验参数这种情况，从而导致了漏洞的产生。

3.垂直越权

垂直越权指的是不同用户角色级别之间发生的越权操作，一般来说是以低权限的用户去执行高权限用户的操作。例如超级管理员（admin）可以在后台进行添加账号、删除账号等操作，普通管理员（user）在后台就找不到添加账号的功能，这时如果普通管理员想办法得到了超级管理员添加账号功能的接口，并且经过测试发现可以成功添加账号或删除账号，这时就发生了垂直越权行为。垂直越权漏洞产生的原因是后端程序没有对当前用户发送的请求进行权限校验。

这里分析一个有意思的垂直越权案例：某系统SSO（Single Sign On，单点登录）垂直越权。

一般企业在SSO中整合了多个应用系统，用户只需要登录一次就可以访问此用户权限范围内的应用系统。在一次测试过程中，发现某系统存在SSO垂直越权漏洞，具体利用过程：先以普通权限用户登录SSO系统，接着访问SSO里的应用系统，如果对应的系统中存在本账号就会认证成功，否则会提示系统中无此用户，如图1-259所示。

通过观察URL发现，uid参数指定了用户名，既然用户名“020002”认证失败，如果将uid参数的值改为admin会产生什么效果呢？结果如图1-260所示，直接以超级管理员身份登录了系统。

继续对其他系统进行测试，发现除了修改URL中用户参数这种越权方法，还有一种方法是修改POST请求包里认证用户名参数为要登录的用户名，可以直接垂直越权登录，原理相同。如图1-261、图1-262所示，将参数值改为admin直接以超级管理员身份登录了该系统。

这个案例就是典型的垂直越权漏洞，产生的原理也很简单，SSO系统对用户名和密码进行验证，登录成功后，以当前认证成功的SSO用户访问对应的系统，应用系统接收SSO的认证信息，并且会再次对比SSO认证的用户名，如果用户名在子系统中存在就认证成功，否则认证失败。问题就出在这里，当应用系统再次对比SSO认证的用户名时，仅校验了用户名，并未对比SSO认证信息，因此可以直接篡改用户名进行垂直越权访问。

1.11.4 密码重置漏洞

1.用户凭证暴力破解

用户凭证暴力破解是指服务端向用户发送的用来重置用户密码的凭证可以被暴力破解。其产生的原因主要是服务端利用了比较弱的验证机制，在利用弱验证机制的同时也没有对凭证的有效时间和错误尝试次数进行限制。这里假设凭证是一个4位纯数字的手机短信验证码，没有限制错误尝试次数，短信验证码有效期为30分钟。这样的利用条件就形成了任意用户密码重置漏洞，因为4位纯数字的短信验证码仅有不到一万条，暴力破解几分钟就可以完成。

案例分析：某快递App任意用户密码重置漏洞。

首先以自己的手机号进行正常注册，注册完毕后退出App。然后尝试重置自己的账号，输入手机号，发送验证码。最后手机验证码为4位数字，30分钟内有效，如图1-263所示。

随意输入一个验证码，点击“重置密码”时抓包，如图1-264、图1-265所示。

暴力破解验证码为“2384”，密码成功重置，结果如图1-266所示。

从这个案例中我们可以看出，4位数字验证码很容易就会被破解，现在很多厂商已经将4位验证码换成了6位验证码，但是6位验证码也有被成功破解的案例，如果不限制验证码的错误尝试次数以及有效时间，那么这个问题就无法从根源上解决。在这里提醒大家在测试时一定要用自己的手机号，仅证明危害即可。

2.回显用户凭证

回显用户凭证是指用户找回密码时，服务器返回的响应包里包含用户找回密码的凭证。例如找回密码时，点击“发送验证码”按钮后抓包，将数据包发送到Burp Suite的Repeater模块，再次发送数据包，在服务器响应包中发现回显了验证码。

这种漏洞的利用条件相较于用户凭证暴力破解更为简单，只须在正常的找回密码功能中输入任意一个手机号，在响应包中就能得到短信验证码，进而重置对方账号。

案例分析：某平台任意用户密码重置。

在平时的众测中，如果遇到主站漏洞比较难挖掘的情况，可以尝试从其他业务子站进行测试。如果主站的用户数据与业务子站的用户数据是通用的，那么一旦子站出现漏洞，就会影响主站，漏洞危害也就提升了。

在一次众测中，对目标主站进行了简单的测试，然而并没有成果。接着发现了目标主站旗下有一个金融网站，以主站注册的账号去登录该金融网站，发现可以成功登录，这也就意味着主站的用户数据与这个金融网站的数据是通用的。

继续测试这个金融网站，在找回用户密码时发现了问题：发送重置密码的短信验证码时，短信验证码回显在了服务端的响应包里，如图1-267所示。

为了验证回显的验证码是正确的，我们可以对比一下真实收到的短信验证码与服务端回显的短信验证码是否一致，如图1-268所示。

使用回显的短信验证码成功重置了密码，如图1-269所示。

用重置后的账号密码尝试登录目标主站，发现可以成功登录，这就验证了主站用户数据与子站用户数据是通用的，成功将漏洞危害从“业务子站任意用户密码重置漏洞”升级为“主站任意用户密码重置漏洞”。

3.原密码未校验

原密码未校验漏洞在任意用户密码重置中比较常见，一般是指用户自主修改密码时，服务端没有强制对用户输入的原密码进行校验。原密码未校验漏洞再结合一个越权漏洞，就可以扩大危害，达到任意用户密码重置的效果。

案例分析：某公司存在任意用户密码重置漏洞。

注册并登录后，进入后台的个人信息修改页面，首先进行一个正常的修改密码流程，输入一个错误的密码进行修改时，页面提示“当前密码输入错误，请重新输入”，如图1-270所示，这说明服务端确实针对旧密码进行了校验。

我们在修改密码时抓包分析一下，如图1-271所示，当原密码错误时，服务端返回了false，并且是根据userId的值对原密码进行的判断，当userId的值与原密码匹配时才能修改成功。

经过测试发现，如果把oldPassword参数的值置空，或者直接删掉oldPassword参数，服务端都会返回true，利用这种方法简单绕过校验原密码的机制，成功修改密码，如图1-272所示。

案例到这里只进行了一半，因为只达到了在不校验原密码的情况下修改自己的密码，那么我们应该如何扩大危害重置任意用户的密码呢？

修改密码时，可以看到数据包里有一个userId参数，通过修改userId参数的值可以修改对应用户的密码，因为我们已经绕过了校验原密码机制，所以可以结合越权漏洞修改他人的密码，结果如图1-273所示。

4.越权修改任意用户

越权修改任意用户密码一般是多个逻辑漏洞组合在一起产生的，比如同时存在越权漏洞和任意用户密码重置漏洞，产生漏洞的主要原因还是权限分配问题。在有些场景下，如果能利用几个不同的逻辑漏洞打出组合拳，往往能突破限制，收获意想不到的效果。

案例分析：某云平台存在越权漏洞和任意用户密码重置漏洞。

首先注册账号，登录系统后发现自己是商户管理员权限，拥有添加商户子账号的功能。

随便添加一个商户子账户，新添加的子账号默认角色为副管理员，商户管理员可以重置子账号的密码，如图1-274所示。

点击重置密码时进行抓包，可以看到是根据Userid对用户进行密码重置的，如图1-275所示。默认情况下Userid是加密的，且无法解密，因此不能利用遍历Userid值的方法进行任意用户密码重置。

继续测试其他的功能点，找到了一处水平越权漏洞，在编辑子账号时抓包，发现发送了一个GET请求，请求的值是子账号的数字型id值，在服务端响应包里回显了用户信息，其中就包含了加密后的Userid。通过遍历数字型id值就可以越权查看他人加密后的Userid，如图1-276所示。

越权拿到其他用户的Userid后，重置子账号密码时尝试替换Userid。为了不影响业务，重置的是我们自己注册的另一个账号。越权重置密码成功，如图1-277所示。

1.11.5 CTF实战分析

1.2018-护网杯-Web-LTshop

题目背景是一个辣条商城，如图1-278所示。简单分析一下商城功能：每个新用户注册即送20元，5元可以兑换一个大辣条，5个大辣条可以兑换一个辣条之王，9999999个辣条之王才可以兑换flag。

由于我们的账户中只有20元，正常情况下只够兑换4个大辣条，无法兑换1个辣条之王。这时想到可以尝试并发漏洞，利用多线程跑包。测试后发现确实有效，用20元兑换了6个大辣条。但是利用这种方法是远远不够的，这种情况下只能考虑整数溢出。

兑换大辣条时进行抓包分析，发现cookie中有Go语言的字样，判断该商城是基于Go语言的某个框架编写的，查阅资料找到Uint64溢出方法。

2的64次方为Uint64的最大值，溢出后数值变为0，因为在兑换时程序会自动将数值乘以5，所以我们需要兑换的数量为2 ⁶⁴ ÷5+1=3689348814741910324。

之前利用并发漏洞兑换了6个大辣条，满足兑换辣条之王的条件，兑换辣条之王时将数量设置为3689348814741910324，成功溢出后就可以兑换flag了。

2.网络信息安全攻防学习平台-密码重置

题目考点是任意用户密码重置，访问题目并点击“忘记密码”链接，提示输入要重置的账号。在这里我们尝试重置管理员账号，页面显示“邮件已经发送admin的邮箱！”如图1-279所示，显然我们不能直接重置管理员的密码。

接下来尝试重置非管理员账号，结果如图1-280所示，返回了一个重置密码链接，观察发现sukey参数是比较关键的，猜测只要能拿到admin账号的sukey就能重置密码。

将获取的sukey进行MD5解密后发现是时间戳，再将时间戳转换为时间就明白了其中的原理，如图1-281所示。sukey的加密方式比较简单，仅仅是将时间戳进行MD5加密。

至此大概的思路就清楚了，我们首先重置admin账号的密码，然后获取重置时的时间，如图1-282所示。

接着将服务器的时间按照固定的格式转成时间戳，注意因为服务器时间和当前时间差了8个小时，所以需要加8个小时。再将时间戳进行MD5加密就得到了admin账号的sukey。最后访问构造好的重置密码链接就拿到了flag，如图1-283所示。

针对逻辑漏洞，本节只是简单地从业务方面进行了漏洞分类讲解和案例分析。由于CTF比赛中的逻辑漏洞题目比较少，覆盖的知识点也不够全面，因此本节漏洞案例分析都来自实际漏洞挖掘。

现实生活中的逻辑漏洞还是比较常见的，建议读者多多思考本节介绍的案例，多动手尝试，定能发现其中的乐趣。在这里也提醒广大读者切记发现问题及时上报，不要随意测试影响厂商业务。 RRqXZMyAvNqomyhZvV+TDn3V11TBPRPKqPLacBLI/r00bu+nLYOq7mZjWfAsKlbg