吴盼盼 俞嘉雯 韩冰青

摘  要： 漏洞扫描、WAF、IPS、APT探针平台等网络安全防护设备虽然能根据实体设置策略来动态侦测和阻止外部以及内部的网络攻击，但无法检测到基于系统逻辑漏洞的网络安全攻击，所以系统逻辑漏洞的挖掘十分重要。本文主要基于HTTP协议的数据包之间逻辑的分析，来进行Web系统的逻辑漏洞的挖掘，从而进一步加强系统的安全性。

关键词： 网络安全； 漏洞挖掘； Web系统； 逻辑漏洞

中图分类号：TP393          文献标识码：A     文章编号：1006-8228（2023）09-24-05

Web security logic vulnerability mining based on HTTP packets

Wu Panpan， Yu Jiawen， Han Bingqing

（Nanjing Audit University， Nanjing， Jiangsu 211815， China）

Abstract： Although network security protection devices such as vulnerability scanning， WAF， IPS， and APT probe platforms can dynamically detect and block external and internal system attacks according to entity setting policies， they cannot detect network security attacks based on system logic vulnerabilities， so it is very important to mine the system logic vulnerabilities. In this paper， we analyze the packet logic of the HTTP protocol to mine the logical vulnerabilities of the Web system， so as to further strengthen the security of the system.

Key words： network security; vulnerability mining; Web system; logic vulnerability

0 引言

网络攻击，根据攻击手段一般可分为“硬攻击”和“软攻击”两类。SQL注入、信息监听、DDOS攻击和暴力破解等主动或被动攻击，都属于“硬攻击”[1]，而“软攻击”主要的攻击方法为社会工程攻击，通过欺诈、诱骗等手段来获取收集信息和入侵计算机系统[2]。而逻辑漏洞攻击更像是两者的融合。

Web安全逻辑漏洞是软件开发者在设计与开发系統过程中存在的逻辑缺陷所造成的[2]。随着软件系统框架的成熟以及网络安全设备的部署，传统网络攻击的成本和难度不断加大，但仍无法检测与阻止基于系统逻辑的网络攻击。网络安全设备是对数据流进行检测与分析，作用于网络层与应用层[3]，一旦攻击者出现攻击行为，其流量特征与正常流量相比存在异常，则会进行会话阻断。

逻辑漏洞是系统HTTP协议接口本身存在的逻辑问题，短信轰炸、敏感信息泄露、更改任意用户密码、越权、价格篡改、未授权登录等都属于逻辑漏洞范畴，其作用范围广、时间长，且无法被安全设备感知[4]，在实际环境中只能通过手工分析HTTP数据包的方法来挖掘此类漏洞。

本文结合实际生产过程中Web系统常用的软件功能模块，详细分析其HTTP数据包内容以及上下接口逻辑关系，探讨Web安全逻辑漏洞的挖掘思路，帮助用户更好地进行网络安全防护。

1 验证码机制缺陷

1.1 图片验证码

图片验证码被广泛应用在Web系统的各个场景中，用户登录认证和用户注册是其中使用最多的两个场景。图片验证码认证机制一旦存在问题，那么很有可能导致整个用户登录整体模块被完全攻破和任意用户无限次注册的问题。图片验证码机制缺陷一般可分为两类。①GET/POST方法请求验证码接口时返回的验证码格式为文本格式而不是图片格式，这样可以直接通过报文进行读取，如图1所示。②机制缺陷为验证码认证机制缺陷。由于系统开发人员的失误，仅仅依靠Web前端来进行验证码的验证。直接删除报文信息中的验证码字段（将code=****删除或者将****置空），这就会导致空验证码绕过。对于独立验证码认证接口，可尝试将认证接口数据包通过Burpsuit工具直接丢弃，如若未报错则存在问题。

1.2 短信验证码

短信验证码常存在的问题有短信轰炸和认证缺陷。短信轰炸是由于开发人员未设置接口请求时间间隔限制造成的或是时间判断完全依靠前端提交的Unix时间戳，通过无间隔的调用短信发送接口或更改时间戳来实现无限制短信发送。

