《web攻防之业务安全实战指南》笔记

前言

登录认证模块测试

暴力破解测试

原理和方法

暴力破解测试简单地说就是对应用系统用户登录账号与密码进行穷举测试，针对账号或密码进行逐一比较，知道找出正确的账号与密码

一般有三种情况：

• 在已知账号的情况下，加载密码字典针对密码进行穷举测试
• 在未知账号的情况下，加载账号字典，并结合密码字典进行穷举测试
• 在未知账号和密码的情况下，利用账号字典和密码字典进行穷举测试

测试过程

1. 利用bp抓包，通过Proxy选项卡将请求数据截断
2. 通过将请求数据分发给Intruder模块，进行爆破
3. 通过查看Length属性值长度不同或者查看Response返回信息或者Status返回状态来判断暴力破解密码是否成功

修复建议

1. 增加验证码，每登录失败一次就边换一次
2. 配置登录失败次数限制策略，如在同一账号尝试登录的情况下，5分重内连续失败超过5次就禁止此用户在3小时内登录系统（实际上还可以继续添加，如果3小时候再5次登录失败就直接把ip给ban了）
3. 再条件允许的情况下，增加手机接收短信验证码邮箱接收邮件验证码，实现双因素认证的防暴力破解机制（但会造成短信轰炸和邮箱轰炸，所以这里设置的时候也要添加一些设置）

本地加密传输测试

测试原理和方法

本地加密传输测试时针对客户端和服务器的数据传输，查看数据是否采用SSL（安全套接层）加密方式加密。

测试过程

主要分以下几个步骤：

1. 使用Wireshark网络抓包工具，选择与公网连接的本地网卡并开启捕捉功能。
2. 再浏览器中访问要测试的HTTPS协议网站，并输入用户名及密码进行登录操作
3. 用Wireshark工具捕捉登录的请求包，并通过请求包的内容判断是否进行了加密。

修复建议

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

Session测试

Session会话固定测试

原理

Session是应用系统对浏览器客户端属性认证的属性标识，再用户u推出应用系统时，应该将Session认证属性标识清空。如果没有清空的话，系统会重复利用这个Session标识进行认证会话。

攻击者可以利用这种漏洞生成固定Session会话，并诱骗用户利用攻击者生成的固定会话进行系统登录，从而导致用户会话认证被窃取

测试过程

1. 注销退出系统前，利用bp抓包，保存本次授权的SessionID
2. 退出系统后重新登录系统，并对请求数据进行抓包拦截
3. 对比两次的SessionID

修复建议

客户端登录系统时，应该先判断客户端是否提交浏览器的留存Session认证会话属性标识，客户端提交此信息至服务端时，应及时销毁浏览器留存的Session认证会话，并要求客户端浏览器重新生成Seesion认证会话属性标识。

Session会话注销测试

原理

Session是应用系统对浏览器客户端身份认证的属性标识，再用户注销或退出应用系统时，系统应将客户端Session认证属性标识清空。如果没能清空，则认证会话将持续有效，此时攻击者获得该Session认证会话会导致用户权限被盗取

测试过程

1. 利用bp抓包，得到登录系统后的Session认证参数值并保存
2. 在截取窗口中将数据发送到Repeater模板
3. 退出系统
4. 在Repeater模块相应授权数据信息中再次发送授权访问请求并查看系统是否对退出后的用户授权Session进行解除授权。

修复建议

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

Session会话超时时间测试

原理

用户成功登录系统获得Session认证会话后，该Session认证应该具有生命周期，如果在固定时间内，用户与服务器没有任何交互操作，就应该销毁用户的Session认证会话信息，要求用户重新登录

测试过程

1. 对已登录授权的系统页面利用bp抓包获取Session认证参数值，并保存
2. 将请求数据发送到Repeater模块中
3. 三十分钟内不再使用该授权会话与服务器进行交互访问，三十分钟后再Repeater模块发送授权访问请求并查看系统返回结果是否存在授权后可查阅的特殊信息

修复建议

对每个生成的Session认证会话配置生命周期

Cookei仿冒测试

原理

服务器为鉴别客户端浏览器会话及身份信息，会将用户身份信息存储在Cookie中，并发送至客户端存储。攻击者通过尝试修改Cookie中的身份标识，从而达到仿冒其他用户身份的目的，并拥有相关用户的所有权限

测试过程

1. 登录进系统并对浏览器页面进行刷新
2. 利用bp抓包获取cookie，并通过将cookie的数值进行修改
3. 查看提交后返回的信息

修复建议

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

密文比对认证测试

原理

系统登录时密码加密流程一般是先将用户名和密码发送到服务器，服务器会把用户提交的密码经过Hash算法加密后和数据库中存储的加密值比对，如果加密值相同，则判定用户提交密码正确。

但有些网站系统时在前台浏览器客户端对密码进行Hash加密后传输给服务器并于数据库加密值进行对比，如果一样就判断密码正确。

这样会泄露密码加密方式，导致出现安全隐患

测试过程

1. 通过bp抓包并根据页面代码分析后正式登录传输口令使用何种加密方式
2. 利用bp中的暴力破解测试配置，对要破解的密码进行数据处理转换

修复建议

将密码加密过程以及密文比对过程防止在服务器后台执行。

登录失败信息测试

原理

用户登录系统失败时会出现一些信息，如果用户名不存在、账号不存在等

测试过程

1. 在登录窗口输入不存在用户名和密码，查看返回信息
2. 在登录窗口输入存在的用户名和错误密码，查看返回信息

修复建议

模糊失败语句

业务办理模块测试

订单ID篡改测试

原理

