WEB业务逻辑漏洞分析

Web业务漏洞分析
1：登录认证模块
1.1 暴力破解测试
测试方法：
针对应用系统用户登录账号与密码进行的穷举测试，针对账号或密码进行逐一比较，直到找出正确的账号和密码。具体有两种情况，①已知账号，结合密码字典对密码进行穷举；②未知账号，加载账号字典，并结合密码字典进行穷举。
修复建议：
(1) 增加验证码，登录失败一次，验证码变换一次。
(2) 配置登录失败次数限制策略，如在同一用户尝试登录的情况下，5分钟内联系登录失败超过6次，则禁止此用户在3小时内登录系统。
(3) 在条件允许的情况下，增加手机接收短信验证码或邮箱接收邮件验证码，实现双因素认证的防暴力破解机制。
1.2 本地加密传输测试
测试方法：
针对客户端与服务器的数据传输，查看数据是否采用SSL加密方式加密。使用Wireshark进行网络流量流量抓包，查看登录请求数据包，对其内容进行分析，判断测试网站交互数据是否加密。
修复建议：
在架设Web应用的服务器上部署有效的SSL证书服务。
1.3 Session测试
1.3.1 会话固定
测试方法：
Session是应用系统对浏览器客户端身份认证的属性标识，在用户退出应用系统时，应将客户端Session认证属性标识清空。在注销退出系统时对SessionID值进行记录。再次登录系统，将本次授权的SessionID值与上次进行对比校验判断是否相同。
修复建议：
在客户端登录系统时，应首先判断客户端是否提交浏览器的留存Session认证会话属性标识，客户端提交此信息至服务器时，应及时销毁浏览器留存的Session认证会话，并要求客户端浏览器重新生成Session认证会话属性标识。
1.3.2 注销测试
测试方法：
对已登录授权的系统页面使用Burp Suite进行抓包，并对SessionID值进行记录。将请求数据发送到Repeater模块。在已授权的页面中退出登录。在Repeater模块对请求数据进行”Go”操作，查看返回页面登录时候失效，并和记录的SessionID进行对比验证。
修复建议：
在用户注销或退出应用系统时，服务器应该及时销毁Session认证会话消息并清空客户端的浏览器Session属性标识。
1.3.3 会话超时时间测试
测试方法：
Session认证会话应具有生命周期，对已登录授权的系统页面使用Burp Suite进行抓包，并对SessionID值和登录时间进行记录。将请求数据发送到Repeater模块。30分钟内对已经授权的页面不进行任何操作，30分钟后对请求数据进行“Go“操作，查看返回页面登录时候失效。
修复建议：
对每个生成的Session认证会话配置生命周期（常规30分钟），从而有效降低因用户会话认证时间过厂而导致的信息泄露风险。
1.4 Cookie防冒测试
测试方法：
服务器为鉴别客户端浏览器会话及身份信息，会将用户身份信息存储在Cookie中，并发送至客户端存储。对系统会话授权认证Cookie中会话身份认证标识进行篡改测试，通过篡改身份认证标识值来判断能否改变用户身份会话。
修复建议：
建议对客户端标识的用户敏感信息数据，使用Session会话认证方式，避免被他人仿冒身份。
1.5 密文对比认证测试
测试方法：
有些网站系统的流程是在前台浏览器客户端对密码进行Hash加密后传输给服务器并与数据库加密值进行对比，如果加密相同则判定用户提交密码正确。此流程会泄露密码加密方式，导致出现安全隐患。通过Burp Suite抓包查看Web系统登录提交密码为加密后的密文传输。通过对页面的分析得出Web系统登录口令加密处理过程是由本都JS脚本来完成的。
修复建议：
将密码加密过程及密文比对过程放置在服务器后台执行。发送用户名和密码到服务器后台，后台对用户提交的密码经过MD5算法加密后和数据库中存储的MD5密码值进行对比，如果加密值相同，则允许用户登录。
1.6 登录失败信息测试
测试方法：
在用户登录系统失败是，系统会在页面显示用户登录的失败状态，假如提交账号在系统中不存在，系统提示“用户名不存在”、“账号不存在”等明确信息；假如提交账号在系统中存在，则系统提示“密码/口令错误”等间接提示信息。攻击者可根据此类登录失败提示信息来判断当前登录账户是否在系统中存在，从而进行有针对性的暴力破解口令测试。
修复建议：
对系统登录失败提示语句表达内容进行统一的模糊描述，从而提高攻击者对登录系统用户名及密码的可猜测难度，如“登录账号或密码错误”、“系统登录失败”等。
2：业务办理模块
2.1 订单ID篡改测试
测试方法：
在某些具有工单，订单等业务的网站，当开发人员没有考虑登录后用户间权限的隔离的问题时，就会导致平行越权绕过漏洞。通过篡改，遍历工单，订单等模块id,获得其他用户的单目详情，其中多数会包括用户的姓名、身份证、地址、电话等敏感隐私信息。黑色产业链中的攻击者通常会利用此漏洞得到这些隐私信息。
修复建议：
后台查看订单时要通过Session机制判断用户身份，做好平行权限控制，服务端需要校验相应订单是否和登录者的身份一致，如发现不一致则拒绝请求，防止平行权限绕过漏洞泄露用户敏感个人隐私信息。
2.2 手机号码篡改测试
测试方法：
手机号通常可以代表一个用户身份。当请求中发现有手机号参数时，我们可以试着修改它，测试是否存在越权漏洞。当我们用A的手机号手机号恩登录后操作某些功能时，抓包或通过其他方式尝试篡改手机号。
修复建议：
后台请求要通过Session机制判断用户身份，如果需要客户端传输手机号，则服务端需要校验手机号是否和登陆者的身份一致。如发现不一致则拒绝请求，防止平行权限绕过。另外，对于手机App程序，不要过于相信从手机中直接读取的手机号码，还是要做常规的身份认证，规范登录流程，防止未授权登录。
2.3 用户ID篡改测试
测试方法：
从开发的角度，用户登录后查看个人信息时，需要通过身份sessionid判定用户身份，然后显示相应的用户个人信息。但有时我们发现在GET或POST请求中有userid这类参数传输，并且后台通过此参数显示对应用户隐私信息。通过使用抓包工具对userid此类参数进行修改，可以查看其它用户隐私信息。黑色产链中的攻击者也喜欢利用此类漏洞进行非法收集个人信息。
修复建议：
后台功能请求要通过Session机制判断用户身份，不要相信客户端传来的用户ID。如果确实需要客户端传输userid,则服务端需要校验userid是否和登录者的Session身份一致，如发现不一致则拒绝请求，防止被攻击者篡改，未授权访问他人账号内容。
2.4 邮箱和用户篡改测试
测试方法：
在发送邮件或站内消息时，篡改其中的发件人参数，导致攻击者可以伪造发信人进行钓鱼攻击等操作，这也是一种平行权限绕过漏洞。用户登录成功后拥有发信权限，开发者就信任了客户端传来的发件人参数，导致业务安全问题出现。
修复建议：
用户登录后写信、发送信息时要通过Sesssion机制判断用户身份。如果需要客户端传输邮箱、发件人，服务端需要校验邮箱、发件人是否和登陆者的身份一致，如发现不一致则拒绝请求，防止被攻击者篡改用于钓鱼攻击。
2.5 商品编号篡改测试
测试方法：
此类业务漏洞的利用方法，除了直接去篡改商品金额，还可以篡改商品编号，同样会造成实际支付金额与商品不对应，但又交易成功的情况。攻击者可以利用此业务漏洞以低价购买高价的物品。

