业务安全漏洞作为常见的Web安全漏洞，在各大漏洞平台时有报道，本书是一本从原

理到案例分析，系统性地介绍这门技术的书籍。撰写团队具有10年大型网站业务安全测试

经验，成员们对常见业务安全漏洞进行梳理，总结出了全面、详细的适用于电商、银行、

金融、证券、保险、游戏、社交、招聘等业务系统的测试理论、工具、方法及案例。

本书共15章，包括理论篇、技术篇和实践篇。理论篇首先介绍从事网络安全工作涉及

的相关法律法规，请大家一定要做一个遵纪守法的白帽子，然后介绍业务安全引发的一些

安全问题和业务安全测试相关的方法论，以及怎么去学好业务安全。技术篇和实践篇选取

的内容都是这些白帽子多年在电商、金融、证券、保险、游戏、社交、招聘、O2O等不同

行业、不同的业务系统存在的各种类型业务逻辑漏洞进行安全测试总结而成的，能够帮助

读者理解不同行业的业务系统涉及的业务安全漏洞的特点。具体来说，技术篇主要介绍登

录认证模块测试、业务办理模块测试、业务授权访问模块测试、输入/输出模块测试、回

退模块测试、验证码机制测试、业务数据安全测试、业务流程乱序测试、密码找回模块测

试、业务接口模块调用测试等内容。实践篇主要针对技术篇中的测试方法进行相关典型案

例的测试总结，包括账号安全案例总结、密码找回案例总结、越权访问案例、OAuth2.0案

例总结、在线支付安全案例总结等。

通过对本书的学习，读者可以很好地掌握业务安全层面的安全测试技术，并且可以协

助企业规避业务安全层面的安全风险。本书比较适合作为企业专职安全人员、研发人员、

普通高等院校网络空间安全学科的教学用书和参考书，以及作为网络安全爱好者的自学用

书。

未经许可，不得以任何方式复制或抄袭本书之部分或全部内容。

版权所有，侵权必究。

图书在版编目（CIP）数据

Web攻防之业务安全实战指南/陈晓光等编著.—北京：电子工业出版社，2018.3

ISBN 978-7-121-33581-5

Ⅰ.①W… Ⅱ.①陈… Ⅲ.①互联网络-安全技术-指南 Ⅳ.①TP393.408-62

中国版本图书馆CIP数据核字（2018）第019878号

责任编辑：董英

印刷：三河市双峰印刷装订有限公司

装订：三河市双峰印刷装订有限公司

出版发行：电子工业出版社

北京市海淀区万寿路173信箱 邮编 100036

开本：787×980 1/16 印张：17.5 字数：292千字

版次：2018年3月第1版

定价：69.00元

凡所购买电子工业出版社图书有缺损问题，请向购买书店调换。若书店售缺，请与本

社发行部联系，联系及邮购电话：（010）88254888，88258888。

质量投诉请发邮件至zlts@phei.com.cn，盗版侵权举报请发邮件至dbqq@phei.com.cn。

本书咨询联系方式：（010）51260888-819，faq@phei.com.cn。

“没有网络安全就没有国家安全”。当前，网络安全已被提升到国家战略的高度，成为

影响国家安全、社会稳定至关重要的因素之一。

由于Web 2.0的兴起，基于Web环境的互联网应用越来越广泛，也让Web应用的安全

技术日趋成熟。目前互联网上接连爆发的应用安全漏洞，让各大企业的安全人员、运维人

员、研发及管理人员都不得不重视这一领域，并为之投入了大量的人力和物力。日渐成熟

的防护产品和解决方案，让Web安全防护的整体环境有了很大的提升。互联网上的网站模

板，大部分都自带了防SQL注入、跨站脚本等攻击的功能，传统的“工具党”、“小白”已很

难再通过简单操作几个按钮就成功完成一次Web入侵。

随着互联网业务的不断发展，互联网上的商务活动也越来越多，所涉及的网络交易也

越来越频繁，交易的数额也越来越庞大，引发的安全事件也越来越多。而这些安全事件的

攻击者更倾向于利用业务逻辑层的安全漏洞，如互联网上曝光的“1元购买特斯拉”、“微信

无限刷红包”、“支付宝熟人可重置登录密码”等业务安全层面的漏洞。基于传统的渗透测

试方法很难发现这些业务逻辑层面的问题，这类问题往往又危害巨大，可能造成企业的资

产损失和名誉受损，并且传统的安全防御设备和措施对业务安全漏洞防护收效甚微。

业务安全问题在互联网上也时有报道，不算新生事物，但目前缺乏一套体系化的介绍

这门技术的书籍。我们通过多年的不同行业的安全服务经验积累了大量的业务安全方面的

经验，于是萌生了编写这本书的想法，把我们所有沉淀的业务安全测试经验分享给爱好网

络安全事业的白帽子们，让大家一起成长，共同为国家网络安全事业贡献绵薄之力。

本书的撰写者均为轩辕攻防实验室白帽子，这些白帽子具备多年的业务安全测试经

验，同时他们在国家信息安全漏洞共享平台（CNVD）报送过很多原创漏洞（2016年轩辕

攻防实验室报送原创漏洞排名第二）。这些白帽子平时低调做人、高调做事，听说要编写

这本书时，大家群情激奋，热烈响应，牺牲了很多的个人休息时间，经过了近一年的努力

才总结完成了全面的、详细的可以适用于不同行业和不同业务系统的业务安全测试理论、

工具、方法及案例。在此也感谢所有参与撰写本书的这些默默无闻，不求名、不逐利、默

默分享的白帽子。在编写本书的过程中，我们也在互联网上发现了很多关于业务安全方面

的经典案例，并选取了几个非常不错且比较典型的案例，经过我们整理总结后分享给各位

读者，有的案例原作者已经联系上了，有个别的也无从联系了，在此也对分享这些经典案

例且默默在互联网上耕耘和贡献的白帽子表示衷心的感谢和发自内心的致敬。

在内容甄选时，抛开了一些纯理论的内容，书中选取的场景案例多是作者在工作中实

际遇到的问题加以改造的，目的是让读者通过对本书的学习，掌握实用的业务安全测试技

术，协助企业规避业务安全层面的安全风险。

本书共15章，包括理论篇、技术篇和实践篇。理论篇开篇首先介绍从事网络安全工作

涉及的相关法律法规，请大家一定要做一个遵纪守法的白帽子，然后介绍业务安全引发的

一些安全问题和业务安全测试相关的方法论及怎么去学好业务安全。技术篇和实践篇选取

的内容都是这些白帽子多年在电商、金融、证券、保险、游戏、社交、招聘、O2O 等不

同行业、不同的业务系统存在的各种类型业务逻辑漏洞进行安全测试总结而成的，能够帮

助读者理解不同行业的业务系统涉及的业务安全漏洞的特点。具体来说，技术篇主要介绍

登录认证模块测试、业务办理模块测试、业务授权访问模块测试、输入/输出模块测试、

回退模块测试、验证码机制测试、业务数据安全测试、业务流程乱序测试、密码找回模块

测试、业务接口模块调用测试等内容。实践篇主要针对技术篇中的测试方法进行相关典型

案例的测试总结，包括账号安全案例总结、密码找回案例总结、越权访问案例、OAuth 2.0案例总结、在线支付安全案例总结等。

通过对本书的学习读者可以很好地掌握业务安全层面的安全测试技术，并且可以协助

企业规避业务安全层面的安全风险。本书比较适合作为企业专职安全人员、研发人员、普

通高等院校网络空间安全学科的教学用书和参考书，以及作为网络安全爱好者的自学用

书。

由于水平有限，书中难免有不妥之处，加之网络攻防技术纵深宽广，发展迅速，在内

容取舍和编排上难免考虑不周全，诚请读者批评指正。

参与本书编写的还有：卜宁琳、袁淏森、刘书、陈亮亮、程利明、黄泽超、吉驰、闫

石坚、杨志学、张冠廷、张瑜龙、陈明、陈延飞、杨梦端。

轩辕攻防实验室负责人 张作峰

2018年01月 于北京

轻松注册成为博文视点社区用户（www.broadview.com.cn），扫码直达本书页面。

· 提交勘误：您对书中内容的修改意见可在 提交勘误 处提交，若被采纳，将获赠博

文视点社区积分（在您购买电子书时，积分可用来抵扣相应金额）。

· 交流互动：在页面下方 读者评论 处留下您的疑问或观点，与我们和其他读者一同

学习交流。

页面入口：http：//www.broadview.com.cn/33581

在出版之际，对关心和支持我们的所有朋友表示衷心的感谢。

感谢恒安嘉新（北京）科技股份公司金红董事长对编写工作的支持。

感谢中国联合网络通信有限公司信息化部林海对本书的审核和指导。

感谢国家互联网应急中心网络安全处主任严寒冰、公安部第三研究所主任徐凯、中国

信息安全测评中心系统评估处任望、威客安全CEO陈新龙、Joinsec创始人余弦、360补天

漏洞响应平台负责人白健、漏洞盒子创始人袁劲松的推荐语，他们是业界的标杆和大家学

习的楷模。

感谢一直给予我们帮助和鼓励的同事和朋友们，他们包括但不限于：吕雪梅、刘晓

蔚、刘宏杰、王小华、王幼平、赵岳磊、王兆龙、郭铁城、毛华均、胡付博、刘新鹏、金

健杨等。

最后感谢互联网上默默耕耘的白帽子刘欢、horseluke、only_guest、px1624、汉时明

月、牛奶坦克、猪哥靓、savior、0x 80、Rocky.Tian等业内人士对安全攻防技术的分享。

本书编写的初衷是为了增强企业的网络安全防护意识，提升网络安全从业者和相关人

士的专业技能水平。本书中讨论的内容仅限于研究和学习，严禁用于任何危害网络安全的

非法活动。《中华人民共和国网络安全法》于2017年6月1日起正式施行，作为我国网络领

域的基础性法律，不仅从法律上保障了广大人民群众在网络空间的利益，有效维护了国家

网络空间主权和安全，同时将严惩破坏我国网络空间的组织和个人。

下面摘录一些网络安全相关法律法规。

中华人民共和国网络安全法

第十二条

国家保护公民、法人和其他组织依法使用网络的权利，促进网络接入普及，提升网络

服务水平，为社会提供安全、便利的网络服务，保障网络信息依法有序自由流动。

任何个人和组织使用网络应当遵守宪法法律，遵守公共秩序，尊重社会公德，不得危

害网络安全，不得利用网络从事危害国家安全、荣誉和利益，煽动颠覆国家政权、推翻社

会主义制度，煽动分裂国家、破坏国家统一，宣扬恐怖主义、极端主义，宣扬民族仇恨、