在电子交易业务网站中，用户登录后可以下订单购买相应产品，购买成功后用户可以查看订单的详情。当开发人员没有考虑登陆后用户间权限隔离的问题，就会导致平行权限绕过漏洞，攻击者只需要注册一个普通账号，就可以通过篡改、遍历订单id从而获得其他用户订单详情。

测试过程

1. 登录账号
2. 通过抓包修改参数（保单号），进行越权查看他人保单内容

修复建议

后台查看订单时要通过session机制判断用户身份，做好平行权限控制，服务端需要校验相应订单是否和登陆者的身份一致，不一致则拒绝请求。

手机号码篡改测试

原理

系统登录功能一般先判断用户名和密码是否正确，然后通过Session机制赋予用户令牌。但在登录后的某些功能点，开发者很容易忽略登录用户的权限问题，所以当我们用A的手机号登录后操作某些功能时，抓包或通过其他方式尝试篡改手机号，即可对这类问题进行测试

测试过程

书本的测试过程是在某办理挂失业务的网站进行的

1. 以0136为尾号的手机进行登录，然后选择挂失业务。
2. 抓包修改参数，将username的手机号参数修改成9793，而验证身份的地方依旧还是0136不变
3. 手机篡改成功，成功挂失尾号为9793的手机号码

修复建议

后台请求要通过session机制判断用户身份，如果需要客户端传输手机号码，则服务端需要校验手机号是否和登陆者的身份一致，不一致则拒绝请求。而对于手机APP程序，不要过于相信从手机中直接读取的手机号码，要做常规的身份认证，规范登录流程，防止未授权登录

用户ID篡改测试

原理

在开发者角度看，用户登录后查看个人信息时，需要通过sessionid判定用户身份，然后显示相应用户的个人信息。但有时我们发现在GET或POST请求中有userid这种关键参数传输，并且后台通过这种参数显示对应用户隐私信息，因此可以进行篡改用户id越权访问。

测试过程

测试使用的是商城网站

1. 登录商城，找到收获地址点击修改按钮并抓包，发现参数deliverID
2. 将参数数值进行修改
3. 提交返回并非本账号的联系人相关信息

修复建议

后台功能请求要通过Session机制判断用户神风，不要相信客户端传来的用户ID。如果需要使用客户端传输的id，则需要对这个id进行校验是否和登陆这的session身份一致

邮箱和用户篡改测试

原理

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

测试过程

1. 编写邮件
2. bp抓包将邮件中的发件人参数inputFrom进行修改然后提交发送邮件
3. 收件时发现发件人被篡改成功

修复建议

用户登录后写信、发送消息时要通过Session机制判断用户身份，如果需要客户端传输邮箱、发件人，服务端需要校验邮箱、发件人是否和登录者的身份一致

商品编号篡改测试

原理

在生成商品订单、跳转支付页面时，修改HTTP请求中的金额参数，可以实现1分买充值卡等操作。此类攻击很难从流量中匹配识别出来，通常只有在时候财务结算时才能发现大额账务问题。

除了修改金额外，还可以篡改商品编号，这样会造成实际支付金额与商品不对应，但又交易成功。

测试过程

1. 登录商城，找到自己想要的物品
2. 选好进行bp抓包，修改参数
3. 提交后发现够吗i成功

修复建议

建议商品金额不要在客户端传入，防止被篡改。如果确实需要在客户端传输金额，则服务端在收到请求后必须检查商品价格和交易金额是否一致，或对支付金额做签名校验。

竞争条件测试

原理

竞争条件通常时在操作系统编程时会遇到的安全问题：当两个或者多个进程视图在同一时刻访问共享内存，或读写某些共享数据时，最后的竞争结果取决于线程执行的顺序

在web安全中，我们可以沿着这个概念，在服务端逻辑与数据库读写存在时序问题时，就可能存在竞争条件漏洞。攻击者通常利用多线程并发请求，在数据库中的余额子段更新前，多次兑换积分或购买商品，从中获得利益。

测试过程

攻击者在提交订单时进行抓包，然后设置多个线程重放此包。

修复建议

在处理订单、支付等关键业务时，使用悲观锁或者乐观锁保证事务的ACID特性，并避免数据脏读。

业务授权访问模块

非授权访问模板

原理

非授权访问是指用户在没有通过认证授权的情况下能够直接访问需要通过认证才能访问到的页面或文本信息。可以尝试登录某网站前台或后台之后，将相关的页面连接复制到其他浏览器或其他电脑上进行访问，观察是否能访问成功

测试过程

1. 在浏览器中登录某网站进行相关操作（如缴费）
2. 复制操作成功后的url（如缴费成功后的url），在另一个浏览器中访问

修复建议

未授权访问可以理解未需要安全配置或权限认证的地址、授权页面存在缺陷，导致其他用户可以直接访问，从而引发重要权限可被操作、数据库、网站目录等敏感信息泄露，所以对未授权访问页面做Session认证，并对用户访问的每一个URL做身份鉴别，正确地校验用户ID以及Token等。

越权测试

原理

越权一般分为水平越权和垂直越权，水平越权是指相同权限地不同用户可以互相访问，垂直越权是指使用权限低地用户可以访问权限高得用户

测试过程

水平越权：

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

如在某网站后台为例，在何查任务编辑模块时，保存用户任务ID

1. 保存任务并抓包
2. 在请求中发现ID得参数，进行修改（通过爆破获取哪个ID是有效ID）

垂直越权：

登录普通用户A，抓包或直接更改用户A身份ID为更高权限C账户得ID，成功查看高权限账户C得业务信息

1. 通过手工才接得出一个账号密码为111得用户，成功登录
2. 通过查看得知超级管理员账号为admin，在修改密码功能出将密码修改为789，然后进行抓包，发现参数uid和pwd，将uid的数值修改为admin，码保存789不变
3. 提交修改的数据报，得到密码秀嘎i成功，直接使用admin账号登录