修复建议：
建议商品金额不要在客户端传入，防止被篡改。如果确实需要在客户端传输金额，则服务端在收到请求后必须检查商品价格和交易金额是否一致，或对支付金额做签名校验，若不一致则组织该交易。
2.6 竞争条件测试
测试方法：
在提交订单时抓包，然后设置很多个线程重放此包。在众多的请求中，个别请求就有可能争取绕过金额、次数的判断，交易成功，从中获利。
修复建议：
在处理订单、支付等关键业务时，使用悲观锁或乐观锁保证失误的ACID特性（原子性、一致性、隔离性、持久性），并避免数据脏读（一个事务读取了令一个事务未提交的数据），解决竞争条件和并发操作可能带来的相关业务问题。
3：业务授权访问模块
3.1非授权访问测试
测试方法：
非授权访问是指用户在没有通过认证授权的情况下能够直接访问需要通过认证才能访问到的页面或文本信息。在登录某网站前台或后台之后，将相关的页面链接复制到其他浏览器或其他电脑上进行访问，观察是否能访问成功。
修复建议：
未授权访问可以理解为需要安全配置或权限认证的地址、授权页面存在缺陷，导致其他用户可以直接访问，从而引发重要权限可被操作、数据库、网站目录等敏感信息泄露，所以对未授权访问页面做Session认证，并对用户访问的每一个URL做身份鉴别，正确地校验用户ID及Token等。
3.2越权测试
测试方法：
越权一般分为水平越权和垂直越权。
水平越权测试方法主要是看能否通过A用户的操作影响B用户。
垂直越权测试方法的基本思路是低权限用户越权高权限用户的功能，比如普通用户可使用管理员功能。
修复建议：
服务端需要校验身份唯一性，自己的身份只能查看、修改、删除、添加自己的信息。
4：输入/输出模块
4.1 SQL注入测试（只提供修复建议）
修复建议：
每个提交信息的客户端页面、通过服务器端脚本（JSP、ASP、ASPX、PHP等）生成的客户端页面、提交的表单（FORM）或发出的链接请求中包含的所有变量，必须对变量的值进行检查，过滤其中包含的特殊字符，或对字符进行转义处理。特殊字符如下。
SQL语句关键词：如and、or、select、declare、update、xp_cmdshell;
SQL语句特殊符号：‘、’’；等。
此外，Web应用系统接入数据库服务器使用的是用户不应为系统管理员，用户角色应遵循最小权限原则。
4.2 XSS测试（只提供修复建议）
修复建议：
每个提交信息的客户端页面、通过服务器端脚本（JSP、ASP、ASPX、PHP等）生成的客户端页面、提交的表单（FORM）或发出的链接请求中包含的所有变量，必须对变量的值进行检查，过滤其中包含的特殊字符，或对字符进行转义处理。特殊字符如下。
（1）HTML标签的<、”、’、%等，以及这些符号的Unicode值；
（2）客户端脚本（JavaScript、 VBScript）关键字：JavaScript、script等。
对于信息搜索功能，不要在搜索结果页面中回显搜索内容。同时设置出错页面，防止Web服务器发生内部错误时，将错误信息返回给客户端。

