业务逻辑漏洞原理探索 ---- 最完整版本

逻辑漏洞形成原理

web应用程序中的逻辑漏洞各不相同，有的很明显，有的很微妙。与SQL注入和跨站不同，逻辑漏洞没有共有的“签名”，定义特性是指应用程序执行的逻辑存在某种缺陷。大部分逻辑缺陷表现为开发者在思考过程中做出的特殊假设存在明显或隐含的错误，通俗点来说，有的开发者会这样认为，如果发生A，就会出现B，因此我执行C。没有考虑如果发生X会怎么样，这种错误的假设会造成许多安全漏洞。逻辑漏洞是多样性的，挖掘它们需要从不同的角度思考问题，设法了解设计者和开发者做出的各种假设，然后考虑如何攻击

攻击者视角

1. 前台视角：业务使用者（信息系统受众）可见的业务及系统视图，如平台的用户注
   册、充值、购买、交易、查询等业务。
2. 后台视角：管理用户（信息系统管理、运营人员）可见的业务及系统视图，如平台
   的登录认证、结算、对账等业务。
3. 业务视角：业务使用者（信息系统受众）可见的表现层视图，如 Web 浏览器、手机
   浏览器展现的页面及其他业务系统用户的UI界面。
4. 系统视角：业务使用者（信息系统受众）不可见的系统逻辑层视图

登录认证模块

暴力破解

暴力破解测试是指针对应用系统用户登录账号与密码进行的穷举测试，针对账号或密
码进行逐一比较，直到找出正确的账号与密码

一般分为以下三种情况:

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

使用工具 :

• burpsuite
• hydra

修复建议

1. 增加验证码，登录失败一次，验证码变换一次
2. 配置登录失败次数限制策略，如在同一用户尝试登录的情况下，5 分钟内连续 登录失败超过5次，则禁止此用户在3小时内登录系统
3. 在条件允许的情况下，增加手机接收短信验证码或邮箱接收邮件验证码，实现 双因素认证的防暴力破解机制。

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

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

使用工具：wireshark，burpsuit
对流量进行截取后分析流量，使用可以进行信息查看

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

session固话测试

Session 是应用系统对浏览器客户端身份认证的属性标识，在用户退出应用系统时， 应将客户端Session认证属性标识清空。如果未能清空客户端Session标识，在下次登录系统时，系统会重复利用该Session标识进行认证会话。攻击者可利用该漏洞生成固定 Session会话，并诱骗用户利用攻击者生成的固定会话进行系统登录，从而导致用户会话 认证被窃取。

原理：在注销退出系统时，对当前浏览器授权SessionID值进行记录。再次登录系统，将本
次授权 SessionID 值与上次进行比对校验。判断服务器是否使用与上次相同的SessionID 值
进行授权认证，若使用相同 SessionID 值则存在固定会话风险。(可以冒用攻击内容)

第一次登录截取session，第二次登录截取session，比对相同则为相同session

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

Cookie仿冒

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

登录，bp拦截，进行重发，修改身份识别码，比如uid等。进行更改即存在

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

密文比对认证

在系统登录时密码加密流程一般是先将用户名和密码发送到服务器，服务器会把用户
提交的密码经过Hash算法加密后和数据库中存储的加密值比对，如果加密值相同，则判
定用户提交密码正确。
但有些网站系统的流程是在前台浏览器客户端对密码进行Hash加密后传输给服务器
并与数据库加密值进行对比，如果加密值相同，则判定用户提交密码正确。此流程会泄漏
密码加密方式，导致出现安全隐患。

原理

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

步骤一：通过Burp Suite工具抓包并根据页面代码分析后证实登录传输口令使用Hash MD5加密算法加密
步骤二：在利用Burp Suite工具进行暴力破解测试配置中添加配置项“Payload Processing”，将要破解的密码值进行数据处理转换
（登录获得加密内容，js加密分析加密方式，得出md5加密进行暴力破解登录）

修复建议

将密码加密过程及密文比对过程放置在服务器后台执行。发送用户名和密码到服务器后台，后台对用户提交的密码经过 MD5 算法加密后和数据库中存储的 MD5密码值进行比 对，如果加密值相同，则允许用户登录

登陆失败信息