修复建议

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

输入/输出模块测试

SQL注入测试

原理

通过把SQL命令插入Web表单提交或输入域名页面请求的查询字符串，最终达到欺骗服务器执行而已的SQL命令的目的。

数字型

一般存在于输入的参数为整数的情况下，如ID、年龄等

1. 正常请求，查看页面
2. 在请求的参数后加and 1=1，如果可以添加执行，则和第一步返回的页面一样
3. 在请求参数后加and 1=2，如果返回页面跟第二部页面不同，或存在差异，则存在数字型注入

字符型

一般存在于接收的参数为字符串的情况下，如姓名、密码等

1. 正常请求查看页面
2. 在查询参数后加‘or 1=1–，加单引号的目的是闭合前面的SQL语句并于后面的语句形成语法正确的SQL语句。如果可以添加并能够执行，则返回除admin用户外所有用户的信息，这时就可以判断存在字符型注入

测试过程

数字型

1. 正常访问，查看页面。在参数后面加单引号或者%27。由于SQL语句单引号是成对出现的，添加单引号则SQL语句是错误的语句，不能被SQL解释器正常解析，访问报错就说明SQL语句执行了
2. 在ID参数后加and 1=1，查看页面，发现于第一步并无异样
3. 添加and 1=2，查看页面，如果发现与第二步不同，则证明存在数字型注入，后续继续手工注入或sqlmap一把梭

字符型

1. 正常访问，查看页面。在参数后面加单引号或者%27。由于SQL语句单引号是成对出现的，添加单引号则SQL语句是错误的语句，不能被SQL解释器正常解析，访问报错就说明SQL语句执行了
2. 在ID参数后加’ or ‘1’=’1，查看页面，然后发现能够查询到所有的信息，则说明存在字符型注入，后续上sqlmap

修复建议

每个提交信息的客户端页面、通过服务器端脚本（JSP、ASP、ASP下、PHP等）生成的客户端页面、提交的表单或发出的连接请求中包含的所有变量，必须对变量的值进行检查，过滤其中包含的特殊字符或对字符进行转义

• SQL语句关键字：and、or、select、declare、update、xp_cmdshell;等
• SQL语句特殊符号：’、“；等

web应用系统接入数据库服务器使用的用户不应为系统管理员，用户角色应遵循最小权限原则。

Xss测试

原理

xss是web应用程序在将数据输出到网页的时候存在问题，导致恶意攻击者可以网web页面里插入而已JS、HTML代码，并将构造的恶意数据显示在页面的漏洞中（常用就是盗取cookie、操纵用户会话）

一般分为存储型、反射性还有DOM型

反射性主要在url或输入框内输入，观察是否能弹出对话框

存储型主要是在网站的留言板、投诉、建议等输入框内输入一段跨站脚本，看是否能插入数据库，如果成狗则当查看该留言时会弹窗。

测试过程

反射型

1. 抓包并在输入处添加测试是否存在Xss漏洞的测试代码
2. 查看是否成功弹出对话框

存储型

1. 在内容框内输入payload
2. 然后点击输入的内容（如帖子或建议什么的），查看是否有弹窗

修复建议

跟SQL差不多，对关键字或者符号进行转义或过滤

• HTML标签的<、”、‘、%等，以及这些符号的Unicode值
• 客户端脚本的关键字：JavaScript、script等

除外，对于信息搜索功能，不应在搜索结果页面中回显搜索内容，同时应该设置出错页面，防止Web服务器发生内部错误时，将错误信息返回给客户端

• 定义允许的行为，确保Web应用程序根据予其结果的严格定义来验证所有输入参数（Cookie、标头、查询字符串、表单、隐藏字段等）
• 检查POST和GET请求的相应，以确保返回的对象时予其的内容且有效
• 通过对用户提供的数据进行编码，从用户输入中移除冲突的字符、括号和单双引号。这将防止插入的脚本以可执行的格式发送给最终用户
• 应该将客户端提供的所有数据限制为字母数字数据
• 使用双因素客户身份验证机制，而非单因素身份验证
• 在修改或使用脚本之前，验证脚本的来源
• 不信任其他人提供的脚本并用在自己的代码中

命令执行测试

原理

在应用需要掉用一些外部程序去处理内容的情况下，就会用到一些执行系统命令的函数，如PHP中的system、exec、shell_exec等，当用户可以控制命令执行函数中的参数时，将可注入恶意系统命令到正常命令中，造成命令执行攻击。如果测试中没有对参数进行过滤，就可以直接造成命令执行漏洞或配合绕过及命令连接符，造成命令执行

测试过程

1. 对疑似能够执行命令执行的地方进行ping指令并抓包
2. 如果接收的参数没有过滤，就可以使用“&、|、||、；”构造语句，进行命令你个执行漏洞

127.0.0.1&&ipconfig

修复建议

尽量少用执行命令的函数或者直接禁用，参数值尽量使用引号包括在使用动态函数之前，确保使用的函数时指定的函数之一，在进入执行命令函数或方法之前，对参数进行过滤，对敏感字符进行转义。

回退模块测试

回退测试

原理

很多Web业务在密码修改成功后或订单付款成功后等业务模块，在返回上一步重新修改密码或者重新付款时存在重新设置密码或者付款的功能，这时如果能返回上一步重复操作，而且还能更改或者重置结果，则存在业务回退漏洞

测试过程

1. 密码修改后，进行回退测试。首先按照正常流程修改密码
2. 尝试是否可以进行回退，结果可以回到重置密码这一步的话，尝试是否能够修改密码，如果可以则存在漏洞

修复建议