认证缺陷是指用户已经收到服务器发送的短信验证码并填写提交给服务器认证时，服务器认证过程中存在的缺陷。关于绕过过程，可参考第1章中的图片验证码机制缺陷。对于短信验证码的绕过，本文主要分析根据服务器回显状态码绕过，由于认证的特殊性，将此类方法结合密码认证绕过放在第2章的Response状态值进行阐述。

2 密码认证绕过

2.1 Response状态值

在用户提交登陆凭证请求后，HTTP的Response中会根据用户的凭证返回特定的响应值（1/0、yes/no、fail/success等）。如若系统存在校验值不严格，并且返回的状态值是在前端进行校验的，那么就可对Response状态值进行修改，用户密码/手机验证码的非法登录请求就能够被成功执行。如图2所示，上面Response中的json状态值为用户输入的正确密码，下面为错误的，可以在正常登录流程中更改状态值为正确的再提交给前端，非法用户就能在不需要密码的情况下登录账户。如若系统用session、taken、JWT等会话控制功能，凭证校验在服务端操作，则不存在此类问题。

2.2 暴力破解

穷举所有的可能性就是暴力破解。暴力破解在计算机安全领域中应用极广，不仅可以用来爆破用户名和口令，也可以对session、taken甚至是JWT进行破解。Web系统中如未配有验证码（图片、滑动、识别、计算）和登录失败锁定等防暴力破解的功能，那么攻入系统只是时间问题。本节主要介绍用户名和口令的暴力破解。

用户名和口令暴力破解的核心是字典，字典囊括了所有用户名和口令的可能字符串。因为大多数人的密码会包括自己信息，所以最好的字典是根据受害者的信息使用字典工具（Cupp、Cewl、Crunch）自动生成的，比如受害者名字、生日、手机号、身份证号、亲人信息等等。一旦发现系统并不存在防暴力破解机制，则可以使用暴力破解工具抓取登录接口信息并导入字典信息进行暴力破解。正确和错误的用户口令，服务器返回信息是不同的，字节长度不同，暴力破解结果根据response的Length长度来甄别，如图3所示。

3 敏感信息泄露

3.1 JWT

JWT（Json Web Token）是认证授权会话机制的一种[5]，JWT的验证方式适用于分布式站点的单点登录（SSO）场景，JWT的验证流程如图4所示。

JWT由header、Payload、signature三个部分表示并使用“.”来分割这三串字符，header部分用来描述元素对象，由type（声明对象是JWT）与alg（声明Hash算法）构成。Payload表示有效荷载，传递的数据都在这个字段中，除了官方提供的七个声明字段（iss、sub、aud、exp、nbf、iat、jti），也可以自定义字段，但存在开发人员将密码的密文字符存放在Payload中，而header与Paylaod均使用base64进行编码，十分容易做逆向解析，一旦存在上述情况，就导致了JWT中的敏感信息泄露。

3.2 JavaScript冗余信息

JavaScript是一种非常简单且强大的前段脚本语言，但是在系统开发时开发人员为了方便，将密码、后台路径、对称密钥、API注释在JavaScript中，这就导致了敏感信息泄露[6]。此类泄露找寻方法非常简单，只需要查看源代码并在其中输入关键字段（login、adminlogin、user/login、password、phone、id等等）进行搜索（Ctrl+F）。前端已经匿名或者打码的敏感信息也可能由于开发人员的疏忽在前端代码中找寻到，另外也可以右击页面找到匿名信息的前端代码，修改元素type为“text”种类后，查看匿名信息是否直接明文显示在前端页面上。开发人员需要对前端代码进行混淆压缩，并仔细检查是否留下关于敏感信息的备注

3.3 中间件版本信息

中间件是介于操作系统与应用软件的一类软件，用来发布应用软件。B/S（浏览器/服务器）架构系统常用的中间件有tomcat、apache、weblogic等。