在用户登录系统失败时，系统会在页面显示用户登录的失败信息，假如提交账号在系统中不存在，系统提示“用户名不存在”、“账号不存在”等明确信息；假如提交账号在系统 中存在，则系统提示“密码/口令错误”等间接提示信息。攻击者可根据此类登录失败提示信息来判断当前登录账号是否在系统中存在，从而进行有针对性的暴力破解口令测试

原理

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

步骤一：在系统登录页面中输入不存在的账号信息并提交，系统会返回明确语句“用
户名不存在”，如图所示。
步骤二：在系统登录页面中输入存在的账号信息及错误密码提交后，系统返回语句间
接地提示了该账号的“密码/口令错误“

修复建议

对系统登录失败提示语句表达内容进行统一的模糊描述，从而提高攻击者对登录系统用户名及密码的可猜测难度，如“登录账号或密码错误”、“系统登录失败”等

业务办理模块

订单篡改

原理
在有电子交易业务的网站中，用户登录后可以下订单购买相应产品，购买成功后，用户可以查看订单的详情。当开发人员没有考虑登录后用户间权限隔离的问题时，就会导致平行权限绕过漏洞。攻击者只需注册一
个普通账户，就可以通过篡改、遍历订单id，获得其他用户订单详情，其中多数会包括用户的姓名、身份证、地址、电话号码等敏感隐私信息。黑色产业链中的攻击者通常会利用此漏洞得到这些隐私信息。登录网站后，访问如下漏洞url，修改参数policyNo的值，可以遍历获得他人保单内容，其中包含很多敏感隐私信息。
http://xxxxx.com/SL_/policyDetailInfo.do?policyNo=P000000018446847

对其信息UID等参数值进行修改即可

修复建议

后台查看订单时要通过Session机制判断用户身份，做好平行权限控制，服务端需要校验相应订单是否和登录者的身份一致，如发现不一致则拒绝请求，防止平行权限绕过漏洞泄露用户敏感个人隐私信息。

手机号篡改

原理
手机号通常可以代表一个用户身份。当请求中发现有手机号参数时，我们可以试着修改它，测试是否存在越权漏洞。系统登录功能一般先判断用户名和密码是否正确，然后通过Session机制赋予用户令牌。但是在登
录后的某些功能点，开发者很容易忽略登录用户的权限问题。所以当我们用 A 的手机号登录后操作某些功能时，抓包或通过其他方式尝试篡改手机号，即可对这类问题进行测试。攻击者登录后，在操作某些功能时，抓包或通过其他方式尝试篡改手机号进行测试

修复建议

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

用户ID篡改

原理
从开发的角度，用户登录后查看个人信息时，需要通过sessionid判定用户身份，然后显示相应用户的个人信息。但有时我们发现在GET或POST请求中有userid这类参数传输，并且后台通过此参数显示对应用户隐私信
息，这导致了攻击者可以通过篡改用户ID越权访问其他用户隐私信息。黑色产业链中的攻击者也喜欢利用此类漏洞非法收集个人信息

修复建议
后台功能请求要通过 Session 机制判断用户身份，不要相信客户端传来的用户ID。如果确实需要客户端传输userid，则服务端需要校验userid是否和登录者的Session身份一致，如发现不一致则拒绝请求，防止被攻击者篡改，未授权访问他人账号内容

邮箱和用户篡改

原理

在发送邮件或站内消息时，篡改其中的发件人参数，导致攻击者可以伪造发信人进行钓鱼攻击等操作，这也是一种平行权限绕过漏洞。用户登录成功后拥有发信权限，开发者就信任了客户端传来的发件人参数，导致业务安全问题出现。

修复建议

用户登录后写信、发送消息时要通过Session机制判断用户身份。如果需要客户端传输邮箱、发件人，服务端需要校验邮箱、发件人是否和登录者的身份一致，如发现不一致则拒绝请求，防止被攻击者篡改用于钓鱼攻击。

商品编号篡改

原理