对于业务流程有多步的情况，如修改密码或重置密码等业务，首先判断该步骤的请求是否时上一步的业务所发起的，如果不是则返回错误提示或页面失效

验证码机制测试

验证码暴力破解测试

原理

验证码机制主要被用于防止暴力破解、防止DDos攻击、识别用户身份等，常见的验证码主要有图片验证码、邮件验证码、短信验证码、滑动验证码和语音验证码

短信验证码：一般是4-6个数字组成，如果没有对验证码的失效时间和尝试失败次数做限制，攻击者就可以通过航是这个区间内的所有数字进行暴力破解攻击

测试过程

1. 找到注册界面，输入手机号后获取验证码信息
2. 快速登录，抓取数据报，对code参数进行暴力破解
3. 通过爆破返回值判断验证码是否正确，然后利用正确的验证码进入网站

修复建议

针对验证码的暴力测试，建议采取如下的加固方案：

1. 设置验证码的失效时间，一般是180秒
2. 限制单位时间内验证码的失败尝试次数，如5分钟连续失败5次就锁定该账号15分钟

验证码重复使用测试

原理

在网站的登录或评论等页面，如果验证码认证成功后没有将session及时清空，会导致验证码首次认证成功之后可重复利用。测试时可以抓取携带验证码的数据报重复提交，查看是否提交成功

测试过程

1. 在投诉建议处输入要投诉的内容，并输入验证码（实际上可以找留言的地方或者其他有验证码的地方）
2. 抓取数据报并修改内容，然后通过bp重复提交投诉信息
3. 重复提交后查看是否提交成功
4. 返回投诉建议处查看是否有内容出现，如果出现则说明存在验证码重复使用漏洞

修复建议

针对验证认证次数问题，应该在验证码使用后服务器马上清楚该验证码认证成功的session

验证码客户端回显测试

原理

当验证码在客户端生成而非服务器端生成时，就会造成此类问题。

当客户端需要和服务器进行交互发送验证码时，可借助浏览器的工具查看客户端于服务器进行交互的详细信息。

测试过程

1. 在密码找回界面输入手机号
2. 向手机发送短信验证码
3. 通过浏览器工具查看返回信息（一般打开f12在network处就能看见信息）
4. 查看返回信息里是否存在短信验证码，存在则说明存在漏洞

修复建议

1. 禁止验证码在本地客户端生成，应采用服务器端验证码生成机制
2. 设置验证码的有效时长
3. 验证码随机生成，且只能使用一次

验证码绕过测试

原理

通过修改前端提交服务器返回的数据，可以实现绕过验证码

测试过程

某注册账户页面

1. 输入任意手机号码，点击获取验证码
2. 输入任意一个验证码，提交请求并抓包
3. 查看并修改返回信息，转发数据包（例如在一些地方会通过返回一个code为1来确定前端验证这个数值是否正确或者错误，这时就可以进行一些操作）
4. 查看是否注册成功，如果成功则存在漏洞

修复原理

建议在服务端增加验证码的认证机制，对客户端提交的验证码进行二次校验

验证码自动识别测试

原理

这个跟验证码本身的逻辑没什么关系，主要是存在机制本身，简单说就是验证码识别技术。

一般对于此类验证码的识别流程为：图像二值化处理→去干扰→字符分割→字符识别

图像二值化是将图像上像素点的灰度值设置为0或255，让整个图片成黑白效果，让图片区分前景背景，简单的说就是进行降维处理。这样处理后虽然丢失很多信息，但是它的意义就在于简化后期的处理，提高处理速度。更详细的内容可以去看机器学习部分，这里就不过多阐述了。

因为现在的验证码为了防止被自动识别，因此会添加点、线、色彩之类的方式对图片进行干扰，所以为了达到良好的识别效果，需要对图像进行去干扰处理。

其中字符分割主要包括从验证码图像中分割出字符区域，以及把字符区域划分成单个字符。

字符识别就是把处理后的图片还原回字符文本的过程。

测试过程

1. 在网站验证码处多次刷新，得到验证码的规律（如是否大小写字母，是否有数字），然后通过PKAV HTTP Fuzzer工具设定一个验证码包含的字符范围
2. 通过第三方识别工具自动对验证码图像进行二值化、去干扰等处理，然后通过人工比对完善识别的准确度
3. 当识别的准确度达到预期效果后，就对页面进行抓包处理
4. 将数据包发送到PKAV HTTP Fuzzer工具的请求包内，设置验证码标志位，用户名和密码标志为，然后开始暴力破解

修复建议

1. 增加背景元素的干扰，如背景色、背景字母等
2. 字符的字符进行扭曲、粘连
3. 使用公式、逻辑验证方法等作为i验证码，如四则运算发、问答题等
4. 图形验证码和使用者相关，如选择联系人头像、选择购买过的物品等作为验证码（但这里我觉得按照作者这样处理会导致敏感信息的泄露，我感觉使用一张大的图片，然后切割成几个小部分，然后让用户根据提示选择有出现内容的部分，如一张图片里面有很多车，但只有左上角和中间有出现警车，这时就可以提示用户选择存在警车的部分（已经切割成9个部分））

业务数据安全测试

商品支付金额篡改测试

原理

电商类网站在业务流程整个环节，需要对业务数据的完整性和一致性进行保护，特别是确保在用户客户端于服务、业务系统接口之间的数据传输的一致性，通常在订购类交易流程中，容易出现服务器端未对用户提交的业务数据进行强制校验，过度信赖客户端提交的业务数据而导致的商品金额篡改漏洞。商品金额篡改测试，通过抓包修改业务流程中的交易金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并提交，查看能否以修改后的金额数据完成业务流程

测试过程

这种测试一般都是用实际支付远低于订单支付的金额订购商品的业务逻辑漏洞。