民族歧视，传播暴力、淫秽色情信息，编造、传播虚假信息扰乱经济秩序和社会秩序，以

及侵害他人名誉、隐私、知识产权和其他合法权益等活动。

第二十七条

任何个人和组织不得从事非法侵入他人网络、干扰他人网络正常功能、窃取网络数据

等危害网络安全的活动；不得提供专门用于从事侵入网络、干扰网络正常功能及防护措

施、窃取网络数据等危害网络安全活动的程序、工具；明知他人从事危害网络安全活动

的，不得为其提供技术支持、广告推广、支付结算等帮助。

第四十四条

任何个人和组织不得窃取或者以其他非法方式获取个人信息，不得非法出售或者非法

向他人提供个人信息。

第四十六条

任何个人和组织应当对其使用网络的行为负责，不得设立用于实施诈骗，传授犯罪方

法，制作或者销售违禁物品、管制物品等违法犯罪活动的网站、通信群组，不得利用网络

发布涉及实施诈骗，制作或者销售违禁物品、管制物品以及其他违法犯罪活动的信息。

第四十八条

任何个人和组织发送的电子信息、提供的应用软件，不得设置恶意程序，不得含有法

律、行政法规禁止发布或者传输的信息。

电子信息发送服务提供者和应用软件下载服务提供者，应当履行安全管理义务，知道

其用户有前款规定行为的，应当停止提供服务，采取消除等处置措施，保存有关记录，并

向有关主管部门报告。

第六十条

违反本法第二十二条第一款、第二款和第四十八条第一款规定，有下列行为之一的，

元以上五十万元以下罚款，对直接负责的主管人员处一万元以上十万元以下罚款：

（一）设置恶意程序的；

（二）对其产品、服务存在的安全缺陷、漏洞等风险未立即采取补救措施，或者未按

照规定及时告知用户并向有关主管部门报告的；

（三）擅自终止为其产品、服务提供安全维护的。

第六十三条

违反本法第二十七条规定，从事危害网络安全的活动，或者提供专门用于从事危害网

络安全活动的程序、工具，或者为他人从事危害网络安全的活动提供技术支持、广告推

广、支付结算等帮助，尚不构成犯罪的，由公安机关没收违法所得，处五日以下拘留，可

以并处五万元以上五十万元以下罚款；情节较重的，处五日以上十五日以下拘留，可以并

处十万元以上一百万元以下罚款。

单位有前款行为的，由公安机关没收违法所得，处十万元以上一百万元以下罚款，并

对直接负责的主管人员和其他直接责任人员依照前款规定处罚。

违反本法第二十七条规定，受到治安管理处罚的人员，五年内不得从事网络安全管理

和网络运营关键岗位的工作；受到刑事处罚的人员，终身不得从事网络安全管理和网络运

营关键岗位的工作。

第六十四条

违反本法第四十四条规定，窃取或者以其他非法方式获取、非法出售或者非法向他人

提供个人信息，尚不构成犯罪的，由公安机关没收违法所得，并处违法所得一倍以上十倍

以下罚款，没有违法所得的，处一百万元以下罚款。

第六十七条

违反本法第四十六条规定，设立用于实施违法犯罪活动的网站、通信群组，或者利用

网络发布涉及实施违法犯罪活动的信息，尚不构成犯罪的，由公安机关处五日以下拘留，

可以并处一万元以上十万元以下罚款；情节较重的，处五日以上十五日以下拘留，可以并

处五万元以上五十万元以下罚款。关闭用于实施违法犯罪活动的网站、通信群组。

单位有前款行为的，由公安机关处十万元以上五十万元以下罚款，并对直接负责的主

管人员和其他直接责任人员依照前款规定处罚。

中华人民共和国刑法

第二百八十五条

违反国家规定，侵入国家事务、国防建设、尖端科学技术领域的计算机信息系统的，

处三年以下有期徒刑或者拘役。

违反国家规定，侵入前款规定以外的计算机信息系统或者采用其他技术手段，获取该

计算机信息系统中存储、处理或者传输的数据，或者对该计算机信息系统实施非法控制，

情节严重的，处三年以下有期徒刑或者拘役，并处或者单处罚金；情节特别严重的，处三

年以上七年以下有期徒刑，并处罚金。

提供专门用于侵入、非法控制计算机信息系统的程序、工具，或者明知他人实施侵

入、非法控制计算机信息系统的违法犯罪行为而为其提供程序、工具，情节严重的，依照

单位犯前三款罪的，对单位判处罚金，并对其直接负责的主管人员和其他直接责任人

员，依照各该款的规定处罚。

第二百八十六条

违反国家规定，对计算机信息系统功能进行删除、修改、增加、干扰，造成计算机信

息系统不能正常运行，后果严重的，处五年以下有期徒刑或者拘役；后果特别严重的，处

五年以上有期徒刑。

违反国家规定，对计算机信息系统中存储、处理或者传输的数据和应用程序进行删

除、修改、增加的操作，后果严重的，依照前款的规定处罚。

故意制作、传播计算机病毒等破坏性程序，影响计算机系统正常运行，后果严重的，

依照第一款的规定处罚。

单位犯前三款罪的，对单位判处罚金，并对其直接负责的主管人员和其他直接责任人

员，依照第一款的规定处罚。

第二百八十六条之一

网络服务提供者不履行法律、行政法规规定的信息网络安全管理义务，经监管部门责

令采取改正措施而拒不改正，有下列情形之一的，处三年以下有期徒刑、拘役或者管制，

并处或者单处罚金：

（一）致使违法信息大量传播的；

（二）致使用户信息泄露，造成严重后果的；

（三）致使刑事案件证据灭失，情节严重的；

（四）有其他严重情节的。

单位犯前款罪的，对单位判处罚金，并对其直接负责的主管人员和其他直接责任人

员，依照前款的规定处罚。

有前两款行为，同时构成其他犯罪的，依照处罚较重的规定定罪处罚。

中华人民共和国刑法修正案（七）

九、在刑法第二百八十五条中增加两款作为第二款、第三款：“违反国家规定，侵入

前款规定以外的计算机信息系统或者采用其他技术手段，获取该计算机信息系统中存储、

处理或者传输的数据，或者对该计算机信息系统实施非法控制，情节严重的，处三年以下

有期徒刑或者拘役，并处或者单处罚金；情节特别严重的，处三年以上七年以下有期徒

刑，并处罚金。

提供专门用于侵入、非法控制计算机信息系统的程序、工具，或者明知他人实施侵

入、非法控制计算机信息系统的违法犯罪行为而为其提供程序、工具，情节严重的，依照

前款的规定处罚。

中华人民共和国刑法修正案（九）

二十八、在刑法第二百八十六条后增加一条，作为第二百八十六条之一：网络服务提

供者不履行法律、行政法规规定的信息网络安全管理义务，经监管部门责令采取改正措施

而拒不改正，有下列情形之一的，处三年以下有期徒刑、拘役或者管制，并处或者单处罚

（一）致使违法信息大量传播的；

（二）致使用户信息泄露，造成严重后果的；

（三）致使刑事案件证据灭失，情节严重的；

（四）有其他严重情节的。

单位犯前款罪的，对单位判处罚金，并对其直接负责的主管人员和其他直接责任人

员，依照前款的规定处罚。

有前两款行为，同时构成其他犯罪的，依照处罚较重的规定定罪处罚。

二十九、在刑法第二百八十七条后增加两条，作为第二百八十七条之一、第二百八十

七条之二：

第二百八十七条之一利用信息网络实施下列行为之一，情节严重的，处三年以下有期

徒刑或者拘役，并处或者单处罚金：

（一）设立用于实施诈骗、传授犯罪方法、制作或者销售违禁物品、管制物品等违法

犯罪活动的网站、通信群组的；

（二）发布有关制作或者销售毒品、枪支、淫秽物品等违禁物品、管制物品或者其他

违法犯罪信息的；

（三）为实施诈骗等违法犯罪活动发布信息的。单位犯前款罪的，对单位判处罚金，

并对其直接负责的主管人员和其他直接责任人员，依照第一款的规定处罚。

有前两款行为，同时构成其他犯罪的，依照处罚较重的规定定罪处罚。

2.1 行业安全问题的思考

近年来，随着信息化技术的迅速发展和全球一体化进程的不断加快，计算机和网络已

经成为与所有人都息息相关的工具和媒介，个人的工作、生活和娱乐，企业的管理，乃至

国家的发展和改革都无出其外。信息和互联带来的不仅仅是便利和高效，大量隐私、敏感

和高价值的信息数据和资产，成为恶意攻击者攻击和威胁的主要目标，从早期以极客为核

心的黑客黄金年代，到现在利益链驱动的庞大黑色产业，网络安全已经成为任何个人、企

业、组织和国家所必须面对的重要问题。“网络安全和信息化是事关国家安全和国家发

展、事关广大人民群众工作生活的重大战略问题，没有网络安全就没有国家安全，没有信

息化就没有现代化。”

随着“互联网+”的发展，经济形态不断地发生演变。众多传统行业逐步地融入互联网

并利用信息通信技术以及互联网平台进行着频繁的商务活动，这些平台（如银行、保险、

证券、电商、P2P、O2O、游戏、社交、招聘、航空等）由于涉及大量的金钱、个人信

息、交易等重要隐私数据，成为了黑客攻击的首要目标，而因为开发人员安全意识淡薄

（只注重实现功能而忽略了在用户使用过程中个人的行为对Web应用程序的业务逻辑功能

的安全性影响）、开发代码频繁迭代导致这些平台业务逻辑层面的安全风险层出不穷（业

务逻辑漏洞主要是开发人员业务流程设计的缺陷，不仅限于网络层、系统层、代码层等。

比如登录验证的绕过、交易中的数据篡改、接口的恶意调用等，都属于业务逻辑漏洞）。

目前业内基于这些平台的安全风险检测一般都采用常规的渗透测试技术（主要基于owasp top 10），而常规的渗透测试往往忽视这些平台存在的业务逻辑层面风险，业务逻辑风险

往往危害更大，会造成非常严重的后果。

为何业务逻辑漏洞会成为黑客的主要攻击目标？

一方面随着社会及科技的发展，购物、社交、P2P、O2O、游戏、招聘等业务纷纷具

备了在线支付功能。如电商支付系统保存了用户手机号、姓名、家庭住址，甚至包括支付

的银行卡号信息、支付密码信息等，这些都是黑客感兴趣的敏感信息。相比SQL注入漏

洞、XSS漏洞、上传、命令执行等传统应用安全方面的漏洞，现在的攻击者更倾向于利用

业务逻辑层面存在的安全问题。这类问题往往容易被开发人员忽视，同时又具有很大的危

害性，例如一些支付类的逻辑漏洞可能使企业遭受巨大的财产损失。传统的安全防护设备