在交易支付类型的业务中，最常见的业务漏洞就是修改商品金额。例如在生成商品订单、跳转支付页面时，修改 HTTP 请求中的金额参数，可以实现 1 分买充值卡、1元买特斯拉等操作。此类攻击很难从流量中匹配
识别出来，通常只有在事后财务结算时发现大额账务问题，才会被发现。此时，攻击者可能已经通过该漏洞获得了大量利益。如果金额较小或财务审核不严，攻击者则可能细水长流，从中获得持续的利益。事后发现此类漏洞，就大大增加了追责的难度和成本。此类业务漏洞的利用方法，攻击者除了直接篡改商品金额，还可以篡改商品编号，同样会造成实际支付金额与商品不对应，但又交易成功的情况。攻击者可以利用此业务漏洞以低价购买高价的物品攻击者提交订单时，抓包篡改商品编号，导致商品与价格不对应但却交易成功，如图所示，攻击者从价格差中获利。

修复建议

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

竞争条件

原理

竞争条件通常是在操作系统编程时会遇到的安全问题：当两个或多个进程试图在同一时刻访问共享内存，或读写某些共享数据时，最后的竞争结果取决于线程执行的顺序（线程运行时序），称为竞争条件（Race
Conditions）。在Web安全中，我们可以沿用这个概念，在服务端逻辑与数据库读写存在时序问题时，就可能存在竞争条件漏洞，如图所示。攻击者通常利用多线程并发请求，在数据库中的余额字段更新之前，多次
兑换积分或购买商品，从中获得利益

攻击者在提交订单时抓包，然后设置很多个线程重放此包。如图所示，在众多请求中，个别请求就有可能争取绕过金额、次数的判断，交易成功，攻击者从中获利

修复建议

在处理订单、支付等关键业务时，使用悲观锁或乐观锁保证事务的
ACID特性（原则性、一致性、隔离性、持久性），并避免数据脏读（一个事务读取了另一个事务未提交的数据），解决竞争条件和并发操作可能带来的相关业务问题

回退模块

原理

很多Web业务在密码修改成功后或者订单付款成功后等业务模块，在返回上一步重新修改密码或者重新付款时存在重新设置密码或者付款的功能，这时如果能返回上一步重复操作，而且还能更改或者重置结果，则存在业务回退漏洞。攻击者按正常流程更改业务信息，更改完成后可回退到上一流程再次成功修改业务信息

修复建议

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

验证码机制

验证码暴力破解

原理
验证码机制主要被用于防止暴力破解、防止DDoS攻击、识别用户身份等，常见的验证码主要有图片验证码、邮件验证码、短信验证码、滑动验证码和语音验证码。以短信验证码为例。短信验证码大部分情况下是
由4～6位数字组成，如果没有对验证码的失效时间和尝试失败的次数做限制，攻击者就可以通过尝试这个区间内的所有数字来进行暴力破解攻击

测试过程

攻击者填写任意手机号码进行注册，服务器向攻击者填写的手机号码发送短信验证码，攻击者设置验证码范围 000000～999999、00000～99999、0000～9999，对验证码进行暴力破解，通过返回数据包判断是否破解成功，然后通过破解成功的验证码完成注册

修复建议

1. 设置验证码的失效时间，建议为180秒；
2. 限制单位时间内验证码的失败尝试次数，如5分钟内连续失败5次即锁定该账号 15分钟。

验证码重复使用

原理

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

测试过程

攻击者填写投诉建议，输入页面验证码，抓取提交的数据包，使用发包工具对数据包进行重复提交，然后查看投诉建议页面是否成功提交了多个投诉信息

修复建议

针对验证认证次数问题，建议验证码在一次认证成功后，服务端清空认证成功的session，这样就可以有效防止验证码一次认证反复使用的问题。

验证码客户端回显

原理

当验证码在客户端生成而非服务器端生成时，就会造成此类问题。当客户端需要和服务器进行交互发送验证码时，可借助浏览器的工具查看客户端与服务器进行交互的详细信息

测试过程

攻击者进入找回密码页面，输入手机号与证件号，获取验证码，服务器会向手机发送验证码，通过浏览器工具查看返回包信息，如果返回包中包含验证码，证明存在此类问题

修复建议

1. 禁止验证码在本地客户端生成，应采用服务器端验证码生成机制；
2. 设置验证码的时效性，如180秒过期
3. 验证码应随机生成，且使用一次即失效

验证码绕过