1. 选择一个商品，按正常操作进入支付页面
2. 抓包并篡改支付请求中的明文金额字段
3. 跳转支付平台，完成篡改后的订单支付流程
4. 如果支付平台完成后自动回到商城，显示订单成功生成并完成支付流程，就表名本次测试实现了这个篡改漏洞

修复建议

商品信息，如金额、折扣等原始数据的校验应该来自服务器端，不接受客户端传递过来的值

商品订购数量篡改测试

原理

本测试是通过在业务流程中抓包修改订购商品数量等字段，如将请求中的商品数量秀嘎i成任意非预期数额、负数等后进行提交，查看业务系统能否以修改后的数量完成业务流程

测试过程

1. 将积分商品放入购物车
2. 抓包将积分商品的积分参数修改为负数
3. 继续完成业务流程
4. 查看发现后端对比出现问题，未能支付成功（实际上如果填写的是0，可能就成功了）

修复建议

服务端应当考虑交易风险控制，对产生异常情况的交易行为（如用户积分数额为负数，兑换库存数量为0的商品等）应该直接给予限制、阻断而非继续完成整个交易流程

前端JS限制绕过测试

原理

很多商品在限制用户购买数量时，服务器仅在页面通过JS脚本限制，未在服务器端校验用户提交的数量，通过抓取客户端发送的请求包修改JS端生成处理的交易数据，如将请求中的商品数量改为大于最大数限制的值，查看能否以非正常业务交易数额完成业务流程

测试过程

一般的流程如下

1. 访问商品订购页面
2. 服务器响应并在前端通过JS限制用户的订购数量
3. 商品订购页面
4. 攻击者绕过JS限制提交超过限制数量范围的订购请求
5. 服务器判断用户支付数据是非合法，订单是否异常
6. 如果能以篡改后的数据完成交易流程则表明存在脆弱性

修复建议

商品信息，如金额、折扣、数量等原始数据的校验应来自于服务器端，不应该完全相信客户端传递过来的值。类似的跨平台支付业务，涉及平台之间接口调用，一定要做好对重要数据，如金额、商品数量等的完整性校验，确保业务重要数据在平台间传输的一致。

请求重放测试

原理

请求重放漏洞是电商平台业务逻辑漏洞中一种常见的由设计缺陷所引发的漏洞，通常情况下所引发的安全问题表现在商品首次购买成功后，参照订购商品的正常流程请求，进行完全模拟正常订购业务流程的重放操作，可以实现“一次购买多次收获”等违背正常业务逻辑的结果

测试过程

1. 在生成订单流程时抓取订购请求
2. 观察每次订购相同商品的请求是否存在不同的随机Token、可变参数等，若有则检查这些随机数的变化情况和失效情况，是否在当前订购流程中唯一有效。
3. 尝试重放之前已经完成流程的订购请求，观察服务器端是否做出正确响应，若订购再次生效，订单再次生成比则表明服务器存在脆弱性

修复建议

用户每次订单Token不应该能重复提交，避免产生重放订购请求的情况。在服务器订单生成关键环节，应该对订单Token对应的订购信息内容、用户身份、用户克用积分等进行强校验。

业务上限测试

原理

业务上限测试主要针对一些电商类应用程序在进行业务办理流程终，服务器没有对用户提交的查询范围、订单数量、金额等数据进行严格校验而引发的一些业务逻辑漏洞。通常情况下，在业务流程中通过向服务端提交高于或低于预期的数据以校验服务端是否对所提交的数据做预期强校验。存在此类脆弱性的应用程序，通常表现未查询到超出预期的信息、订购或兑换超出预期范围的商品等

测试过程

1. 在业务查询-手里记录查询中，应用程序只允许登录用户查询6个月以内的手里记录，但通过抓包查看到请求中存在明文字段month
2. 将month设置的查询范围调高到6个月以上，应用程序返回了6个月的手里记录，表明服务器端并没有限制用户的查询时间

修复建议

在服务器端应该对订单Token对应的订购信息内容、用户身份、用户克用积分等进行强校验。服务端应考虑交易风险控制，对产生异常情况的交易行为（如用户积分数额为负值、兑换库存数量为0的商品等）应当直接给予限制、阻断，而非继续完成整个交易流程。

业务流程乱序测试

业务流程绕过测试

原理

该项测试主要针对业务流程的处理流程是否正常，确保攻击者无法通过技术手段绕过某些重要流程步骤，检验办理业务过程中是否有控制机制来保证其遵循正常流程，如业务流程分三步走：第一步，注册并发送验证码；第二部，输入验证码；第三步注册成功。在第三步进行抓包分析，将邮箱或手机号替换为别人的，如果成功，就跳过了第一步和第二步，就绕过了正常的业务流程

测试过程

1. 新注册一个账号进行测试，此账号余额为0
2. 对账号重置并用bp工具进行数据报截取，金额可随意填写
3. 截获支付订单数据包，放弃支付，获取生成的订单号
4. 利用截获的订单号构造链接并访问

http://www.xxx.com/index.php?controllersite&actionpayok&out_trade_no=充值订单号

修复建议

针对此类漏洞，建议对敏感信息如身份ID、账号密码、订单号、金额等进行加密处理，并在服务端对其进行二次比对。

密码找回模块测试

验证码客户端回显测试

原理

找回密码测试中要注意验证码是否会回显在响应中，有些网站程序会选择将验证码回显在响应中，来判断你用户输入的验证码是否和响应中的验证码一致，如果一致就会通过校验

测试过程