和措施主要针对应用层面，而对业务逻辑层面的防护则收效甚微。攻击者可以利用程序员

的设计缺陷进行交易数据篡改、敏感信息盗取、资产的窃取等操作。现在的黑客不再以炫

耀技能为主要攻击目的，而主要以经济利益为目的，攻击的目的逐渐转变为趋利化。

另一方面，如今的业务系统对于传统安全漏洞防护的技术和设备越来越成熟，基于传

统安全漏洞入侵也变得越来越困难，增加了黑客的攻击成本。而业务逻辑漏洞可以逃逸各

种安全防护，迄今为止没有很好的解决办法。这也是为什么黑客偏好使用业务逻辑漏洞进

行攻击的一个原因。

本书中我们将围绕业务场景中可能存在的业务安全问题介绍详细的测试方法。

2.2 如何更好地学习业务安全

总结的宝贵经验，开拓自己的安全视野。

其次需要了解目标平台的业务流程。在进行安全测试前，需要对业务的详细流程进行

一次全面的梳理。可以先将业务主体划分为几个大模块，再将每个大模块逐个细分为子模

块。可以从账号体系开始，如用户的注册、登录、密码找回、信息存储等，再到具体的业

务办理，如商品的搜索、选择、支付、生成订单，以及订单查询和用户评论等。对整个业

务流程有了一个详细的了解后，再结合前面学到的测试方法，就能更全面地把控业务流程

的各个步骤可能存在的风险点。

应结合被测试对象的实际业务情况，从熟悉公司、组织的业务模式、赢利模式来着

手，通过一定程度地理解被测对象的业务模式，了解信息系统所承载的业务数据流转情

况，分析出业务对象、渠道，以及各业务系统前、后台业务数据的生成、传输、使用和存

储方式，再针对不同的业务场景构建相应的业务安全测试模型。

建议读者尽量自己搭建每个业务场景，在自己搭建业务环境的过程中，可以熟悉业务

流程和业务类型，对于自己搭建的业务环境会有更深刻的印象。

通常情况下针对电子商务类业务安全测试模型的构建应着重考虑账户、交易和支付三

个重要业务相关环节，确保账户体系安全、交易体系安全、支付体系安全以及用户信息存

储安全。

在实践层面，推荐使用以下两种测试技巧，以达到事半功倍的效果：

·

科学的测试方法。常规的方法有控制变量法、删减法等，如在分析平行权限跨越

时，需要明白每一次步骤变的是什么，不变的是什么，控制好不同变量的变化，从而筛选

出影响业务流程的参数。

· 学会使用思维导图等工具。在面对复杂的系统时，我们需要通过思维导图等工具来

协助我们理清各个业务模块之间的联系，从而做到有的放矢。

如果是初学者，建议先熟悉Web安全的基础知识，推荐本书同系列的《Web安全基础

教程》，该教程详细介绍了Web安全基础、Web安全测试方法、Web常见漏洞、Web 安全

实战演练、日常安全意识。在熟悉基础安全技能后，再结合本书的案例多进行动手实践，

毕竟读万卷书，不如行万里路。

最后，希望在网络安全的道路上与君共勉，砥砺前行！

第3章 业务安全测试理论

3.1 业务安全测试概述

业务安全测试通常是指针对业务运行的软、硬件平台（操作系统、数据库、中间件

等），业务系统自身（软件或设备）和业务所提供的服务进行安全测试，保护业务系统免

受安全威胁，以验证业务系统符合安全需求定义和安全标准的过程。本书所涉及的业务安

全主要是系统自身和所提供服务的安全，即针对业务系统中的业务流程、业务逻辑设计、

业务权限和业务数据及相关支撑系统及后台管理平台与业务相关的支撑功能、管理流程等

方面的安全测试，深度挖掘业务安全漏洞，并提供相关整改修复建议，从关注具体业务功

能的正确呈现、安全运营角度出发，增强用户业务系统的安全性。

传统安全测试主要依靠基于漏洞类型的自动化扫描检测，辅以人工测试，来发现如

SQL 注入、XSS、任意文件上传、远程命令执行等传统类型的漏洞，这种方式往往容易忽

略业务系统的业务流程设计缺陷、业务逻辑、业务数据流转、业务权限、业务数据等方面

的安全风险。过度依赖基于漏洞的传统安全测试方式脱离了业务系统本身，不与业务数据

相关联，很难发现业务层面的漏洞，企业很可能因为简单的业务逻辑漏洞而蒙受巨大损

失。

3.2 业务安全测试模型

如图3-1所示，业务安全测试模型要素如下。

图3-1 业务安全测试模型

· 前台视角：业务使用者（信息系统受众）可见的业务及系统视图，如平台的用户注

册、充值、购买、交易、查询等业务。

· 后台视角：管理用户（信息系统管理、运营人员）可见的业务及系统视图，如平台

的登录认证、结算、对账等业务。

· 业务视角：业务使用者（信息系统受众）可见的表现层视图，如 Web 浏览器、手机

浏览器展现的页面及其他业务系统用户的UI界面。

· 系统视角：业务使用者（信息系统受众）不可见的系统逻辑层视图。

为了全面测试客户业务系统，在进行业务安全分析的时候，不能拘泥于以上测试模

型，在面对不同用户的不同业务的时候，通过深入了解用户业务特点、业务安全需求，应

切实地根据客户业务系统的架构，从前/后视角、业务视角与支撑系统视角划分测试对

象，根据实际情况选择白灰盒或黑盒的手段进行业务安全测试。

*特别提示：

·

对于支撑系统的子系统，其调用关系有时不是简单的顺序调用，中间可能涉及重

复、乱序调用的情况，需要具体系统具体分析。

· 对于前台的业务视角，在做白盒测试前，应通过用户访谈切实了解其每一个业务模

块调用了哪些支撑系统模块，熟悉其调用顺序。

· 对于前台的业务视角，以手动用例测试结合安全分析工具为主。对于能够提供使用

环境的管理后台业务视角，以手动用例测试结合安全分析工具为主，不能提供使用环境的

管理后台业务视角测试以访谈为主。对于支撑系统视角的测试，以访谈为主。

3.3 业务安全测试流程

业务安全测试流程总体上分为七个阶段，前期工作主要以测试准备和业务调研为主，

通过收集并参考业务系统相关设计文档和实际操作，与相关开发人员沟通、调研等方式熟

悉了解被测系统业务内容和流程，然后在前期工作的基础上，根据业务类型进行业务场景

建模，并把重要业务系统功能拆分成待测试的业务模块，进而对重要业务功能的各个业务

模块进行业务流程梳理，之后对梳理后的业务关键点进行风险识别工作，这也是业务测试

安全最重要的关键环节，最终根据风险点设计相应的测试用例，开展测试工作并最终输出

测试报告。具体业务安全测试流程如图3-2所示。

图3-2 业务安全测试流程图

流程一：测试准备

准备阶段主要包括对业务系统的前期熟悉工作，以了解被测试业务系统的数量、规模

和场景等内容。针对白盒性质的测试，可以结合相关开发文档去熟悉相关系统业务；针对

黑盒测试，可通过实际操作还原业务流程的方式理解业务。

流程二：业务调研

业务调研阶段主要针对业务系统相关负责人进行访谈调研，了解业务系统的整体情

况，包括部署情况、功能模块、业务流程、数据流、业务逻辑以及现有的安全措施等内

容。根据以往测试实施经验，在业务调研前可先设计访谈问卷，访谈后可能会随着对客户

业务系统具体情况了解的深入而不断调整、更新问卷（黑盒测试此步骤可忽略）。

流程三：业务场景建模

针对不同行业、不同平台的业务系统，如电商、银行、金融、证券、保险、游戏、社

交、招聘等业务系统，识别出其中的高风险业务场景进行建模。以电商系统为例，如图3-

3所示为业务场景建模模型图。

图3-3 电商系统业务场景建模

流程四：业务流程梳理

建模完成后需要对重要业务场景的各个业务模块逐一进行业务流程梳理，从前台和后

台、业务和支撑系统等4个不同维度进行分析，识别各业务模块的业务逻辑、业务数据流

和功能字段等。

业务模块的流程梳理主要遵循以下原则：

· 区分业务主流程和分支流程，业务梳理工作是围绕主流程进行分析的，而主流程一

定是核心业务流程，业务流程重点梳理的对象首先应放在核心主流程上，务必梳理出业务

关键环节；

· 概括归纳业务分支流程，业务分支流程往往存在通用点，可将具有业务相似性的分

支流程归纳成某一类型的业务流程，无须单独对其进行测试；

· 识别业务流程数据信息流，特别是业务数据流在交互方双方之间传输的先后顺序、

路径等；

· 识别业务数据流功能字段，识别数据流中包含的重要程度不等的信息，理解这些字

段的含义有助于下阶段风险点分析。

如图3-4所示是针对某电商类网站的用户登录功能的业务流程梳理图。

图3-4 相关业务流程图

通过业务流程的各个阶段梳理出业务流程各个关键环节点，如图3-5所示。

流程五：业务风险点识别

在完成前期不同维度的业务流程梳理工作后，针对前台业务应着重关注用户界面操作

每一步可能的逻辑风险和技术风险；针对后台业务应着重关注数据安全、数据流转及处理

的日志和审计。

图3-5 业务环节梳理结果图

业务风险点识别应主要关注以下安全风险内容。

（1）业务环节存在的安全风险

业务环节存在的安全风险指的是业务使用者可见的业务存在的安全风险，如注册、登

录和密码找回等身份认证环节，是否存在完善的验证码机制、数据一致性校验机制、

Session 和 Cookie 校验机制等，是否能规避验证码绕过、暴利破解和 SQL注入等漏洞。

（2）支持系统存在的安全风险

支持系统存在的安全风险，如用户访问控制机制是否完善，是否存在水平越权或垂直

越权漏洞。系统内加密存储机制是否完善，业务数据是否明文传输。系统使用的业务接口

是否可以未授权访问/调用，是否可以调用重放、遍历，接口调用参数是否可篡改等。

（3）业务环节间存在的安全风险

业务环节间存在的安全风险，如系统业务流程是否存在乱序，导致某个业务环节可绕

过、回退，或某个业务请求可以无限重放。业务环节间传输的数据是否有一致性校验机

制，是否存在业务数据可被篡改的风险。

（4）支持系统间存在的安全风险

支持系统间存在的安全风险，如系统间数据传输是否加密、系统间传输的参数是否可

篡改。系统间输入参数的过滤机制是否完善，是否可能导致 SQL 注入、XSS跨站脚本和

代码执行漏洞。

（5）业务环节与支持系统间存在的安全风险

业务环节与支持系统间存在的风险，如数据传输是否加密、加密方式是否完善，是否