原理
在一些案例中，通过修改前端提交服务器返回的数据，可以实现绕过验证码，执行我们的请求

测试过程

攻击者进入注册账户页面，输入任意手机号码，获取验证码，在注册账户页面填写任意验证码，提交请求并抓包，使用抓包工具查看并修改返回包信息，转发返回数据包，查看是否注册成功

修复建议

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

验证码自动识别

原理
网站登录页面所使用的图形验证码是出现最早也是使用最为广泛的验证码，我们就以图形验证码为例来讲解如何对其进行自动识别。一般对于此类验证码的识别流程为：图像二值化处理→去干扰→字符分割→字符识别。图像二值化就是将图像上像素点的灰度值设置为0或255，也就是将整个图像呈现出明显的黑白效果

测试过程
攻击者访问网站登录页面，通过刷新验证码页面查看验证码组成规律，进行图像二值化、去干扰等处理，并进行人工比对，存储成功识别的验证码包，截入工具，利用工具对登录页面进行暴力破解，根据返回包的大小和关键字判断是否破解成功

业务流程乱序

业务流程绕过

原理

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

测试过程
攻击者访问注册页面，注册测试账户，充值提交并抓取数据包，填写任意充值金额并抓包，获取订单号，利用订单号构造充值链接并访问链接，查看是否充值成功，如果充值成功说明存在业务流程绕过问题，以某社交网站为例，经过测试发现订单生成后流程走至链接
http：//www.xxx.com/index.php？controller=site&action=payok&out_trade_no=，只要提供对应的充值订单号就可以绕过支付环节，未经支付直接充值成功。

修复建议

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

密码找回模块

验证码客户端回显

原理

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

测试过程

填入要找回的账号，通过Burp抓取返回包找到正确验证码，将正确验证码发送给服务端已达到密码重置的目的
步骤一：网站中一般第一步会要求用户填写账号信息以便发送验证码到用户的邮箱或者手机号中等待用户查收校验
步骤二：在找回密码测试中需要对发送验证码的请求抓包，观察它的响应结果。使用工具Burp Suite拦截请求
步骤三：拦截到请求包后，通过观察可以发现object参数是验证码的发送邮箱。 POST/member/same/password?type=email&object=xxxxxx@126.com
HTTP/1.1Host:www.xxxxx.com
如果是这个账号的用户，那么就可以在自己的邮件中看到验证码，但是如果不是自己的账号当验证码发生泄露后任意账号密码修改的漏洞就触发了。
步骤四：查看响应包中的内容
步骤五：当响应包中返回验证码后就泄露了找回密码的凭证，攻击者只需要利用响应中的验证码就可以通过找回密码功能修改密码，这样就绕过了只有用户自己邮箱或者手机才能看到验证码的条件而达到密码修改的目的

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

接口参数账号修改

原理

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

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

测试流程
接口参数账号修改测试流程为拦截前端请求，通过修改请求内邮箱或手机号等参数，将修改后数据发送给服务器进行欺骗达到密码重置的目的
步骤一：在某网站的找回密码功能中，当输入用户账号后会出现发送重置密码邮件的按钮。在单击发送按钮时抓包，可以看到用户的邮箱已经出现在了数据包的email参数值中，那么尝试将email参数修改为我们自己
的邮箱会出现什么情况？
步骤二：修改email参数的值后，网站提示邮件已经发送成功，此时可以打开我们自己的邮箱查看修改密码邮件是否收到，
步骤三：可以看到修改密码的链接已经发送到邮箱中，打开链接即可修改目标用户的密码，尽管目标用户绑定的并不是我们的邮箱，服务端仍将邮件发送到了我们篡改后的邮箱中
步骤四：通过上面的案例可以看到，服务端并没有校验这个邮箱是否是该账号绑定的邮箱，而是直接向请求中的email参数对应的邮箱发送邮件。类似这种直接修改请求参数的情况不仅在发送邮件时存在，如果修改密码请求中包含目标账号参数，也可以通过篡改账号参数重置目标账号密码

修复建议
对找回密码的 Token 做一对一的校验，一个 Token 只能修改一个用户，同时一定要保证Token不泄露

Response状态值修改