1. 网站中一般第一步都会要求用户填写账号信息一遍发送验证码到用户的邮箱或者手机号中等大i用户查收检验。
2. 在找回密码测试中需要对发送验证码的请求抓包，观察它的响应结果。
3. 拦截到请求包后，通过观察可以发现object参数是验证码的发送邮箱，如果是这个账号的用户，就可以在自己的邮件中看大哦验证码，但如果不是自己的账号当验证码发生泄露后任意账号密码修改的漏洞就触发了。
4. 查看响应包中的内容
5. 当响应包中返回验证码后就泄露了找回密码的凭证，攻击者只需要利用这个盐泽和你干嘛就可以通过找回密码功能修改密码，这样就绕过了只有用户自己的手机或邮箱才能看到验证码的条件，从而达成修改的目的

修复建议

避免返回验证码到响应包中，验证码一定要放在服务器端校验

验证码暴力破解测试

原理

找回密码功能模块中通常会将用户凭证（一般是验证码）发送到用户自己才可以看到的手机号或者邮箱中，只要用户不泄露自己的验证码就不会被攻击者利用。但有些应用程序在验证码发送功能模块中验证码位数及复杂性较弱，也没有对验证码做次数限制而导致验证码可以被暴力枚举并修改任意用户密码

测试过程

1. 利用bp抓包
2. 通过intruder模块进行枚举测试，通过观察长度来确定验证码是否是真实验证码

修复建议

对用户输入的验证码进行错误次数的校验，以及提高验证码的复杂度

接口参数账号修改测试

原理

找回密码功能逻辑中常常会在用户修改密码接口提交参数中存在传递用户账号的参数，而用户账号参数作为一个可控的变量是可以被篡改的，从而导致修改账号密码的凭证或修改的目标账号出现偏差，最终造成任意密码修改的漏洞。

通常在找回密码逻辑中，服务端会要求用户提供要修改的账号，然后给这个账号发送只有账号主人才能看到的凭证。比如给这个账号注入绑定的邮箱或手机号发送验证码，或找回密码的链接，这样可以保证只有账号注入才可以看到这些凭证。但是如果服务端对账号的控制逻辑不当，就会导致原有账号被篡改为其他账号，服务端把凭证发送给篡改后的账号的邮箱或手机，最终造成可利用凭证重置任意账号密码的漏洞

测试过程

1. 在某网站的找回密码功能中，当输入用户账号后会出现发送重置密码邮件的按钮。在单击发送按钮时抓包，可以看大哦用户的邮箱已经出现在数据包中。尝试将email参数中的邮箱修改成自己的邮箱
2. 修改后网站提示邮件已经发送成功，此时可以打开自己的邮箱查看修改密码邮件是否收到
3. 如果收到则进行修改密码

修复建议

对找回密码的Token做一对一的校验，一个Token只能修改一个用户，同时要确保Token不会泄露。

Response状态值修改测试

原理

Response状态值修改测试，即修改请求的响应结果来达到密码重置的目的，存在这种漏洞的网站或者手机app往往因为校验不严格而导致了非常危险的重置密码操作。

这种漏洞的利用方式通常时在服务端发送某个密码重置的凭证请求后，出现特定的响应值，如true、1、ok、success等，网站看到回显内容为特定值后即修改密码，通常这种漏洞的回显值校验实在客户端进行的，所以只需要修改回显即可

测试过程

1. 某网站的找回密码功能需要发送验证码到用户手机，用户输入收到的验证码即可重置密码。于是我们输入一个要找回的目标手机号，短信认证码可以随便填写，然后单击找回吗按钮后抓包
2. 看到这个请求包包含了validateCode和phone两个参数，在bp中右键intercept选项，选择Do intercept→Response to this request，设置后就可以看到这个请求的回显Response包了。接着单击Forward转发这个请求。
3. 转发后可以看到Response的回显包已经成功接收到了，但是包返回的值是false，这时我们手动修改成true，然后关闭拦截让数据报正常发送
4. 结果页面直接跳转到重置密码页面

修复建议

不要再前端利用服务端返回的值判断是否可以修改密码，要把整个检验环节交给服务端验证

Session覆盖测试

原理

找回密码逻辑漏洞测试中也会遇到参数不可控的情况，比如要修改的用户名或绑定的手机号无法在提交参数时修改，服务端通过读取当前session会话来判断要修改密码的账号。

一般网站的业务逻辑是：用户使用手机进行注册→服务端向手机发送验证码短信→用户输入验证码→进入密码重置页面

网站对session覆盖的测试如下：

1. 需要准备自己的账号接收凭证（验证码）
2. 获得凭证校验成功后进入密码重置页面
3. 在浏览器信标签重新打开找回密码页面，输入目标手机号
4. 此时当前session账号已经被覆盖，重新回到第二步中打开的重置密码页面即可重置目标手机号

测试过程

1. 在找回密码界面输入A手机号，然后点击下一步
2. 正常操作进入到修改密码界面
3. 打开新的标签，输入B的手机号，抵达发送验证码处，发送点击获取验证码
4. 刷新A手机号的修改界面，如果存在漏洞则发现可以对B账号修改密码（因为session已经覆盖成B账号了）

修复建议

session覆盖类似于账号参数的修改，只是以控制当前session的方式篡改了要重置密码的账号，在重置密码请求中一定要对修改的账号和凭证是否一致做进一步的校验。

弱Token设计缺陷测试

原理

在找回密码功能中，很多网站会向用户邮箱发送找回密码页面链接。用户只需要进入邮箱，打开找回密码邮件中的链接，就可以进入密码重置页面了。找回密码的链接通常会加入校验参数来确认链接的有效性，通过校验参数的值与数据库生成的值是否一致来判断当前找回密码的链接是否有效

测试过程

1. 正常流程获得多个账号的密码找回凭证（如链接）
2. 观察是否有规律可循