采用前端加密、简单MD5编码等不安全的加密方式。系统处理多线程并发请求的机制是

否完善，服务端逻辑与数据库读写是否存在时序问题，导致竞争条件漏洞。系统间输入参

数的过滤机制是否完善。

具体业务风险点识别示例如图3-6所示。

图3-6 业务风险点识别

流程六：开展测试

对前期业务流程梳理和识别出的风险点，进行有针对性的测试工作。

流程七：撰写报告

最后是针对业务安全测试过程中发现的风险结果进行评价和建议，综合评价利用场景

的风险程度和造成影响的严重程度，最终完成测试报告的撰写。

3.4 业务安全测试参考标准

本书介绍的业务安全测试方法在充分借鉴了中华人民共和国通信行业标准YD/T 3169

—2016（互联网新技术新业务安全评估指南）、ISO 27002信息安全最佳实践、Cobit IT内

控框架、PCI数据安全标准的同时，考虑到需要进行业务安全测试的核心业务主要基于

Web，还参考了OWASP安全防护框架及Microsoft Web应用安全框架，采纳其中业务安全

相关的安全性要求、检测方法、处置方法，参考实际业务系统特点及主要安全关注需求，

能够为目标系统提供定制化测试。

本书总结了十大业务安全测试关键点，如图3-7所示。在接下来的技术篇中，将结合

案例详细介绍每个关键点的测试原理和方法、测试过程和修复建议。

第4章 登录认证模块测试

4.1 暴力破解测试

4.1.1 测试原理和方法

暴力破解测试是指针对应用系统用户登录账号与密码进行的穷举测试，针对账号或密

码进行逐一比较，直到找出正确的账号与密码。

一般分为以下三种情况：

· 在已知账号的情况下，加载密码字典针对密码进行穷举测试；

· 在未知账号的情况下，加载账号字典，并结合密码字典进行穷举测试；

· 在未知账号和密码的情况下，利用账号字典和密码字典进行穷举测试。

4.1.2 测试过程

使用手工或工具对系统登录认证的账号及密码进行穷举访问测试，根据系统返回的数

据信息来判别账号及密码是否正确。测试流程如图4-1所示。

步骤一：对浏览器进行HTTP代理配置，将浏览器访问请求指向Burp Suite工具默认的

监听端口（这里以火狐浏览器为例）。

图4-1 暴力破解测试流程图

（1）打开火狐浏览器，在页面中单击右上角的“打开菜单”按钮，然后在下拉框中单

击“选项”按钮进入火狐浏览器选项页面，如图4-2所示。

图4-2 进入火狐浏览器选项功能页面

（2）在火狐浏览器选项页面中单击“高级”按钮，选择“网络”选项卡，在连接项中单

击“设置”按钮，进入火狐浏览器“连接设置”界面，如图4-3所示。

图4-3 进入火狐浏览器“连接设置”界面

（3）进入“连接设置”界面后将连接方式选择为“手动配置代理”，在 HTTP代理框中

填写“127.0.0.1”，在端口框中填写“8080”，最后单击“确定”按钮确定配置信息，如图4-4所

示。

图4-4 配置火狐浏览器代理参数

步骤二：使用 Burp Suite 工具获取浏览器登录请求，并将登录请求数据发送至

Intruder选项卡中（这里使用Burp Suite 1.7.11版本）。

（1）在Burp Suite页面中选择“Proxy”选项卡，然后再次选择“Intercept”子选项卡，在

该选项卡界面中将“Intercept”按钮设置为“Intercept is on”，此时火狐浏览器发送的请求数

据会被Burp Suite工具截断，如图4-5所示。

图4-5 将Burp Suite工具中Proxy模块数据包拦截功能开启

从图4-5我们可以看到Proxy的Intercept选项卡中对应有四个选项按钮，下面分别来讲

解一下。

· Forward：将当前Proxy拦截到的数据包进行转发。

· Drop：将当前Proxy拦截到的数据包进行丢弃。

· Intercept is on：单击之后，将关闭Burp Suite的拦截功能。但是所有HTTP请求还是

经过Burp Suite，我们可以在HTTP history选项卡中看到。

· Action：我们可以进行其他更多的操作，发送到 Intruder 等其他 Burp Suite模块，以

便进行重复测试或者暴力破解。（2）在火狐浏览器中填写要暴力破解的账号信息及任意

密码信息，单击“确定”按钮提交信息，如图4-6所示。

图4-6 输入将要暴力破解账号口令并提交

（3）当火狐浏览器将登录请求数据提交后，会被Burp Suite Proxy模块截断，在截断

数据界面中使用鼠标右击，在弹出菜单中选择“Send to Intruder”，Burp Suite会将该请求数

据分发给Intruder模块，如图4-7所示。

图4-7 截获浏览器请求数据并将请求数据分发给Intruder模块

步骤三：使用Burp Suite工具中的Intruder模块进行破解参数配置，运行破解任务并成

功破解系统账号口令。

（1）在Intruder模块中选择Positions选项卡，单击“Clear”按钮清除相关默认参数值前

后的“§”标记符号，如图4-8所示。

图4-8 在Intruder模块中的Positions选项卡中清除默认参数值标记

（2）用鼠标选中请求数据页面中的password参数值（所要进行暴力破解的密码

值），并单击“Add §”按钮进行位置标记，如图4-9所示。

（3）选择Payloads选项卡，然后单击“Load items form file”，在弹出对话框中选择暴

力破解密码文件并单击“打开”按钮，将破解密码列表导入后单击“Start attack”按钮开始暴

力破解测试，如图4-10所示。

（4）在暴力破解测试窗口“Intruder attack 1”中可根据Length属性值长度的不同来判断

暴力破解密码是否成功，也可通过查看Response返回信息或者Status返回状态的不同来判

断破解密码是否成功，如图4-11所示。

图4-9 选择并标记所要暴力破解的参数值

图4-10 导入暴力破解密码文件并运行暴力破解测试

图4-11 根据返回结果判断暴力破解密码是否成功

（5）通过Burp Suite工具暴力破解成功的密码来尝试系统登录（本系统为作者自己搭

建的系统），如图4-12所示。

图4-12 通过Burp Suite工具暴力破解成功的密码来尝试登录

4.1.3 修复建议

（1）增加验证码，登录失败一次，验证码变换一次。

（2）配置登录失败次数限制策略，如在同一用户尝试登录的情况下，5 分钟内连续

登录失败超过6次，则禁止此用户在3小时内登录系统。

（3）在条件允许的情况下，增加手机接收短信验证码或邮箱接收邮件验证码，实现

双因素认证的防暴力破解机制。

4.2 本地加密传输测试

4.2.1 测试原理和方法

本机加密传输测试是针对客户端与服务器的数据传输，查看数据是否采用

SSL

（Security Socket Layer，安全套接层）加密方式加密。

4.2.2 测试过程

测试验证客户端与服务器交互数据在网络传输过程中是否采用 SSL 进行加密处理，

加密数据是否可被破解。测试流程如图4-13所示。

图4-13 本地加密传输测试流程图

步骤一：使用Wireshark网络抓包工具，选择与公网连接的本地网卡并开启对网卡流

量数据的捕获功能，如图4-14所示。

图4-14 使用Wireshark网络抓包工具对本地网卡进行数据捕获

步骤二：在浏览器中访问要测试的HTTPS协议网站，并输入用户名及密码进行登录

操作，如图4-15所示。

图4-15 在Wireshark捕获状态下对HTTPS测试网站进行登录操作

步骤三：在Wireshark工具捕获流中找到对应HTTPS测试网站登录的请求数据包，对

该请求包内容进行分析，判断测试网站交互数据是否真正加密，如图4-16所示。

图4-16 在Wireshark工具捕获流中找到对应HTTPS测试网站并查看数据是否加密

4.2.3 修复建议

在架设Web应用的服务器上部署有效的SSL证书服务。

4.3 Session测试

4.3.1 Session会话固定测试

4.3.1.1 测试原理和方法

Session 是应用系统对浏览器客户端身份认证的属性标识，在用户退出应用系统时，

应将客户端Session认证属性标识清空。如果未能清空客户端Session标识，在下次登录系

统时，系统会重复利用该Session标识进行认证会话。攻击者可利用该漏洞生成固定

Session会话，并诱骗用户利用攻击者生成的固定会话进行系统登录，从而导致用户会话

认证被窃取。

4.3.1.2 测试过程

在注销退出系统时，对当前浏览器授权SessionID值进行记录。再次登录系统，将本

次授权 SessionID 值与上次进行比对校验。判断服务器是否使用与上次相同的SessionID 值

进行授权认证，若使用相同 SessionID 值则存在固定会话风险。测试流程如图4-17所示。

图4-17 Session会话固定测试流程图

步骤一：在已登录授权认证的页面中单击“退出系统”，如图4-18所示。

图4-18 单击并退出已登录授权认证的系统

步骤二：使用Burp

Suite工具对本次退出系统的请求数据进行截取，对本次授权的

SessionID进行记录备份，如图4-19所示。

图4-19 在退出系统前抓包将SessionID值进行记录备份

步骤三：退出系统后，再次重新登录系统，如图4-20所示。

图4-20 退出系统后再次重新登录系统

步骤四：使用Burp Suite工具对本次登录授权请求数据进行截取，并将本次登录与上

次登录的授权SessionID值进行比较，判断是否相同，如图4-21所示。

图4-21 将两次登录SessionID值进行判断对比

4.3.1.3 修复建议

在客户端登录系统时，应首先判断客户端是否提交浏览器的留存Session认证会话属

性标识，客户端提交此信息至服务器时，应及时销毁浏览器留存的Session认证会话，并

要求客户端浏览器重新生成Session认证会话属性标识。

4.3.2 Seesion会话注销测试

4.3.2.1 测试原理和方法

Session 是应用系统对浏览器客户端身份认证的属性标识，在用户注销或退出应用系

统时，系统应将客户端Session认证属性标识清空。如果未能清空Session认证会话，该认

证会话将持续有效，此时攻击者获得该Session认证会话会导致用户权限被盗取。

4.3.2.2 测试过程

该项测试主要在用户注销退出系统授权后，判断授权认证SessionID值是否依然有

效。若授权认证SessionID依然有效则存在风险。测试流程如图4-22所示。

图4-22 Seesion会话注销测试流程图

步骤一：对已登录授权的系统页面使用Burp Suite工具进行请求数据截取，将数据包

中Session认证参数值进行保存记录，如图4-23、图4-24所示。

图4-23 已登录授权的系统页面

图4-24 使用Burp Suite 工具截取登录认证Session信息并进行保存记录

步骤二：在数据截取窗口中使用鼠标右击，在弹出菜单中选择“Send Repeater”，将请

求数据发送至Repeater模块中，如图4-25所示。