原理
Response状态值修改测试，即修改请求的响应结果来达到密码重置的目的，存在这种漏洞的网站或者手机App往往因为校验不严格而导致了非常危险的重置密码操作。这种漏洞的利用方式通常是在服务端发送某个密码重置的凭证请求后，出现特定的响应值，比如true、1、ok、success等，网站看到回显内容为特定值后即修改密码，通常这种漏洞的回显值校验是在客户端进行的，所以只需要修改回显即可。

测试流程
Response 状态值修改测试流程主要是分析服务端校验后的结果，正确和错误分别是什么样的返回结果，通过修改返回结果为正确来欺骗客户端，以达到密码重置的目的

步骤一：某网站的找回密码功能需要发送验证码到用户手机，用户输入收到的验证码即可重置密码。但是如果他的回显值被修改呢？我们来做个测试，输入要找回的目标手机号，短信认证码可以随便填写，然后单击“找回密码”按钮对该请求抓包
步骤二：看到这个请求包含了validateCode和phone两个参数，在Burp Suite中右击intercept选项，选择Do intercept→Response to this request，设置后就可以看到这个请求的回显Response包了
步骤三：转发后可以看到Response的回显包已经成功接收到了，但是包返回的值是false，通常false是失败的含义，也就是说服务端校验验证码的时候发现验证码不一致然后返回了false给客户端，这里我们可以尝试
修改false值为true，然后单击“Intercept is on”按钮关闭拦截让数据包正常发送
步骤四：接着可以看到页面直接跳转到了重置密码页面，于是轻松达到了任意密码修改的目的，在这个测试过程中只需要知道目标的账号而不需要知道任何绑定邮箱或者验证码就可以修改密码

密码找回流程绕过

原理
很多网站的密码找回功能一般有以下几个步骤。
（1）用户输入找回密码的账号；
（2）校验凭证：向用户发送短信验证码或者找回密码链接，用户回填验证码或单击 链接进入密码重置页面，以此方式证明当前操作用户是账号主人；
（3）校验成功进入重置密码页面。
在找回密码逻辑中，第二步校验凭证最为重要。不是账号主人是无法收到校验凭证的，试想有没有办法可以绕过第二步凭证校验，直接进入第三步重置密码呢？用户修改密码需要向服务器发送修改密码请求，服务器通过后再修改数据库中相应的密码，所以在测试中我们首先要收集三个步骤的请求接口，重点是收集到最后一步重置密码的接口，这样我们可以直接跳过凭证校验的接口去尝试直接重置密码。在下面的密码找回案例中，需要用户填写要找回的账号然后验证身份，之后才可以进入设置新密码的页面，我们需要对这个流程所有请求的接口做分析，找出最后一步重置密码的接口，接着使用URL测试是否可以跳过验证身份环节。

修复建议

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

业务接口调用模块

接口调用重放

原理

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

测试过程

在进行接口调用重放测试时，攻击者与普通用户的区别在于他会通过工具（如Burp Suite）抓取订单请求，然后在短时间内通过Burp Suite工具的Repeater对请求（如订单请求）进行多次重放，服务器则会根据请求
在短时间内执行多个有效操作（如生成订单）。

修复建议

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

接口调用遍历

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

测试过程

攻击者在测试前，使用Brup Suite的爬虫功能对网站进行爬取，然后筛选出包含用户标识参数的请求（如id、uid），对筛选后的每一个请求进行分析，判断其是否包含敏感信息。如果包含敏感信息，则通过Brup
Suite的Intruder设置用户标识参数为变量来进行遍历，如果返回他人信息，则漏洞存在。

使用Burp Suite的爬虫功能，从重点关注的目录（一般为网站根目录）开始爬取，在 HTTP history 选项卡中选中要开始爬取的项，单击鼠标右键，选择“Spider from here”，爬取登录后的网站链接。
爬取的结果会在Target→Site map中显示，在爬取完毕后，再使用BurpSuite的过滤功能筛选出带有uid参数的链接，没有包含uid字符串的HTTP请求会被隐藏起来，不会在HTTP history中显示。
查看对应的HTTP请求的响应包中是否带有想要的信息。由HTTP 请求的参数我们可以猜测到这个请求的功能，如 method 参数值为
video.getUserVideoRecordList，作用是获取对应 uid 的视频播放的历史记录，由响应内容可以确定对数值进行暴力破解即可