www.xxx.com/index.php?m=CustomerService&a=resetPwdEml&token=dGVzdEAxMjYuY29tJjk5NTk=
www.xxx.com/index.php?m=CustomerService&a=resetPwdEml&token=dGVzdEAxMjYuY29tJjI2ODI=
www.xxx.com/index.php?m=CustomerService&a=resetPwdEml&token=dGVzdEAxMjYuY29tJjk4NzY=

可以发现Token参数在不断地变化，但也是有规律的，找到这个规律，利用枚举进行爆破，就成功可以修改密码了。

修复建议

密码找回的Token不能使用时间戳或用户邮箱和较短有规律可循的数字字符，应当使用复杂的Token生成机制让攻击者无法推测处具体的值

密码找回流程绕过测试

原理

很多网站的密码找回功能一般有以下几个步骤：

1. 用户输入找回密码的账号
2. 检验凭证：向用户发送短信验证码或者找回密码链接，用户回填验证码或单击链接进入密码重置页面，以此方式证明当前操作用户是账号主人
3. 校验成功进入重置密码页面

在找回密码逻辑中，第二步校验凭证最为重要，不是账号主人是无法收到校验凭证的。用户修改密码需要向服务器发送修改密码请求，服务器通过后在修改数据库中响应的密码，所以在测试中我们首先要收集三个步骤的请求接口，重点是收集到最后一步重置密码的接口，这样就可以直接跳过凭证校验的接口去尝试直接重置密码

测试过程

1. 注册一个账号，在找回密码页面获得url：GET /account/findPassword.html
2. 继续进行找回密码流程，获得第二步的url为 GET /forgetpwd/findPassNext.do
3. 通过验证，进入到重置密码页面，获得url为GET /forgetpwd/emailValidateNext.do
4. 使用自己的账号正常顺序流程找回自己的密码然后尝试在第一步的时候将url修改成第三步的url看看能不能直接进入密码重置页面。

修复建议

防止跳过验证步骤，一定要在后端逻辑校验中确认上一步流程是否完成

业务接口调用模块测试

接口调用重放测试

原理

在短信、邮件调用业务或生成业务数据环节中，如短信验证码、邮件验证码、订单生成、评论提交等，对业务环节进行调用（重放）测试。如果业务经过调用（重放）后多次生成有效的业务或数据结果，可判断为存在接口调用（重放）问题

测试过程

1. 在购买机票“提交订单”环节抓取数据包
2. 使用bp工具对生成订单的数据包进行重放测试
3. 查看返回结果，订单在1分钟内重放生成

修复建议

• 对生成订单环节采用验证码机制，防止生成数据业务被恶意调用
• 每一个订单使用唯一的Token，订单提交一次后，Token失效

接口调用遍历测试

原理

web接口一般将厂家你的一些功能需求进行封装，通过传入不同的参数来获取数据或执行响应的功能，其中一个最常见的场景就是通过接口传入id参数，返回对应id的一些信息。在安全测试中，我们可以使用bp作为http代理，记录所有请求核响应信息，通过bp以登录后的状态对整站进行爬取，再使用过滤功能找到传入id参数的http请求，然后通过intruder对id参数进行遍历，看是否返回不同的响应信息。如果不同的id值对应不同用户的信息，则说明存在漏洞

测试过程

1. 使用bp爬虫功能，从重点关注的目录开始爬取，在http history 选项卡中要开始爬取的项，单击鼠标右键，选择“spider from here”，爬取登录后的网站链接。
   爬取结果会在Target→site map中显示，在爬取完毕后，再使用bp的过滤功能筛选出带有uid参数的链接，没有包含uid字符串的http请求会被隐藏起来，不会再httphistory中显示。
2. 查看对应的http请求的响应包中是否带有想要的信息。由http请求的参数我们可以猜测到这个请求的功能，如method参数值为video.getUserVideoRecordList，作用是获取对应uid的视频播放的历史记录，由响应内容可以确定
   HTTP响应中包含一些敏感信息，如观看视频时的ip地址、视频id、视频的标题等。
3. 将http请求发送到intruder，设置后四位数字为变量，进行遍历测试。
4. 分析测试结果，如果存在播放记录的请求，则说明存在接口调用遍历测试漏洞。

修复建议

再session中存储当前用户的凭证或者id，只有传入凭证或者id参数值与session中一致才返回数据内容。

接口调用参数篡改测试

原理

在短信、邮件调用业务环节中，例如短信验证码、邮件验证码。修改对应请求中手机号或邮箱地址参数值提交后，如果修改后的手机号或邮箱收到系统发送的i西南西，则表示接口数据调用参数可以篡改。

测试过程

1. 在短信验证码页面点击重新发送，同时bp抓数据包
2. 截取数据将param.telno参数（指定发送手机号码）修改为其他手机号码
3. 修改后被指定的手机号收到响应验证码短信。

修复建议

• 会话session中存储重要的凭证，在忘记密码、重新发送验证码等业务中，从session获取用户凭证而不是从客户请求的参数中获取
• 从客户端处获取手机号、邮箱号等账号信息，要与session中的凭证进行对比，验证通过后才允许进行业务操作。

接口未授权访问/调用测试

原理

在正常的业务中，敏感功能的接口需要对访问者的身份进行验证，验证后才允许调用接口进行操作。如果敏感功能接口没有身份校验，那么攻击者无须登录或者验证即可调用接口进行操作。

在安全测试中我们使用bp作为http代理，在登录状态下记录所有请求核响应信息，筛选出敏感功能、返回敏感数据的请求。

在未登录的情况下，使用浏览器访问对应敏感功能的请求，如果返回的数据与登录状态后的一致，则存在漏洞或缺陷

测试过程