中间件版本信息泄露主要有两个来源，一是HTTP数据包中的Response返回信息泄露，主要是Server与X-Powered-By字段泄露，如图5所示。但Apache-Coyote/1.1可以作为例外，它不会暴露tomcat的具体版本号，可以不隐藏版本号。同时构造报错页面影响的请求，比如访问未被授权的页面的URL构造401错误、访问不存在的页面的URL构造404错误和篡改http method改为站点不允许的http method构造405错误，查看报错页面是否存在版本号并与漏洞库进行对比。

近些年来不同版本的中间件存在的安全漏洞非常之多（CVE-2017-12615、CVE-2019-0232等），且风险巨大，每次最新的中间件漏洞被挖掘后厂商只能进行发布版本补丁更新，但由于并不是所有的系统运维人员都会去进行补丁更新，一旦开发人员在系统开发过程中没有对中间件的版本信息进行隐藏处理，就很有可能导致漏洞直接被非法人员利用。

4 越权漏洞

4.1 垂直越权

垂直越权，是在不同用户级别、权限之间的越权访问。垂直越权分为向上越权和向下越权，向上越权指一个低权限用户访问高权限用户的资源与功能。高级别用户访问低级别用户信息（对高级别用户屏蔽的信息）为向下越权，这类情况较少见，所以垂直越权一般指向上越权。

垂直越权的原因是系统功能与资源未与用户身份信息（cookie、session、token）绑定。假设在一个民生供水系统中，A用户为管理用户，有权限进行社区供水流量的调节，而B用户为普通用户，只能进行基本的水流量监控与水卡充值权限，在一次偶然中B用户发现了供水流量调节的HTTP接口信息，一旦系统存在垂直越权漏洞，用户B可直接登录自己的账户将自己的身份信息（cookie、session、token）填写在接口中并调用，后果不堪设想。

垂直越权在实际系统中普遍存在，由于开发人员疏忽，未对用户身份权限信息进行鉴别，虽然前段流程看起来是违规的，但是HTTP數据包只传递信息给服务器，并不去管是否权限对应，服务器端由于未鉴别权限，收到后并不会发现这是个违法信息。

4.2 水平越权

水平越权是攻击者想访问与自己同级别用户的资源，其中主要包括三个场景：基于用户身份ID、基于对象ID、基于文件名，这三类可同属于ID指向，更改ID指向只能实现水平越权。图6中，用户A与用户B是同级别用户，他们的资源（文件、敏感信息、配置等）也是分隔的，分别对应资源1与资源2。在正常访问资源流程中，用户B的访问请求在HTTP数据包的表现为ID=资源2，但如果存在平行越权漏洞，则可以通过更改资源ID为1就能访问用户A的资源。

平行越权的在实际场景中普遍存在，失效的访问控制是造成平行越权的原因，开发人员在系统开发过程中应考虑到权限与用户之间的绑定，并在系统开发完成后进行测试。

5 业务逻辑一致性

5.1 竞争条件

存在类似积分兑换业务等情况，需要判断是否满足条件，这类业务需要对请求做类似队列的处理，或者对判断条件是否满足的依据数据的获取做加锁处理，只有因此类问题对经济上造成损失的业务才需要检查此项，如购买相应规格的服务，如果能突破人为设置规格的上限，公司是会承受损失的。

举例来说，如积分兑换业务，假设目前账号有500积分，应该可以兑换200积分的奖品二次，但很多情况下服务器处理是同时进行的，如果检查条件时没有加锁或者队列处理兑换业务，那么在该用户并发大量兑换请求时，兑换的条件检查同时都是该账户下有500积分，这样就存在可以多兑换的问题。

5.2 篡改价格、数量（极值）

如果业务的表单设计中直接包含了价格的参数（price）、数量或者涉及到价格、数量（不推荐在表单中设计价格参数）可能会出现产品“0元购”、数量超出控制（最大与最小）问题。