修复建议
在Session中存储当前用户的凭证或者id，只有传入凭证或者id参数值与Session中的一 致才返回数据内容

接口调用参数篡改

原理

在短信、邮件调用业务环节中，例如短信验证码、邮件验证码。修改对应请求中手机号或邮箱地址参数值提交后，如果修改后的手机号或邮箱收到系统发送的信息，则表示接口数据调用参数可篡改。
攻击者拥有账号B，用户拥有账号A。攻击者对账号A进行密码找回操作，服务器给账号 A 的邮箱或者手机发送密码重置信息，攻击者进入验证码验证环节，此时攻击者单击“重新发送验证码”并拦截重新发送这个请
求，将请求中的接收验证码用户的邮箱或者手机修改为自己的。如果接收到密码重置信息，则存在漏洞

步骤一：在短信验证码页面单击“重新发送”同时抓取数据包

步骤二：在截取数据中将param.telno参数（指定发送手机号码）修改为其他手机号码。
步骤三：修改后被指定的手机号收到相应验证码短信

修复建议

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

接口未授权访问/调用

原理

在正常的业务中，敏感功能的接口需要对访问者的身份进行验证，验证后才允许调用接口进行操作。如果敏感功能接口没有身份校验，那么攻击者无须登录或者验证即可调用接口进行操作。在安全测试中，我们可以使用Burp Suite作为HTTP代理，在登录状态下记录所有请求和响应信息，筛选出敏感功能、返回敏感数据的请求。在未登录的情况下，使用浏览器访问对应敏感功能的请求，如果返回的数据与登录状态后的一致，则存在漏洞或缺陷。
测试过程

攻击者在测试前，使用Brup Suite的爬虫功能对网站进行爬取，通过MIME Type筛选出与接口相关的请求对筛选后的每一个请求进行判断是否包含敏感信息。如果包含敏感信息，则复制请求URL到未进行登录的浏览器进行访问，如果访问后返回之前的敏感信息，则存在漏洞

步骤一：登录后使用Burp Suite的爬虫功能，从重点关注的目录（一般为网站根目录）开始爬取，在HTTP history选项卡中选中要开始爬取的项，右键选择“Spider fromhere”。爬取的结果会在Target→Site map中
显示，在爬取完毕后，使用Burp Suite的MIME type过滤功能，筛选出接口相关的HTTP请求，重点关注json、script、xml、text MIME type等。
步骤二：对接口相关的请求进行查看，查看响应中是否包含想要的敏感信息，如个人电话、IP地址、兴趣爱好、网站历史记录、身份证、手机号、住址等信息。通过查看响应包的具体信息，可以发现返回页面包含敏感信息，如ip地址、视频的历 史播放等信息，通过这些信息可以了解其位置及关注点
步骤三：将完整的请求URL复制到未登录的浏览器中，查看能否访问对应URL的内容。如果能够返回敏感信息，则说明漏洞存在；如果需要登录验证后才能访问，则不存在该漏洞。
在未进行登录的浏览器上，能够直接返回对应URL的页面内容而无须验证其身份，则该网站存在接口未授权访问的漏洞。

修复建议

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

账号安全

无限制登录任意账号

由于各类应用的安全防护手段参差不齐，导致攻击者可以利用漏洞绕过登录限制，或者利用已经认证的用户，通过修改身份ID登录任意账号。
步骤一：某学校网站后台为http：//www.xxx.edu.cn/login.asp
步骤二：因网站登录处过滤不严格导致存在SQL注入漏洞，利用万能密码，可以绕过登录的限制成功登录后台

电子邮件账号泄露事件

电子邮箱业务基于计算机和通信网的信息传递业务，利用电信号传递和存储信息，为用户传送电子信函、文件数字传真、图像和数字化语音等各类型的信息。电子邮件最大的特点是，人们可以在任何地方、任何时间收、发信件，解决了时空的限制，大大提高了工作效率，为办公自动化、商业活动提供了很大便利。但电子邮件账号泄露，也将引发大量的信息泄露通过搜索引擎查找某公司公开于互联网的文件，对信息下载分析，然后获取内容进行测试