图4-25 将请求数据信息转发至Repeater模块中

步骤三：在已授权的页面中退出系统，如图4-26所示。

图4-26 在系统授权页面中退出系统

步骤四：在Repeater模块相应授权数据信息页面中单击“GO”按钮，再次发送授权访问

请求并查看系统是否对退出后的用户授权Session进行解除授权，如图4-27所示。

图4-27 在用户退出系统后再次使用原先的Session访问系统要求重新登录

4.3.2.3 修复建议

在用户注销或退出应用系统时，服务器应及时销毁Session认证会话信息并清空客户

端浏览器Session属性标识。

4.3.3 Seesion会话超时时间测试

4.3.3.1 测试原理和方法

在用户成功登录系统获得Session认证会话后，该Session认证会话应具有生命周期，

即用户在成功登录系统后，如果在固定时间内（例如10分钟）该用户与服务器无任何交互

操作，应销毁该用户Session认证会话信息，要求用户重新登录系统认证。

4.3.3.2 测试过程

对系统会话授权认证时长进行测试，并根据系统承载的业务需求来分析判断当前系统

会话授权认证时间是否过长。测试流程如图4-28所示。

图4-28 Session会话超时时间测试流程图

步骤一：对已登录授权的系统页面使用Burp Suite工具进行请求数据截取，将数据包

中Session认证参数值进行保存记录，如图4-29、图4-30所示。

图4-29 已登录授权的系统页面

图4-30 使用Burp Suite工具截取登录认证Session信息并进行保存记录

步骤二：在数据截取窗口中使用鼠标右击，在弹出菜单中选择“Send Repeater”，将请

求数据发送至Repeater模块中，如图4-31所示。

图4-31 将请求数据信息转发至Repeater模块中

步骤三：在此后30分钟内不再使用该授权会话与服务器进行交互访问。30分钟过后在

Repeater 模块相应授权数据信息页面中单击“GO”按钮，再次发送授权访问请求并查看系

统返回结果是否存在授权后可查阅的特殊信息，如图4-32、图4-33所示。

图4-32 对授权成功的Session值进行首次访问

图4-33 时隔30分钟后再次发送请求（系统仍然返回用户特殊信息）

4.3.3.3 修复建议

对每个生成的Session认证会话配置生命周期（常规业务系统建议30分钟内），从而

有效降低因用户会话认证时间过长而导致的信息泄露风险。

4.4 Cookie仿冒测试

4.4.1 测试原理和方法

服务器为鉴别客户端浏览器会话及身份信息，会将用户身份信息存储在 Cookie中，

并发送至客户端存储。攻击者通过尝试修改Cookie中的身份标识，从而达到仿冒其他用户

身份的目的，并拥有相关用户的所有权限。

4.4.2 测试过程

对系统会话授权认证Cookie中会话身份认证标识进行篡改测试，通过篡改身份认证标

识值来判断能否改变用户身份会话。测试流程如图4-34所示。

图4-34 Cookie仿冒测试流程图

步骤一：使用leifeng账号登录系统并进行浏览器页面刷新，如图4-35所示。

图4-35 使用学生账号leifeng登录系统

步骤二：使用Burp

Suite工具对本次页面刷新请求数据进行截取，并将请求数据

Cookie中的userid值修改为“admin”进行提交，如图4-36所示。

图4-36 再次刷新页面并抓包将Cookie中userid身份认证标识进行篡改

步骤三：查看提交后的返回信息，账号身份授权被修改，如图4-37所示。

图4-37 通过篡改userid身份标识改变登录系统人员身份信息

4.4.3 修复建议

建议对客户端标识的用户敏感信息数据，使用Session会话认证方式，避免被他人仿

冒身份。

4.5 密文比对认证测试

4.5.1 测试原理和方法

在系统登录时密码加密流程一般是先将用户名和密码发送到服务器，服务器会把用户

提交的密码经过Hash算法加密后和数据库中存储的加密值比对，如果加密值相同，则判

定用户提交密码正确。

但有些网站系统的流程是在前台浏览器客户端对密码进行Hash加密后传输给服务器

并与数据库加密值进行对比，如果加密值相同，则判定用户提交密码正确。此流程会泄漏

密码加密方式，导致出现安全隐患。

4.5.2 测试过程

对系统敏感数据加密流程进行测试，判断加密过程或方式是否为客户端加密方式。测

试流程如图4-38所示。

图4-38 密文对比认证测试流程图

步骤一：通过Burp Suite工具抓包并根据页面代码分析后证实登录传输口令使用Hash MD5加密算法加密。

（1）通过Burp Suite工具抓包查看Web系统登录提交密码为加密后的密文传输，如图

4-39所示。

图4-39 使用Burp Suite工具抓包证实Web系统登录口令为MD5加密传输

（2）通过对页面代码分析得出Web系统登录口令加密处理过程是由本地JS脚本来完

成的，方式为Hash MD5算法加密，如图4-40所示。

步骤二：在利用Burp

Suite工具进行暴力破解测试配置中添加配置项“Payload

Processing”，将要破解的密码值进行数据处理转换。

（1）在暴力破解Payload选项卡Payload Processing中单击“Add”按钮，在弹出对话框

中按顺序选择“Hash”及“MD5”并单击“OK”按钮，如图4-41所示。

图4-40 分析得出系统密码加密方式为本地MD5算法加密

图4-41 在Payload Processing中配置密码处理类型

（2）Payload Processing配置完成后单击“Start attack”按钮开始暴力破解测试，通过

Payload Processing将所有明文密码进行MD5转换后进行了暴力破解登录测试并成功破解，

如图4-42所示。

图4-42 通过Payload Processing配置成功破解密码

4.5.3 修复建议

将密码加密过程及密文比对过程放置在服务器后台执行。发送用户名和密码到服务器

后台，后台对用户提交的密码经过 MD5 算法加密后和数据库中存储的 MD5密码值进行比

对，如果加密值相同，则允许用户登录。

4.6 登录失败信息测试

4.6.1 测试原理和方法

在用户登录系统失败时，系统会在页面显示用户登录的失败信息，假如提交账号在系

统中不存在，系统提示“用户名不存在”、“账号不存在”等明确信息；假如提交账号在系统

中存在，则系统提示“密码/口令错误”等间接提示信息。攻击者可根据此类登录失败提示

信息来判断当前登录账号是否在系统中存在，从而进行有针对性的暴力破解口令测试。

4.6.2 测试过程

针对系统返回不同的登录失败提示信息进行逻辑分析，判断是否能通过系统返回的登

录失败信息猜测系统账号或密码。测试流程如图4-43所示。

图4-43 登录失败信息测试流程图

步骤一：在系统登录页面中输入不存在的账号信息并提交，系统会返回明确语句“用

户名不存在”，如图4-44所示。

步骤二：在系统登录页面中输入存在的账号信息及错误密码提交后，系统返回语句间

接地提示了该账号的“密码/口令错误”，如图4-45所示。

图4-44 系统返回信息并明确提示登录账号不存在

图4-45 系统间接地提示该账号密码错误

4.6.3 修复建议

对系统登录失败提示语句表达内容进行统一的模糊描述，从而提高攻击者对登录系统

用户名及密码的可猜测难度，如“登录账号或密码错误”、“系统登录失败”等。

第5章 业务办理模块测试

5.1 订单ID篡改测试

5.1.1 测试原理和方法

在有电子交易业务的网站中，用户登录后可以下订单购买相应产品，购买成功后，用

户可以查看订单的详情。当开发人员没有考虑登录后用户间权限隔离的问题时，就会导致

平行权限绕过漏洞。攻击者只需注册一个普通账户，就可以通过篡改、遍历订单id，获得

其他用户订单详情，其中多数会包括用户的姓名、身份证、地址、电话号码等敏感隐私信

息。黑色产业链中的攻击者通常会利用此漏洞得到这些隐私信息。

5.1.2 测试过程

攻击者注册一个普通账户，然后篡改、遍历订单 ID，获得其他用户订单详情。测试

流程如图5-1所示。

假设某保险网站存在平行权限绕过漏洞。

登录网站后，访问如下漏洞url，修改参数policyNo的值，可以遍历获得他人保单内

容，其中包含很多敏感隐私信息。

http://xxxxx.com/SL_LES/policyDetailInfo.do?policyNo=P000000018446847

图5-1 订单ID篡改测试流程图

步骤一：登录“李先生”账号（测试），查看本人保单，如图5-2所示。

图5-2 查看保单

步骤二：抓包修改保单号，即可越权查看他人保单内容，如图 5-3、图 5-4、图5-5所

示。

图5-3 抓包修改保单号

图5-4 他人保单

图5-5 他人保单

在返回的数据包中，包含全部在界面中被隐藏的身份证号等敏感信息，如图5-6所

示。

图5-6 查看隐藏的敏感信息

可能涉及1800多万的保单信息泄露，如图5-7所示。

图5-7 遍历保单号

5.1.3 修复建议

后台查看订单时要通过Session机制判断用户身份，做好平行权限控制，服务端需要

校验相应订单是否和登录者的身份一致，如发现不一致则拒绝请求，防止平行权限绕过漏

洞泄露用户敏感个人隐私信息。

5.2 手机号码篡改测试

5.2.1 测试原理和方法

手机号通常可以代表一个用户身份。当请求中发现有手机号参数时，我们可以试着修

改它，测试是否存在越权漏洞。系统登录功能一般先判断用户名和密码是否正确，然后通

过Session机制赋予用户令牌。但是在登录后的某些功能点，开发者很容易忽略登录用户

的权限问题。所以当我们用 A 的手机号登录后操作某些功能时，抓包或通过其他方式尝

试篡改手机号，即可对这类问题进行测试。

5.2.2 测试过程

攻击者登录后，在操作某些功能时，抓包或通过其他方式尝试篡改手机号进行测试，

如图5-8所示。

图5-8 手机号码篡改流程图

以某网站办理挂失业务为例。

步骤一：以尾号0136手机登录，然后选择挂失业务，如图5-9所示。

图5-9 挂失业务

步骤二：抓包修改businessForALLFormBean.username=XXXXXXX0136为business ForALLFormBean.username=XXXXXXX9793，如图5-10所示。

图5-10 篡改手机号码

步骤三：手机号码参数篡改成功，成功挂失尾号为9793的手机号码，如图5-11所示：

图5-11 挂失成功

5.2.3 修复建议

后台请求要通过Session机制判断用户身份，如果需要客户端传输手机号码，则服务

端需要校验手机号是否和登录者的身份一致。如发现不一致则拒绝请求，防止平行权限绕

过。另外，对于手机 App 程序，不要过于相信从手机中直接读取的手机号码，还是要做

常规的身份认证，规范登录流程，防止未授权登录。

5.3 用户ID篡改测试