在一个正常流程中拦截请求，尝试将价格参数篡改成0、较低的值、负值等，后端检测、控制输入可能被突破。对于有订购数量上限的，尝试篡改请求中的代表订购数量的参数，以检测能否订购成功。如果订购次数有限制，则尝试重放订购请求或者绕过前端限制进行订购。参考http参数污染的思路，有价格参数并作输入检查限制的情况下，自行增加一个相同的价格参数，尝试通过此种方式突破参数的输入检查限制。在没有price参数的情况下，可以参考http参数污染的思路，自行构造“price”等。不同规格计费参数，低规格产品订购时更改为高规格实例参数，尝试低价高购问题篡改。对一些线性计费产品，如个/月计费，将数量更改为0，查看是否能免费订购。

5.3 任意用户密码更改

任意用户密码更改漏洞主要存在于“忘记密码”与“更改密码”模块，如果Web功能逻辑不严谨，则会造成恶意者随意更改他人密码。

任意密码更改一般要与验证码漏洞或者平行越权漏洞联系起来。在第四章第二节《水平越权》中，其中的资源库也可以指用户的密码，这样情况一般出现在“更改密码”的模块中。如果身份信息未与鉴权信息进行绑定，而仅仅依靠资源ID指向，攻击者只要知道用户对应的资源ID（猜解、爆破）就能进行任意用户的密码更改。

“忘记密码”中的逻辑缺陷一般要联系验证码漏洞与跳过验证码步骤。在正常的“忘记密码”过程中，系统一般都要求用户输入手机号进行验证码接收，在此过程中则会出现四种场景：

⑴ 验证码失效；

⑵ 验证码未绑定用户；

⑶ 篡改接收手机号/邮箱；

⑷ 跳过验证码密码步骤。

如果服务器未设置验证超时等功能造成验证码功能失效，可导致攻击者直接进行验证码暴力破解。验证码未绑定用户的情况会导致攻击者在使用自己的手机号/邮箱来进行验证码的，验证成功后修改HTTP数据包将手机号/邮箱换成其他人，这就实现了修改他人密码。在“找回密码”时，系统会要求输入用户名，之后系统会根据用户名发送验证码，在此期间使用软件拦截数据包，将受害者的手机号/邮箱更改为自己的，就能实现非法修改验证码。如图7所示，Web对用户密码的更改流程。

攻击者先用自己的账户来进行一个完整 “找回密码”流程，并记录流程接口数据，如果系统校验不严格，会导致攻击者输入受害者手机号发送验证码，之后直接丢弃验证码检验数据包跳到输入新密码修改密码接口，以此来实现任意用户密码更改。

6 结束语

Web安全逻辑漏洞是开发者在系统开发时期没有充分考虑到系统的安全逻辑性所导致的，在实际Web应用环境中普遍存在，而且很难被漏洞扫描探测出来，一旦被攻击者利用，攻击行为就很难被拦截且溯源也极为困难。本文通过HTTP数据包工作机制与流程，从验证码机制缺陷、密码认证绕过、敏感信息泄露、越权漏洞、业务逻辑一致性这五个方面，且通过具体实例来阐述Web安全逻辑漏洞挖掘思路。接下来将继续对逻辑漏洞安全识别与修补做深入研究，同时结合深度学习技术，为单位与企业的Web系统的安全开发提供有效的理论参考。

参考文献（References）：

[1] Douglas Jacobson.网络安全基础——网络攻防、协议与安全[M].电子工业版社，2016.

[2] 謝其祥，李莎.基于沙盒技术及社会工程学角度分析和防范钓鱼攻击的研究[J].广东通信技术，2022，42（9）：46-51.

[3] 陈春玲，雷世荣，陈丹伟.分布式防火墙的原理、实现及应用[J].南京邮电学院学报，2002（4）：5-10.

[4] 刘欣然.网络攻击分类技术综述[J].通信学报，2004（7）：30-36.

[5] 范展源，罗福强.JWT认证技术及其在Web中的应用[J].数字技术与应用，2016（2）：114.

[6] 马洪亮，王伟，韩臻.混淆恶意JavaScript代码的检测与反混淆方法研究[J].计算机学报，2017，40（7）：1699-1713.