中间人攻击

中间人攻击，即所谓的Main-in-the-middle（MITM）攻击，顾名思义，就是攻击者插入到原本直接通信的双方中间，让双方以为还在直接跟对方通信，但实际上双方的通信对象已变成了攻击者，同时信息已经被中间人获取或篡改。而中间人攻击不仅可以捕获HTTP未加密的传输数据，更可以捕获HTTPS协议加密的数据。HTTPS中间人攻击一般分为SSL连接建立前的攻击，以及HTTPS传输过程中的攻击。常见的HTTPS中间人攻击，会首先需结合ARP、DNS欺骗、伪造CA证书等技术，来对会话进行拦截。

SSL证书欺骗攻击

SSL证书欺骗攻击较为简单，首先通过DNS劫持和局域网ARP欺骗甚至网关劫持等技术，将用户的访问重定向到攻击者的设备上，让用户机器与攻击者机器建立HTTPS连接（使用伪造的CA证书），而攻击者机器再跟Web服务端连接。这样攻击者的机器分别与用户和真正的服务器建立 SSL 连接，通过这两个连接之间转发数据，就能得到被攻击者和服务器之间交互的数据内容。但用户的浏览器会提示证书不可信，只要用户不单击继续就能避免被劫持。所以这是最简单的攻击方式，也是最容易识别的攻击方式。为SSL证书欺骗攻击流程。

越权访问安全

平行越权

攻击者请求操作（增、删、查、改）某条数据时，Web 应用程序没有判断该数据的所属人，或者在判断数据所属人时直接从用户提交的表单参数中获取（如用户ID），导致攻击者可以自行修改参数（用户ID），操作不属于自己的数据

纵向越权

服务器为鉴别客户端浏览器会话及身份信息，会将用户身份信息存储在 Cookie中，并发送至客户端存储。
攻击者通过尝试修改Cookie中的身份标识为管理员，欺骗服务器分配管理员权限，达到垂直越权的目的

防范越权访问漏洞的相关手段

实现应用程序的完善的访问控制不是件容易的事，越权漏洞防不胜防，本文从越权漏洞相关案例给出以下几点建议：
（1）对于开发者而言，一定要有安全意识，时刻保持警惕。
（2）永远不要相信来自客户端（用户）的输入，对于可控参数进行严格的检查与过滤。
（3）执行关键操作前必须验证用户身份，多阶段功能的每一步都要验证用户身份。
（4）对于直接对象引用，加密资源ID，以防止攻击者对ID进行枚举。
（5）在前端实现的验证并不可靠，前端可以验证用户的输入是否合规，要在服务端对请求的数据和当前用户身份做校验。检查提交CRUD请求的操作者（Session）与目标对象的权限所有者（查数据库）是否一致，
如果不一致则阻断。
（6）在调用功能之前，验证当前用户身份是否有权限调用相关功能（推荐使用过滤器，进行统一权限验证）。
（7）把属主、权限、对象、操作的场景抽象成一个统一的框架，在框架内统一实现 权限的管理和检查。

在线支付安全

防范在线支付漏洞的相关手段

在线支付对广大消费者和商家来说日益重要，稍有不慎就会给商家带来经济损失，为了减少或者避免在线支付环节中的业务安全问题，希望商家采取以下措施进行预防。
（1）针对订单金额篡改的预防措施
将订单中的商品价格封装为码表形式，即每个商品拥有一个ID，每个ID对应一条相应的价格。用户访问前台选择商品并提交，服务器端验证商品 ID，然后计算商品总额并生成订单。
（2）针对订单数量篡改的预防措施
在服务器端判断提交商品ID中数量参数值不低于0，如果数量参数值低于0，则直接提示错误信息，让客户修正。通过数据类型判断正确后，同时判断商城库存对应商品的剩余量，如果剩余量低于商品的购买数量，则直接提示错误信息，让客户修正。
（3）针对订单请求重放测试的预防措施
无论支付成功还是失败时，使用的订单编号必须唯一，并且永久记录订单编号，不允许二次使用。
（4）针对其他参数（如运费）干扰测试的预防措施
在服务器端判断订单中运费参数值不低于0，如运费参数值低于0，则直接提示错误信息，让客户修正。