5.3.1 测试原理和方法

从开发的角度，用户登录后查看个人信息时，需要通过sessionid判定用户身份，然后

显示相应用户的个人信息。但有时我们发现在GET或POST请求中有userid这类参数传输，

并且后台通过此参数显示对应用户隐私信息，这就导致了攻击者可以通过篡改用户ID越

权访问其他用户隐私信息。黑色产业链中的攻击者也喜欢利用此类漏洞非法收集个人信

息。

5.3.2 测试过程

攻击者注册一个普通账户，然后遍历用户ID，获得其他用户信息，如图5-12所示。

图5-12 用户ID篡改测试流程图

某商城“修改收货人信息”处存在平行权限绕过业务漏洞。

步骤一：登录商城，找到收货地址单击“修改”按钮并抓包，发现 deliverId 参数，如图

5-13所示。

图5-13 修改收货地址

步骤二：将deliverId参数值“327343”修改为“327344”，如图5-14所示。

图5-14 修改收货人ID

步骤三：提交后返回非本账户的联系人相关信息，返回了deliverId=327344的收货人

信息，如图5-15所示。

图5-15 泄露其他收货人信息

5.3.3 修复建议

后台功能请求要通过 Session 机制判断用户身份，不要相信客户端传来的用户ID。如

果确实需要客户端传输userid，则服务端需要校验userid是否和登录者的Session身份一致，

如发现不一致则拒绝请求，防止被攻击者篡改，未授权访问他人账号内容。

5.4 邮箱和用户篡改测试

5.4.1 测试原理和方法

在发送邮件或站内消息时，篡改其中的发件人参数，导致攻击者可以伪造发信人进行

钓鱼攻击等操作，这也是一种平行权限绕过漏洞。用户登录成功后拥有发信权限，开发者

就信任了客户端传来的发件人参数，导致业务安全问题出现。

5.4.2 测试过程

攻击者抓包篡改发信请求，可伪造发信人，发送钓鱼信件，如图5-16所示。

图5-16 邮箱篡改测试流程

步骤一：编写邮件，单击“发送”按钮，如图5-17所示。

图5-17 写信

步骤二：使用Burp Suite工具将邮件发送数据包中的发件人参数“inputFrom”进行修改

并提交发送邮件，如图5-18所示。

图5-18 修改发件人

步骤三：收件时，发现发件人被篡改成功，如图5-19所示。

图5-19 发件人被篡改

5.4.3 修复建议

用户登录后写信、发送消息时要通过Session机制判断用户身份。如果需要客户端传

输邮箱、发件人，服务端需要校验邮箱、发件人是否和登录者的身份一致，如发现不一致

则拒绝请求，防止被攻击者篡改用于钓鱼攻击。

5.5 商品编号篡改测试

5.5.1 测试原理和方法

在交易支付类型的业务中，最常见的业务漏洞就是修改商品金额。例如在生成商品订

单、跳转支付页面时，修改 HTTP 请求中的金额参数，可以实现 1 分买充值卡、1元买特

斯拉等操作。此类攻击很难从流量中匹配识别出来，通常只有在事后财务结算时发现大额

账务问题，才会被发现。此时，攻击者可能已经通过该漏洞获得了大量利益。如果金额较

小或财务审核不严，攻击者则可能细水长流，从中获得持续的利益。事后发现此类漏洞，

就大大增加了追责的难度和成本。

此类业务漏洞的利用方法，攻击者除了直接篡改商品金额，还可以篡改商品编号，同

样会造成实际支付金额与商品不对应，但又交易成功的情况。攻击者可以利用此业务漏洞

以低价购买高价的物品。

5.5.2 测试过程

攻击者提交订单时，抓包篡改商品编号，导致商品与价格不对应但却交易成功，如图

5-20所示，攻击者从价格差中获利。

图5-20 商品编号篡改测试流程

步骤一：登录某积分商城http：//xxxxx.com.cn/club/index.php？m=goods&c=lists。

步骤二：列出积分换商品，先挑选出我想要的礼物，如商品编号为

goods_id=1419f75d406811e3ae7601beb44c5ff7.

需要30积分换购的商品，如图5-21所示。

图5-21 兑换礼品

步骤三：选择商城中积分最低的礼物兑换（5 积分的杯子），并填好相关信息，抓包

修改goods_id，如图5-22所示。

图5-22 篡改商品编号

步骤四：替换goods_id=1419f75d406811e3ae7601beb44c5ff7（30积分），替换成功，

如图5-23所示。

步骤五：订单页面显示用5积分换购需要30积分的鼠标成功，如图5-24所示。

图5-23 兑换成功

图5-24 订单信息

5.5.3 修复建议

建议商品金额不要在客户端传入，防止被篡改。如果确实需要在客户端传输金额，则

服务端在收到请求后必须检查商品价格和交易金额是否一致，或对支付金额做签名校验，

若不一致则阻止该交易。

5.6 竞争条件测试

5.6.1 测试原理和方法

竞争条件通常是在操作系统编程时会遇到的安全问题：当两个或多个进程试图在同一

时刻访问共享内存，或读写某些共享数据时，最后的竞争结果取决于线程执行的顺序（线

程运行时序），称为竞争条件（Race Conditions）。

在Web安全中，我们可以沿用这个概念，在服务端逻辑与数据库读写存在时序问题

时，就可能存在竞争条件漏洞，如图5-25所示。攻击者通常利用多线程并发请求，在数据

库中的余额字段更新之前，多次兑换积分或购买商品，从中获得利益。

图5-25 竞争条件漏洞

例如，如下PHP代码片段就存在此竞争条件漏洞。

5.6.2 测试过程

攻击者在提交订单时抓包，然后设置很多个线程重放此包。如图5-26所示，在众多请

求中，个别请求就有可能争取绕过金额、次数的判断，交易成功，攻击者从中获利。

图5-26 时间竞争测试流程

某网站退款提现时存在竞争条件漏洞。申请退款时，点了两次，生成了两单退款申

请，如图5-27所示。

图5-27 申请退款

同时余额变成了负数，如图5-28所示。

图5-28 账户余额

退款申请没有经过财务审核，直接收到两笔七千多元的退款，如图5-29所示。

图5-29 提现成功

5.6.3 修复建议

如图5-30所示，在处理订单、支付等关键业务时，使用悲观锁或乐观锁保证事务的

ACID特性（原子性、一致性、隔离性、持久性），并避免数据脏读（一个事务读取了另

一个事务未提交的数据），解决竞争条件和并发操作可能带来的相关业务问题。

图5-30 竞争条件漏洞修补

第6章 业务授权访问模块

6.1 非授权访问测试

6.1.1 测试原理和方法

非授权访问是指用户在没有通过认证授权的情况下能够直接访问需要通过认证才能访

问到的页面或文本信息。可以尝试在登录某网站前台或后台之后，将相关的页面链接复制

到其他浏览器或其他电脑上进行访问，观察是否能访问成功。

6.1.2 测试过程

攻击者登录某应用访问需要通过认证的页面，切换浏览器再次访问此页面，成功访问

则存在未授权访问漏洞，如图6-1所示。

图6-1 非授权访问测试流程图

以某网站交费充值为例。

步骤一：在IE浏览器中登录某网站进行交费，如图6-2所示。

图6-2 成功缴费截图

步骤二：复制交费成功的URL，在火狐浏览器里访问，成功访问，如图6-3所示。

图6-3 再次访问成功截图

6.1.3 修复建议

未授权访问可以理解为需要安全配置或权限认证的地址、授权页面存在缺陷，导致其

他用户可以直接访问，从而引发重要权限可被操作、数据库、网站目录等敏感信息泄露，

所以对未授权访问页面做Session认证，并对用户访问的每一个URL做身份鉴别，正确地

校验用户ID及Token等。

6.2 越权测试

6.2.1 测试原理和方法

越权一般分为水平越权和垂直越权，水平越权是指相同权限的不同用户可以互相访

问；垂直越权是指使用权限低的用户可以访问权限较高的用户。

水平越权测试方法主要是看能否通过A用户的操作影响B用户。

垂直越权测试方法的基本思路是低权限用户越权高权限用户的功能，比如普通用户可

使用管理员功能。

越权分类如图6-4所示。

图6-4

6.2.2 测试过程

6.2.2.1 水平越权测试

正常更改或查看A账户信息，抓包或者更改账户身份ID，成功查看同权限其他账户业

务信息，如图6-5所示。

以某网站后台为例，在核查任务编辑模块时，保存用户任务ID，如图6-6所示。

图6-5 水平权限测试流程图

图6-6 任务编辑模块

步骤一：保存任务并抓包，如图6-7所示。

图6-7 业务抓包

步骤二：可以看到请求中有taskHeader.taskId这个参数，也许这个参数是提交者的业

务ID，如果可以更改，能看到别的提交者（如果是同一权限的用户），则这里存在水平

越权的漏洞，现在利用爆破的方式自动更改taskHeader.taskId，如图6-8所示。

图6-8 更改业务ID

可以看到爆破自动更改taskHeader.taskId的值，响应状态为200，且响应长度也不一

样，查看响应包成功查看其他用户保存的核查任务，如图6-9所示。

图6-9 更改ID后查看同权限用户的业务信息

6.2.2.2 垂直越权测试

登录普通账户A，抓包或直接更改账户A身份ID为高权限C账户的ID，成功查看高权

限账户C的业务信息，如图6-10所示。

图6-10 垂直越权测试流程图

以某系统后台为例。

步骤一：通过手工猜解得出一个账号密码均为111的用户，成功登录，如图6-11所

示。

图6-11 成功登录系统

步骤二：通过查看得知超级管理员账号为admin。找到“修改密码”这一功能，将密码

改为789，单击“确定修改密码”后进行抓包，抓包后可以看到两个参数：uid和pwd，分别

表示用户名和密码。将参数uid的值由111改为admin，码保持789不变，如图6-12所示。

图6-12 更改数据包

步骤三：提交修改的数据包，提示密码修改成功，此时 admin 账号的密码已被改成

789，使用admin账号登录成功，如图6-13所示。

图6-13 高权限admin账户登录成功

6.2.3 修复建议

服务端需校验身份唯一性，自己的身份只能查看、修改、删除、添加自己的信息。

7.1 SQL注入测试

7.1.1 测试原理和方法

SQL注入就是通过把SQL命令插入Web表单提交或输入域名页面请求的查询字符串，

最终达到欺骗服务器执行恶意的SQL命令的目的。具体来说，它是利用现有应用程序，将

（恶意）SQL命令注入后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶

意）SQL 语句获取一个存在安全漏洞的网站上的数据库权限，而不是按照设计者的意图

去执行SQL语句。下面通过一个经典的万能密码登录案例深入浅出地介绍SQL注入漏洞。