1. 登录后使用bp的爬虫功能，从重点关注的目录开始爬取，爬取后使用mime type过滤功能，筛选出接口相关的http请求，重点关注json、script、xml、text mime type等
2. 对接口相关的请求进行查看，查看响应中是否包含想要的敏感信息，如个人电话、ip地址、兴趣爱好、网站例是记录、身份证、手机号、住址等信息。
   通过查看响应包的具体i西南西，可以发现返回页面包含敏感信息，如ip地址、视频的例是播放等信息，通过这些信息可以了解其位置及关注点
3. 将完整的请求url复制到未登录的浏览器中，查看能否访问对应url的内容。如果能够返回敏感信息，则说明漏洞存在。如果需要登录验证才能访问，则不存在。

修复建议

1. 采用Token校验的方式，在url中添加一个Token参数，只有Token验证通过才返回接口数据且Token使用一次后失效
2. 在接口被调用时，后端对会话状态进行验证，如果已经登录，便返回接口数据；如果未登录，则返回自定义的错误信息。

Callback自定义测试

原理

在浏览器中存在着同源策略，所谓同源是指域名、协议、端口相同。当使用Ajax异步传输数据时，非同源域名之间会存在限制。其中一种解决办法时JSONP（JSON with padding），基本原理是利用HTML里的<script></script>元素标签，远程调用JSON文件来实现数据传递。

JSONP技术中一般使用Callback（回调函数）参数来声明回调时使用的函数名，这里往往存在安全问题，由于没有使用白名单的方法进行限制Callback的函数名，导致攻击者可以自定义Callback内容，从而触发Xss等漏洞。

测试过程

1. 使用bp爬虫功能，从重点关注的目录开始爬取（一般是网站的根目录），在http history选项卡中选中要开始爬取的项，右键选择spider from here
   爬取的结果会在Target→site map中显示。爬取完毕后，再使用bp的过滤功能找到带有Callback参数的链接。输入关键词后，开始让过滤生效
2. 找到url带有callback参数的链接
3. 查看url对应的httpresponse的content-type类型是否未text/hmtl，如果Content-Type未text/html，我们输入的HTML标签才会被浏览器解析。将对应的请求发送到repeater
4. 查看callback参数是否存在过滤及可控，这时我们需要再callback参数值前追加一些文本类的HTML标签，不直接使用script等标签是避免waf等防护设备的检测。（书中使用的是一级标题标签

   
   根据response的内容，我们可以了解到callback参数不存在过滤及可控，进一步测试发现info参数对response的输出内容没有影响，删除掉info参数，精简url

5. 将callback参数更换成带有恶意行为的html标签，进行利用

修复建议

1. 严格定义http响应中的Content-Type未json数据格式：Content-Type：application/json
2. 简历callbcak函数白名单，如果传入的callback参数值不再白名单内，跳转到统一的异常界面阻止其继续输出
3. 对callback参数进行html实体编码来过滤掉“<”、”>“等字符

WebService测试

原理

WebService是一种跨编程语言和跨操作系统平台的远程调用技术。XML+XSD、SOAP（simple Object Access Protocol）和WSDL（Web Services Description Language）就是构成WebService平台的三大技术，其中XML+XSD用来描述、表达要传输的数据；SOAP是用于交换XML编码信息的轻量级协议，一般以XML或者XSD作为载体，通过HTTP协议发送请求和接收结果，SOAP协议会在HTTP协议的基础上增加一些特定的HTTP消息投；WSDL是一个基于XML的用于描述WebService及其函数、参数和返回值的语言

所以WebService就是一个应用程序向外界暴露出一个能通过Web进行调用的API。这个API接收用户输入的参数，然后返回相关的数据内容。如果一个WebService完全信任用户的输入，不进行过滤，则有可能导致SQL注入漏洞的发生

测试过程

在攻击者测试前，通过爬虫或者目录扫描等方法找到服务器的WebService链接，接着使用WVS（Web Vulnerability Scanner）的Web Services Editor功能导入各个接口函数，通过关键字（如Get、Exec）定位到相关的接口函数，通过HTTP Editor对每一个接口函数的输入参数进行测试（如SQL注入、文件上传等），如果出现预期效果（如数据库报错、不同的延时等），则存在漏洞。

1. 找到服务器的WebService的链接，在WebService后面加上?wsdl，服务器边回返回WSDL描述函数信息。
2. 使用WVS（Web Vulnerability Scanner），单击左边栏的“Web Services Editor”
   在Operation选项列表中，可以看到WebService定义的多个函数，选择其中一个，WVS便会显示需要输入的参数值。在选择的时候，我们尽量选择一些可能会设计数据库操作的函数，比如函数名以GET开头的，一般是从数据库返回一些信息；比如Exec开头的，一般是直接执行SQL语句或者特定指令。
3. 带年纪“HTTP Editor”切换到HTTP请求界面，我们可以发送SOAP请求，以及接收请求后的响应。
4. 在了解数据库类型后，我们可以使用具体的非查询类的SQL语句去测试输入参数是否存在SQL注入漏洞。
   测试是否存在漏洞，一般应是由延时类的SQL语句，通过返回响应的时间间隔来确认是否可以直接执行SQL语句。
5. 剩下的利用步骤和常规的SQL注入测试一致，用Wireshark或者BP抓取请求，保存到本地文件，在需要测试的参数值处添加星号。然后通过sqlmap对参数进行检测即可
   对应的参数是-r

修复建议

1. 未WebService添加身份认证，认证成功后才允许访问和调用
2. WebService中接收输入参数的函数，在后端应该对输入参数进行过滤以及精华，在处理后踩入库查询
3. 在敏感功能的函数中，添加密码认证，认证后才允许调用敏感功能的函数