4.3 命令执行测试（只提供修复建议）
尽量少用执行命令的函数或者直接禁用，参数值尽量使用引号包括在使用动态函数之前，确保使用的函数是指定的函数之一，在进入执行命令的函数/方法之前，对参数进行进行过滤，对敏感字符进行转义。
5：回退模块
测试方法：
Web业务在密码修改成功后或者订单付款成功后等业务模块，在返回上一步重新修改密码或者重新付款时存在重新设置密码或者付款功能，这时如果能返回上一步重复操作，而且还能更改或者重置结果，则存在业务回退漏洞。
修复建议：
对于业务流程有多步的情况，入修改棉麻或重置密码等业务，首先判断该步骤的请求是否是上一步骤的业务说发起的，如果不是则返回错误提示或页面失效。
6：验证码机制模块
6.1 验证码暴力破解测试
测试方法：
现在最常见的短信验证可以被暴力破解。短信验证码大部分情况下是由4~6位数字组成，如果没对验证码的失效时间和尝试失败的次数做限制，攻击者就可以通过尝试这个区间内的所有数字来进行暴力破解。
修复建议：
针对验证码的暴力测试，采取如下加固方案：
（1）设置验证码的失效时间，建议为60秒；
（2）限制单位时间内验证码的失败尝试次数。
6.2 验证码重复使用测试
测试方法：
在某些网站如果验证码认证成功后没有将session及时清空，将会导致验证码首次认证成功后可被重复使用。测试时可以出去出去携带验证码的数据包重复提交，查看是否提交成功。
修复建议：
针对验证认证次数问题，建议验证码在一次认证成功后，服务端清空认证成功的session，这样就可以有效防止验证码一次认证反复使用的问题。
6.3 验证码客户端回显测试
测试方法：
当验证码在客户端生成而非服务器端生成时，就会造成此类问题。当客户端需要和服务器进行交互发送验证码时，可借助浏览器的工具查看客户端与服务器进行交互的详细信息。
修复建议：
针对验证码在客户端回显的情况，建议采取如下措施来预防此类问题：
（1）禁止验证码在本地客户端生成，应采用服务器端验证码生成机制；
（2）设置验证码的时效性，如60秒过期；
（3）验证码应随机生成，且使用一次即失效。
6.4 验证码绕过测试
测试方法：
攻击者进入需要验证码的页面，输入任意手机号码，获取验证码，在页面填写任意验证码，提交请求并抓包，使用抓包工具查看并修改返回包信息，转发返回数据包，查看是否注册成功。
修复建议：
针对此漏洞，建议在服务端增加验证码的认证机制，对客户端提交的验证码进行二次校验。
6.5 验证码自动识别测试
测试方法：
攻击者访问网站登录页面，通过刷新验证码页面查看验证码组成规律，进行图像二值化、去干扰等处理，并进行人工比对，存储成功识别的验证码包，截入工具，利用工具对登录页面进行暴力破解，根据返回包的大小和关键字判断是否破解成功。
推荐工具
PKAV HTTP Fuzzer
修复建议：
针对验证码被自动识别的风险，建议通过以下几个方面来进行加固：
（1）增加背景元素的干扰，如背景色、背景字母等；
（2）字符的字体进行扭曲、粘连；
（3）使用公式、逻辑验证方法等作为验证码，如四则运算法、问答题等；
（4）图形验证码和使用者相关，比如选择联系人头像、选择购买过的物品等作为验证码
7：业务数据安全模块
7.1 商品支付金额票改测试
测试方法：
电商类同站在业务流程整个环节，需要对业务数据的完整性和一致性进行保护，特别是确保在用户客户端与服务、业务系统接口之间的数据传输的一致性，通常在订购类交易流程中，容易出现服务器端未对用户提交的业务数据进行强制校验，过度信赖客户端提交的业务数据而导致的商品金额篡改漏洞。商品金额篡改测试，通过抓包修改业务流程中的交易金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并提交，查看能否以修改后的金额数据完成业务流程。
该项测试主要针对订单生成的过程中存在商品支付金额校验不完整而产生业务安全风险点，通常导致攻击者用实际支付远低于订单支付的金额订购商品的业务逻辑漏洞。
修复建议：
商品信息，如金额、折扣等原始数据的校验应来自于服务起端。不应该接受客户端传递过来的值。
7.2商品订购数量篡改测试
测试方法：
商品数量篡改测试是通过在业务流程中抓包修改订购商品数量等字段，如将请求中的商品数量修改成任意非预期数额、负数等后进行提交，查看业务系统能否以修改后的数量完成业务流程。
修复建议：
服务端应当考虑交易风险控制，对产生异常情况的交易行为（如用户积分数额为负值、兑换库存数量为0的商品等）应当直接予以眼制、阻断，而非继续完成整个个交易流程。
7.3前端JS限制绕过测试
测试方法：
很多商品在限制用户购买数量时，服务器仅在页面通过JS脚本限制，未在服务端校验用户提交的数量，通过抓取客户端发送的请求包修改JS端生成处理的交易数据，如将请求中的商品数量改为大于最大数限制的值，查看能否以非正常业务交易数据完成业务流程。
修复建议：
商品信息，如金额、折扣、数量等原始数据的校验应来自于服务器端，不应该完全相信客户端传递过来的值。类似的跨平台支付业务，涉及平台之间接口调用。一定要做好对重要数据，如金额、商品数量等的完整性校验，确保业务重要数据在平台间传输的一致。
7.4 请求重放测试
测试方法：
请求重放漏洞是电商平台业务逻辑漏洞中一种常见的由设计缺陷所引发的漏洞，通常情况下所引发的安全问题表现在商品首次购买成功后，参照订购商品的正常流程请求，进行完全模拟正常订购业务流程的重放操作，可以实现“一次购买多次收货”等违背正常业务逻辑的结果。该项测试主要针对电商平台订购兑换业务流程中对每笔交易请求的唯一性判断缺乏有效机制的业务逻辑问题，通过该项测试可以验证交易流程中随机数、时间戳等生成机制是否正常。
修复建议：
用户每次订单Token不应该能重复提交，避免产生重放订购请求的情况。在服务器订单生成关键环节，应该对订单Token对应的订购信息内容、用户身份、用户可用积分等进行强校验。
7.5 业务上限测试
测试方法：
业务上限测试主要是针对一些电商类应用程序在进行业务办理流程中，服务端没有对用户提交的查询范围、订单数量、金额等数据进行严格校验而引发的一些业务逻辑漏洞。通常情况下，在业务流程中通过向服务端提交高于或低于预期的数据以校验服务端是否对所提交的数据做预期强校验。存在此类脆弱性的应用程序，通常表现为查询到超出预期的信息、订购或兑换超出预期范围的商品等。
该项测试主要判断应用程序是否对业务预期范围外的业务请求做出正确回应。
修复建议
在服务器端应该对订单Token对应的订购信息内容、用户身份、用户可用积分等进行强校验。服务端应考虑交易风险控制，对产生异常情况的交易行为（如用户积分数额为负值、兑换库存数量为0的商品等）应当直接予以限铺、阻断，而非继续完成整个交易流程。
8：业务流程乱序模块
测试方法：
该项测试主要针对业务流程的处理流程是否正常，确保政击者无法通过技术手段绕过某些重要流程步骤，检验办理业务过程中是否有控制机制来保证其遵循正常流程。例如业务流程分为三步：第一步，注册并发送验证码：第二步，输入验证码；第三步，注册成功。在第三步进行抓包分析，将邮箱或手机号替换为其他人的，如果成功注册，就跳过了第一步和第二步，绕过了正常的业务流程。
修复建议：
针对此类漏洞，建议对敏感信息如身份ID、账号密码、订单号、金额等进行加密处理，并在服务端对其进行二次比对。
9：密码找回模块
9.1 验证码客户端回显测试
测试方法：
找回密码测试中要注意验证码是否会回显在响应中，有些网站程序会选择将验证码回显在响应中，来判断用户输入的验证码是否和响应中的验证码一致，如果一致就会通过校验。
修复建议：
避免返回验证码到相应包中，验证码一定要放在服务器校验。
9.2 验证码暴露破解测试
测试方法：
找回密码功能模块中通常会将用户凭证（一般为验证码）发送到用户自己才可以看到的手机号或者邮箱中，只要用户不泄露自己的验证码就不会被攻击者利用，但是有些应用程序在验证码发送功能模块中验证码位数及复杂性较弱，也没有对验证码做次数限制而导致验证码可被暴力枚举并修改任意用户密码。
在测试验证码是否可以被暴力枚举时，可以先将验证码多次发送给自己的账号，观察验证码是否有规律，如每次接收到的验证码为纯数字并且是4位数。
修复建议：
为了避免出现验证码被暴力破解的情况，建议对用户输入的验证码校验采取错误次数限制并提高验证码的复杂度。
9.3 接口参数账号修改测试
测试方法：
找回密码功能逻辑中常常会在用户修改密码接口提交参数中存在传递用户账户的参数，而用户账号参数作为一个可控的变量是可以被篡改的，从而导致修改账号密码的凭证或修改的目标账号出现偏差，最终造成任意账号密码修改的漏洞。
接口参数账号修改测试流程为拦截前段请求，通过修改请求内邮箱或手机号等参数，将修改后数据发送给服务器进行欺骗达到密码重置的目的。
修复建议：
对找回密码的Token做一对一的校验，一个Token只能修改一个用户，同时一定要保证Token不泄露。
9.4 Response状态值修改测试
测试方法：
Response状态值修改测试，即修改请求的响应结果来达到密码重置的目的，存在这种漏洞的网站或者手机App往往因为校验不严格而导致了非常危险的重置密码操作。
这种漏洞的利用方式通常是在服务端发送某个密码重置的凭证请求后，出现特定的响应值，比如true、1、ok、success等，网站看到回显内容为特定值后即修改卷码，通常这种漏洞的回显值校验是在客户端进行的，所以只需要修改回显即可。
修复建议：
注意不要在前端利用服务端返回的值判断是否可以修改密码，要把整个校验环节交给服务端验证。
9.5 Session覆盖
测试方法：
找回密码逻辑漏润测试中也会遇到参数不可控的情况，比如要修改的用户名或者绑定的手机号无法在提交参数时修改，服务端通过读取当前scsion会话来判断要修改密码的账号，这种情况下能否对Session中的内容做修改以达到任意密码重置的目的呢？
在某网站中的找回密码功能中，业务逻辑是：由用户使用手机进行注册，然后服务端向手机发送验证码短信，用户输入验证码提交后，进入密码重置页面。
对网站中Session覆盖的测试如下：
（1）需要准备自己的账号接收凭证（短信验证码）；
（2）获得凭证校验成功后进入密码重置页面；
（3）在浏览器新标签重新打开找回密码页面，输入目标手机号；
（4）此时当前Session账户已经被覆盖，重新回到第二步中打开的重置密码页面即可重置目标手机号。
修复建议：
Session覆盖类似于账号参数的修改，只是以控制当前Session的方式篡改了要重置密码的账号，在重置密码请求中一定要对修改的账号和凭证是否一致做进一步的校验。
9.6 弱Token设计缺陷测试
测试方法：
在找回密码功能中，很多网站会向用户邮箱发送找回密码页面链接。用户只需要进入邮箱，打开找回密码邮件中的链接，就可以进入密码重置页面了。找回密码的链接通常会假如校验参数来确认链接的有效性，通过校验参数的值与数据库生成的值是否一致来判断当前找回密码的链接是否有效。
修复建议：
密码找回的Token不能使用时间戳或者用户邮箱和较短有规律可循的数字字符，应当使用复杂的Token生成机制让攻击者无法推测出具体的值。
9.7 密码找回流程绕过测试
测试方法：
很多网站的密码找回功能一般有以下步骤。
（1）用户输入找回密码的账号；
（2）校验凭证：向用户发送短信验证码或者找回密码链接，用户回填验证码或单击链接进入密码重置页面，以此方式证明当前操作用户是账号主人；
（3）校验成功进入重置密码页面。
在找回密码逻辑中，第二步校验凭证最为重要。不是账号主人是无法收到校验凭证的，试想有没有办法可以绕过第二步凭证校验，直接进入第三步重置密码。
用户修改密码需要向服务器发送修改密码请求，服务器通过后再修改数据库中相应的密码，所以在测试中我们首先要收集三个步骤的请求接口，重点是收集到最后一步重置密码的接口，这样我们可以直接跳过凭证校验的接口去尝试直接重置密码。
修复建议：
防止跳过验证步骤一定要在后端逻辑校验中确认上一步流程已经完成。
10：业务员接口调用模块
10.1 接口调用重放测试
测试方法：
在短信、邮件调用业务或生成业务数据环节中，如短信验证码、邮件验证码、订单生成、评论提交等，对业务环节进行调用（重放）测试。如果业务经过调用（重放）后多次生成有效的业务或数据结果，可判断为存在接口调用（重放）问题。
在进行接口调用重放测试时，攻击者与普通用户的区别在于他会通过工具（如Burp Suite）抓取订单请求，然后在短时间内通过Burp Suite工具的Repeater对请求（如订单请求）进行多次重放，服务器则会根据请求在短时间内执行多个有效操作（如生成订单）。
修复建议：
（1）对生成订单环节采用验证码机制，防止生成数据业务被恶意调用。
（2）每一个订单使用唯一的Tokcn，订单提交一次后，Token失效。
10.2 接口调用遍历测试
测试方法：
Web接口一般将常见的一些功能需求进行封装，通过传入不同的参数来获取数据或者执行相应的功能，其中一个最常见的场景就是通过接口传入id参数，返回对应id的一些信息。在安全测试中，我们可以使用Burp Suite作为HTTP代理，记录所有请求和响应信息，通过Burp Suite以登录后的状态对整站进行爬取，再使用过滤功能找到传入id参数的HTTP请求，然后通过Intruder对id参数进行遍历，看是否返回不同的响应信息。如果不同的id值对应不同用户的信息，则说明存在漏洞。
修复建议：
在Session中存储当前用户的凭证或者id，只有传入凭证或者id参数值与Session中的一致才返回数据内容。
10.3 接口调用参数篡改测试
测试方法：
在短信、邮件调用业务环节中，例如短信验证码、邮件验证码。修改对应请求中手机号或邮箱地址参数值提交后，如果修改后的手机号或邮箱收到系统发送的信息，则表示接口数据调用参数可篡改。
修复建议：
（1）会话Session中存储重要的凭证，在忘记密码、重新发送验证码等业务中，从Session获取用户凭证而不是从客户请求的参数中获取。
（2）从客户端处获取手机号、邮箱等账号信息，要与Session中的凭证进行对比，验证通过后才允许进行业务操作。
10.4 接口未授权访问/调用测试
测试方法：
在正常的业务中，敏感功能的接口需要对访问者的身份进行验证，验证后才允许调用接口进行操作。如果敏感功能接口没有身份校验，那么攻击者无须登录或者验证即可调用接口进行操作。在安全测试中，我们可以使用Burp Suite作为日HTTP代理，在登录状态下记录所有请求和响应信息，筛选出敏感功能、返回敏感数据的请求。在未登录的情况下，使用浏览器访问对应敏感功能的请求，如果返回的数据与登录状态后的一致，则存在漏洞或缺陷。
修复建议：
（1）采用Token校验的方式，在url中添加一个Token参数，只有Token验证通过才返回接口数据且Token使用一次失效。
（2）在接口被调用时，后端对会话状态进行验证，如果已经登录，便返回接口数据；如果未登录，则返回自定义的错误信息。
10.5 Callback自定义测试
测试方法：
在浏览器中存在着同源策略，所谓同源是指域名、协议、端口相同。当使用Ajax异步传输数据时，非同源域名之间会存在限制。其中有一种解决方法是JSONP（JSON with Paddomh）,基本原理是利用HTML里元素标签，远程调用JSON文件来实现数据传递。JSONP技术一般使用Callback（回调函数）参数来声明回调时所使用的函数名，这里往往存在安全问题，由于没有使用白名单的方法进行验资Callback的函数名，导致攻击者可以自定义Callback内容，从而触发XSS等漏洞。
修复建议：
（1）严格定义HTTP响应中的Content-Type为json数据格式：Content-Type:application/json。
（2）建立callback函数白名单，如果传入的cllback参数值不在白名单内，跳转到统一的异常界面阻止其继续输出。
（3）对callback参数进行HTML实体编码来过滤掉“<”、“>”等字符。
10.6 WebService测试
测试方法：
webService是一种跨编程语言和跨操作系统平合的远程调用技术。XML+XSD、SOPA和WSDL就是构成WebService平台的三大技术，其中XML+XSD用描述、表达要传输的数据； SOAP是用于交换XML编码信息的轻量级协议，一般以XML或者XSD作为载体，通过HTTP协议发送请求和接收结果，SOAP协议会在HTTP协议的基础上增加一些特定的HTTP消息头；WSDL是一个基于XML的用于描述Web Service及其函数、参数和返回值的语言。
通过上面的描述，我们可以知道WebService就是一个应用程序向外界暴露出一个能通过Web进行调用的APl。这个API接收用户输入的参数，然后返回相关的数据内容。如果一个WebService完全信任用户的输入，不进行过滤，则有可能导致SQL注入漏洞的发送。
修复建议：
（1）为WebService添加身份认证，认证成功后才允许访问和调用。
（2）WebService中接收输入参数的函数，在后端应该对输入参数进行过滤及净化，在处理后才入库查询。
（3）在敏感功能的函数中，添加密码认证，认证后才允许调用敏感功能的函数。

注：本文非原创，只是源头无法追溯，此处仅做为分享，若原作者看到，可随时联系。