SQL注入按照请求类型分为：GET型、POST型、Cookie注入型。GET与POST两种类

型的区别是由表单的提交方式决定的。按照数据类型可分为：数字型和字符型（数字也是

字符，严格地说就是一类，区别在于数字型不用闭合前面的SQL语句，而字符型需要闭

合）。测试方法分为报错型、延时型、盲注型、布尔型等。

数字型注入（一般存在于输入的参数为整数的情况下，如 ID、年龄等）测试方法如

下。

第一步：正常请求，查看页面。

第二步：在请求的参数后加and 1=1，如果可以添加执行，则和第一步的返回页面并

无差异。

第三步：在请求参数后加and 1=2，如果返回页面与第二步页面明显不同，或有所差

异，则断定存在数字型注入。

字符型注入（一般存在于接收的参数为字符串的情况下，如姓名、密码等）测试方法

如下。

第一步：正常请求查看页面（如查询admin用户信息，则返回admin用户的信息）。

第二步：在查询的参数后加’or 1=1（有时可以加--来注释后面的语句），加单引号的

目的是闭合前面的SQL语句并与后面的语句形成语法正确的SQL语句。如果可以添加并能

够执行，则返回除 admin 用户外所有用户的信息。这时可以判断存在字符型注入。

7.1.2 测试过程

攻击者确定疑似的数字型注入链接，按照数字型手工注入方式进行手工判断，若确定

存在漏洞后，可用手工注入方式查询数据或使用注入工具查询数据库数据，如图7-1所

示。

图7-1 数字型注入测试流程图

7.1.2.1 数字型注入

以网站http：//XXX.XXX.com/sydwzwb/zwxq.php？id=3974为例。

步骤一：正常访问，查看页面，如图7-2所示。

在参数后加单引号或者%27，即可在参数后构造SQL语句。由于SQL语句单引号是成

对出现的，添加单引号则SQL语句是错误的语句，不能被SQL解释器正常解析。访问报错

说明SQL语句执行了，如图7-3所示。

图7-2 正常访问页面

图7-3 添加单引号页面显示

步骤二：在ID参数后加and 1=1，查看页面，发现与第一步并无异样，如图7-4所示。

图7-4 添加and 1=1页面显示

步骤三：添加and 1=2，并查看页面，如图7-5所示。

图7-5 添加and 1=2页面显示

如果发现与第二步完全不同，则可以证明存在数字型注入，利用专门的SQL注入工具

（如sqlmap）可以拥有数据库增、删、改、查权限，甚至可以执行系统命令、上传后门文

件等。sqlmap 工具下载使用说明详见其官网 http：//sqlmap.org/，如图 7-6所示。

图7-6 用sqlmap跑数据

7.1.2.2 字符型注入

攻击者确定疑似的字符型注入链接，按照字符型手工注入方式进行手工判断，若确定

存在漏洞后，可用手工注入方式查询数据或使用注入工具查询数据库数据，如图7-7所

示。

图7-7 字符型注入测试流程图

以网站http：//xxx/Organ！loadOrgs.shtml为例。

步骤一：正常访问，抓包并查看页面，如图7-8所示。

图7-8 正常访问返回包情况

在参数后加单引号或者%27（由于 SQL 语句单引号是成对出现的，添加单引号则

SQL语句是错误的语句，不能被SQL解释器正常解析。访问报错说明SQL语句执行了），

即可在参数后构造SQL语句，如图7-9所示。

图7-9 添加单引号返回包情况

步骤二：添加’or‘1’=’1，查看页面，如图7-10所示。

图7-10 添加’or‘1’=’1返回包情况

不仅查询出10100095的信息，所有信息都可以查询到，用sqlmap可以进一步验证漏

洞，如图7-11所示。

图7-11 sqlmap注入成功

以上两种注入都是基于报错信息手工测试和工具注入，还有基于时间、盲注、布尔型

等的注入，在这就不一一举例了。

7.1.3 修复建议

每个提交信息的客户端页面、通过服务器端脚本（JSP、ASP、ASPX、PHP等）生成

的客户端页面、提交的表单（FORM）或发出的链接请求中包含的所有变量，必须对变量

的值进行检查，过滤其中包含的特殊字符，或对字符进行转义处理。特殊字符如下。

· SQL语句关键词：如and、or、select、declare、update、xp_cmdshell；

· SQL语句特殊符号：’、”、；等。

此外，Web 应用系统接入数据库服务器使用的用户不应为系统管理员，用户角色应

遵循最小权限原则。

7.2 XSS测试

7.2.1 测试原理和方法

跨站脚本漏洞是Web应用程序在将数据输出到网页的时候存在问题，导致恶意攻击者

可以往Web页面里插入恶意JavaScript、HTML代码，并将构造的恶意数据显示在页面的漏

洞中。攻击者一般利用此漏洞窃取或操纵客户会话和 Cookie，用于模仿合法用户，从而

使攻击者以该用户身份查看或变更用户记录以及执行事务。

跨站一般情况下主要分为存储型跨站、反射型跨站、DOM型跨站。存储型跨站脚本

可直接写入服务端数据库，而反射型不写入数据库，由服务端解析后在浏览器生成一段类

似<script>alert（/xss/）</script>的脚本。

反射型跨站测试方法主要是在URL或输入框内插入一段跨站脚本，观察是否能弹出对

话框。

存储型跨站测试方法主要是在网站的留言板、投诉、建议等输入框内输入一段跨站脚

本，看是否能插入数据库，插入成功的表现为当网站管理人员查看该留言时，会执行跨站

语句（如弹出对话框），或者当普通用户再次访问该页面时，会执行跨站语句，如弹出对

话框。

7.2.2 测试过程

发现疑似存在跨站链接，在漏洞参数处添加测试漏洞payload，如果达到测试目的则

确定跨站漏洞存在，根据漏洞实际类型分为反射型跨站、存储型跨站，如图7-12所示。

图7-12 XSS漏洞测试流程图

7.2.2.1 反射型XSS

以http：//xxx.xxx.local中高级搜索模块为例，如图7-13所示。

图7-13 高级搜索业务模块

步骤一：抓包并在工单编号输入处添加测试是否存在XSS漏洞的测试代码，如图7-14

所示。

图7-14 抓取业务请求包并添加验证漏洞payload

步骤二：成功弹出对话框，并证明XSS漏洞存在，如图7-15所示。

图7-15 漏洞成功触发

7.2.2.2 存储型XSS

以http：//xxx.xxx.local为例，在商调函模块存在新建、编辑、删除的模块，如图7-16

所示。

图7-16 业务模块

新建一工单并在功能说明处添加XSS payload，这时数据会存储于数据库，于是就会

造成存储型XSS，如图7-17所示。

图7-17 漏洞成功触发

7.2.3 修复建议

每个提交信息的客户端页面、通过服务器端脚本（JSP、ASP、ASPX、PHP等）生成

的客户端页面、提交的表单（FORM）或发出的链接请求中包含的所有变量，必须对变量

的值进行检查，过滤其中包含的特殊字符，或对字符进行转义处理。特殊字符如下。

· 客户端脚本（JavaScript、VBScript）关键字：JavaScript、script等。

此外，对于信息搜索功能，不应在搜索结果页面中回显搜索内容。同时应设置出错页

面，防止Web服务器发生内部错误时，将错误信息返回给客户端。具体建议如下：

· 定义允许的行为，确保Web应用程序根据预期结果的严格定义来验证所有输入参数

（Cookie、标头、查询字符串、表单、隐藏字段等）。

· 检查POST和GET请求的响应，以确保返回的对象是预期的内容且有效。

·

通过对用户提供的数据进行编码，从用户输入中移除冲突的字符、括号和单双引

号。这将防止插入的脚本以可执行的格式发送给最终用户。

·

只要可能，就应将客户端提供的所有数据限制为字母数字数据。使用此过滤机制

时，如果用户输入“<script>alertdocumentcookie（'aaa'）</script>”，将缩减

为“scriptalertdocumentcookiescript”。如果必须使用非字母数字字符，请先将其编码为

HTML 实体，然后再将其用在 HTTP 响应中，这样就无法将它们用于修改HTML文档的结

构。

· 使用双因素客户身份验证机制，而非单因素身份验证。

· 在修改或使用脚本之前，验证脚本的来源。

· 不要完全信任其他人提供的脚本并用在自己的代码中（不论是从Web上下载的，还

是熟人提供的）。

7.3 命令执行测试

7.3.1 测试原理和方法

在应用需要调用一些外部程序去处理内容的情况下，就会用到一些执行系统命令的函

数。如PHP中的system、exec、shell_exec等，当用户可以控制命令执行函数中的参数时，

将可注入恶意系统命令到正常命令中，造成命令执行攻击。测试中如果没有对参数（如

cmd=、command、excute=等）进行过滤，就可以直接造成命令执行漏洞或配合绕过及命

令连接符（在操作系统中，“&、|、||、；”都可以作为命令连接符使用，用户通过浏览器

提交执行命令，由于服务器端没有针对执行函数做过滤，导致在没有指定绝对路径的情况

下就执行命令）等进行命令执行漏洞测试。

7.3.2 测试过程

攻击者发现疑似存在命令执行的漏洞链接，添加命令执行payload，确认漏洞，如图7-18所示。

图7-18 命令执行漏洞测试流程

以某网络安全审计系统为例，由于未对register_key参数进行过滤可能存在命令执行漏

洞，抓包并对其进行测试，构造命令执行语句并执行成功，证明此参数未经严格过滤造成

命令执行漏洞，如图7-19和图7-20所示。

图7-19 抓包并进行测试

图7-20 漏洞成功执行

再以自己搭建的网站http：//localhost/DVWA/为例。

在dvwa处提供了一个免费的ping命令，如图7-21所示。

图7-21 ping命令

步骤一：我们ping一下自己的主机并抓包，如图7-22所示。

步骤二：由于ip接收一个参数并执行ping命令，如果接收的参数没有过滤就可以

用“&、|、||、；”构造语句，进行命令执行漏洞测试，成功执行系统命令，如图7-23所

示。

图7-22 抓取请求包

图7-23 漏洞成功触发

7.3.3 修复建议

尽量少用执行命令的函数或者直接禁用，参数值尽量使用引号包括在使用动态函数之

前，确保使用的函数是指定的函数之一，在进入执行命令的函数/方法之前，对参数进行

过滤，对敏感字符进行转义。

第8章 回退模块测试

8.1 回退测试

8.1.1 测试原理和方法

很多Web业务在密码修改成功后或者订单付款成功后等业务模块，在返回上一步重新

修改密码或者重新付款时存在重新设置密码或者付款的功能，这时如果能返回上一步重复

操作，而且还能更改或者重置结果，则存在业务回退漏洞。

8.1.2 测试过程

攻击者按正常流程更改业务信息，更改完成后可回退到上一流程再次成功修改业务信

息，如图8-1所示。

图8-1 业务回退测试流程

以某网站修改密码为例。

步骤一：密码修改成功后，进行回退测试（检查是否可以回退，并进行操作，如果存

在，可能存在回退漏洞），首先按照正常流程更改密码，如图8-2所示。

图8-2 密码重置成功

步骤二：尝试是否可以进行回退，结果可以回到重置密码这一步，即第三步，可以修

改密码，成功且无限制，如图8-3所示。

图8-3 回退可再次进行修改

8.1.3 修复建议

对于业务流程有多步的情况，如修改密码或重置密码等业务，首先判断该步骤的请求

是否是上一步骤的业务所发起的，如果不是则返回错误提示或页面失效。

9.1 验证码暴力破解测试

9.1.1 测试原理和方法

验证码机制主要被用于防止暴力破解、防止DDoS攻击、识别用户身份等，常见的验

证码主要有图片验证码、邮件验证码、短信验证码、滑动验证码和语音验证码。

以短信验证码为例。短信验证码大部分情况下是由4～6位数字组成，如果没有对验证

码的失效时间和尝试失败的次数做限制，攻击者就可以通过尝试这个区间内的所有数字来

进行暴力破解攻击。

9.1.2 测试过程

攻击者填写任意手机号码进行注册，服务器向攻击者填写的手机号码发送短信验证

码，攻击者设置验证码范围 000000～999999、00000～99999、0000～9999，对验证码进

行暴力破解，通过返回数据包判断是否破解成功，然后通过破解成功的验证码完成注册，

如图9-1所示。

以某会员网站任意手机号码注册为例。

步骤一：填写任意号码进行注册，本案例使用手机号码为16666666666，单击获取手

机动态码，会向手机发送一条验证码信息，如图9-2所示。

图9-1 短信验证码暴力破解测试流程

图9-2 获取短信验证码

步骤二：快速登录，抓取数据包，对code参数进行暴力破解，如图9-3所示。

图9-3 抓取登录数据包

破解信息如下，如图9-4所示。

图9-4 暴力破解

步骤三：通过返回值的长度可判断 46547 为正确的验证码，使用该验证码可成功登录

网站，获取个人信息，如图9-5所示。

图9-5 登录成功

9.1.3 修复建议

针对验证码的暴力测试，建议采取如下的加固方案：

（1）设置验证码的失效时间，建议为180秒；

（2）限制单位时间内验证码的失败尝试次数，如5分钟内连续失败5次即锁定该账号

15分钟。

9.2 验证码重复使用测试

9.2.1 测试原理和方法

在网站的登录或评论等页面，如果验证码认证成功后没有将session及时清空，将会导

致验证码首次认证成功之后可重复使用。测试时可以抓取携带验证码的数据包重复提交，

查看是否提交成功。

9.2.2 测试过程

攻击者填写投诉建议，输入页面验证码，抓取提交的数据包，使用发包工具对数据包

进行重复提交，然后查看投诉建议页面是否成功提交了多个投诉信息，如图9-6所示。

图9-6 验证码重复使用测试流程

以某App手机客户端应用程序为例。

步骤一：在客户投诉建议处，输入要投诉的内容，并输入验证码，如图9-7所示。步

骤二：抓取数据包并修改投诉内容参数complaintsContent的值，如图9-8所示。通过Burp Suite工具重复提交投诉信息，如图9-9所示。

图9-7 填写投诉信息

图9-8 抓取数据包

图9-9 暴力重复提交

步骤三：经过暴力重复提交后，客户端显示提交成功，如图9-10所示。

图9-10 提交成功

步骤四：返回页面查看历史投诉建议内容，可看到通过首次验证码认证，成功提交了

多次投诉，如图9-11、图9-12所示。

图9-11 成功提交多次投诉

图9-12 查看投诉信息

9.2.3 修复建议

针对验证认证次数问题，建议验证码在一次认证成功后，服务端清空认证成功的

session，这样就可以有效防止验证码一次认证反复使用的问题。

9.3 验证码客户端回显测试

9.3.1 测试原理和方法

当验证码在客户端生成而非服务器端生成时，就会造成此类问题。当客户端需要和服

务器进行交互发送验证码时，可借助浏览器的工具查看客户端与服务器进行交互的详细信

息。

9.3.2 测试过程

攻击者进入找回密码页面，输入手机号与证件号，获取验证码，服务器会向手机发送

验证码，通过浏览器工具查看返回包信息，如果返回包中包含验证码，证明存在此类问

题，如图9-13所示。

图9-13 验证码客户端回显测试流程

以某P2P金融平台为例。

步骤一：使用浏览器访问该网站，在找回密码页面中任意输入一个手机号码和开户证

件号，如图9-14所示。

图9-14 输入手机号与证件号

步骤二：单击“下一步”按钮，即可向该手机发送短信验证码。按 F12 键启用浏览器调

试工具可看到短信验证码在本地生成，如图9-15所示。

图9-15 查看本地生成的验证码

步骤三：输入本地生成的验证码，如图9-16所示。

图9-16 输入验证码

进入重置密码页面，如图9-17所示。

图9-17 进入密码重置页面

步骤四：重置密码成功，如图9-18所示。

图9-18 重置成功

9.3.3 修复建议

针对验证码在客户端回显的情况，建议采取如下措施来预防此类问题：

（1）禁止验证码在本地客户端生成，应采用服务器端验证码生成机制；

（2）设置验证码的时效性，如180秒过期；

（3）验证码应随机生成，且使用一次即失效。

9.4 验证码绕过测试

9.4.1 测试原理和方法

在一些案例中，通过修改前端提交服务器返回的数据，可以实现绕过验证码，执行我

们的请求。

9.4.2 测试过程

攻击者进入注册账户页面，输入任意手机号码，获取验证码，在注册账户页面填写任

意验证码，提交请求并抓包，使用抓包工具查看并修改返回包信息，转发返回数据包，查

看是否注册成功，如图9-19所示。

图9-19 验证码绕过测试流程

以某P2P网站系统注册功能为例。

步骤一：首先输入任意手机号码和密码，我们此处以 18888888886 为例，单击“获取

手机验证码”，由于我们无法获取到18888888886这个手机的真实验证码，我们随意填写一

个验证码1234，如图9-20所示。

步骤二：单击注册领红包并通过 burp 对数据包进行截获，右击选择 Do intercept-Response to this request，如图9-21所示。

图9-20 输入手机号码

图9-21 抓取数据包

步骤三：然后单击 Forword 后，burp 工具里显示的就是网站返回的数据包。因为我

们填写的手机验证码1234肯定是错误的，而此时res_code的值为1，证明了当手机验证码

错误时res_code的值为1。我们将返回数据包中的res_code的值改为0，从而实现绕过验证

码，如图9-22所示。

步骤四：继续单击Forword后，即可成功注册该手机号码18888888886的账号并登录跳

转到用户界面，如图9-23所示。

图9-22 修改返回值

图9-23 注册成功并登录

9.4.3 修复建议

针对此漏洞，建议在服务端增加验证码的认证机制，对客户端提交的验证码进行二次

校验。

9.5 验证码自动识别测试

9.5.1 测试原理和方法

前面几小节介绍的测试方法主要针对业务逻辑设计上存在缺陷的验证码机制，而事实

上还有很大一部分验证码机制在逻辑上并不存在问题，这就涉及与验证码机制本身的正面

对抗，也就是验证码识别技术。

网站登录页面所使用的图形验证码是出现最早也是使用最为广泛的验证码，我们就以

图形验证码为例来讲解如何对其进行自动识别。

一般对于此类验证码的识别流程为：图像二值化处理→去干扰→字符分割→字符识

别。

图像二值化就是将图像上像素点的灰度值设置为0或255，也就是将整个图像呈现出明

显的黑白效果。

为了防止验证码被自动识别，通常用加入一些点、线、色彩之类的方式进行图像干

扰，如图9-24所示。

图9-24 验证码图像干扰

所以为了达到良好的识别效果，需要对图像进行去干扰处理。

字符分割主要包括从验证码图像中分割出字符区域，以及把字符区域划分成单个字

符。

字符识别就是把处理后的图片还原回字符文本的过程。

9.5.2 测试过程

攻击者访问网站登录页面，通过刷新验证码页面查看验证码组成规律，进行图像二值

化、去干扰等处理，并进行人工比对，存储成功识别的验证码包，截入工具，利用工具对

登录页面进行暴力破解，根据返回包的大小和关键字判断是否破解成功，如图9-25所示。

以某游戏站点为例。

图9-25 验证码自动识别测试流程

步骤一：首先通过多次刷新验证码，发现验证码主要由数字或小写字母组成，于是通

过PKAV HTTP Fuzzer工具设定一个验证码包含的字符范围，如图9-26所示。

图9-26 设定验证码字符范围

步骤二：通过第三方识别工具可以自动对验证码图像进行二值化、去干扰等处理，然

后通过人工比对来完善识别的准确率，如图9-27、图9-28所示。

步骤三：当识别的准确率符合自己预期的效果后（比如达到90%以上），就可以对登

录页面进行抓包分析了，通过Burp Suite工具抓取登录的数据包，如图9-29所示。

图9-27 验证码人工比对

图9-28 验证码人工比对

图9-29 抓取登录数据包

步骤四：将抓取到的请求数据包放至PKAV HTTP Fuzzer工具的请求包内，设置验证

码标志位，用户名和密码标志位，如图9-30所示。

图9-30 设置请求包

单击即可开始对账号密码进行暴力破解，验证码会自动载入，如图9-31所示。

图9-31 暴力破解

查看请求结果，可发现一个长度为611的返回包，用户名和密码为admin：admin，可

成功登录网站，如图9-32所示。

图9-32 成功登录

9.5.3 修复建议

针对验证码被自动识别的风险，建议通过以下几个方面来进行加固：

（1）增加背景元素的干扰，如背景色、背景字母等；

（2）字符的字体进行扭曲、粘连；

（3）使用公式、逻辑验证方法等作为验证码，如四则运算法、问答题等；

（4）图形验证码和使用者相关，比如选择联系人头像、选择购买过的物品等作为验

证码。

10.1 商品支付金额篡改测试

10.1.1 测试原理和方法

电商类网站在业务流程整个环节，需要对业务数据的完整性和一致性进行保护，特别

是确保在用户客户端与服务、业务系统接口之间的数据传输的一致性，通常在订购类交易

流程中，容易出现服务器端未对用户提交的业务数据进行强制校验，过度信赖客户端提交

的业务数据而导致的商品金额篡改漏洞。商品金额篡改测试，通过抓包修改业务流程中的

交易金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并