提交,查看能否以修改后的金额数据完成业务流程。
10.1.2 测试过程
该项测试主要针对订单生成的过程中存在商品支付金额校验不完整而产生业务安全风
险点,通常导致攻击者用实际支付远低于订单支付的金额订购商品的业务逻辑漏洞,如图
10-1所示。
测试过程以登录http://www.xxx.cn/service/electronic/init.action网上营业厅购买充值卡
为例。
图10-1 测试流程图
步骤一:购卡选择卡面值后进入支付平台页面,如图10-2所示。
图10-2 实际支付金额
抓包并篡改支付请求中的明文金额字段 elecCardConfirm.money,如图 10-3 和图10-4
所示。
图10-3 抓取支付请求
图10-4 篡改支付请求中的支付金额字段
步骤二:跳转支付平台,完成篡改后订单金额支付流程,如图10-5和图10-6所示。
图10-5 在支付平台支付篡改后的金额
图10-6 支付平台回调电商平台提示支付完成
步骤三:支付平台支付完成后自动回调商城,显示订单成功生成并完成支付流程,表
明本次测试实现了用篡改后的金额0.01元在电商平台订购到100元的商品的操作,如图10-7所示。
图10-7 电商平台提示订单已经完成支付
10.1.3 修复建议
商品信息,如金额、折扣等原始数据的校验应来自于服务器端,不应接受客户端传递
过来的值。
10.2 商品订购数量篡改测试
10.2.1 测试原理和方法
商品数量篡改测试是通过在业务流程中抓包修改订购商品数量等字段,如将请求中的
商品数量修改成任意非预期数额、负数等后进行提交,查看业务系统能否以修改后的数量
完成业务流程。
10.2.2 测试过程
该项测试主要针对商品订购的过程中对异常交易数据处理缺乏风控机制而导致的相关
业务逻辑漏洞,例如针对订购中的数量、价格等缺乏判断而产生意外的结果,往往被攻击
者所利用,如图10-8所示。
测试过程以某网上营业厅积分商城为例。
图10-8 测试流程图
步骤一:将商品放入购物车,对于实物礼品需要放在购物车中进行订购。放入购物车
后,单击进入购物车,如图10-9所示。
图10-9 将要购买的商品添加进购物车
步骤二:在购物车中进行礼品兑换,确认商品订单准备进行数据包信息篡改,如图
10-10所示。
图10-10 确认商品订单
抓包将商品的数量参数修改成负数并保存,如图10-11和图10-12所示。
图10-11 篡改该订购请求中的商品数量
可以看到购物车中实际支付积分已经变为负积分,如图10-13所示。
步骤三:添加兑换人的配送信息,确认订单信息,完成积分兑换业务流程,如图10-
14所示。
图10-12 保存篡改后的订购信息
图10-13 实际篡改后的订购信息
获取验证码并且验证通过后,单击“下一步”按钮,进入订单确认页面,如图10-15所
示。
图10-14 确认订单信息
图10-15 支付订单
步骤四:提交订单订购请求,此页面列出订单的清单,包括收货人信息、兑换礼品列
表和消费积分。单击“提交订单”按钮,完成礼品兑换,显示兑换结果,如图10-16所示。
图10-16 实际生成的订单详情
步骤五:兑换结果查看,由于积分为负值提交给后台,视为无效订单,所以未能成功
利用。服务端对这些异常订单数据进行比对,未能支付成功,如图10-17所示。
图10-17 服务器对异常订单的响应
10.2.3 修复建议
服务端应当考虑交易风险控制,对产生异常情况的交易行为(如用户积分数额为负
值、兑换库存数量为 0 的商品等)应当直接予以限制、阻断,而非继续完成整个交易流
程。
10.3 前端JS限制绕过测试
10.3.1 测试原理和方法
很多商品在限制用户购买数量时,服务器仅在页面通过JS脚本限制,未在服务器端校
验用户提交的数量,通过抓取客户端发送的请求包修改JS端生成处理的交易数据,如将请
求中的商品数量改为大于最大数限制的值,查看能否以非正常业务交易数据完成业务流
程。
10.3.2 测试过程
该项测试主要针对电商平台由于交易限制机制不严谨、不完善而导致的一些业务逻辑
问题。例如,在促销活动中限制商品购买数量,却未对数量进行前、后端严格校验,往往
被攻击者所利用,如图10-18所示。
图10-18 测试流程图
测试过程以 http://www.xxx.com/xxx-100-2856.html 网上商城绕过团购购买数量限制
购买团购价商品为例。
步骤一:购买限购的商品,商品限制购买数量为 2 份,将其加入购物车,如图10-19
和图10-20所示。
图10-19 商品订购页面
图10-20 商品订购数量限制
步骤二:通过观察发现客户端在前端浏览器使用JavaScript做了购买限制,尝试绕过
限制提交购买请求,可以通过抓包修改数量字段,改为 100 个后成功提交,如图10-21所
示。
图10-21 直接绕过JS限制完成订购
10.3.3 修复建议
商品信息,如金额、折扣、数量等原始数据的校验应来自于服务器端,不应该完全相
信客户端传递过来的值。类似的跨平台支付业务,涉及平台之间接口调用,一定要做好对
重要数据,如金额、商品数量等的完整性校验,确保业务重要数据在平台间传输的一致。
10.4 请求重放测试
10.4.1 测试原理和方法
请求重放漏洞是电商平台业务逻辑漏洞中一种常见的由设计缺陷所引发的漏洞,通常
情况下所引发的安全问题表现在商品首次购买成功后,参照订购商品的正常流程请求,进
行完全模拟正常订购业务流程的重放操作,可以实现“一次购买多次收货”等违背正常业务
逻辑的结果。
10.4.2 测试过程
该项测试主要针对电商平台订购兑换业务流程中对每笔交易请求的唯一性判断缺乏有
效机制的业务逻辑问题,通过该项测试可以验证交易流程中随机数、时间戳等生成机制是
否正常,如图10-22所示。
图10-22 测试流程图
步骤一:在生成订单流程时抓取订购请求,如图10-23所示。
图10-23 生成订购请求页面
步骤二:观察每次订购相同商品的请求是否存在不同的随机Token、可变参数等,若
有则检查这些随机数的变化情况和失效情况,是否在当前订购流程中唯一有效,如图10-
24所示。
图10-24 留存订购HTTP请求
步骤三:尝试重放之前已经完成流程的订购请求,观察服务器端是否做出正确响应,
若订购再次生效,订单再次生成则表明服务器存在脆弱性,如图10-25所示。
图10-25 将订购HTTP请求进行重放发送
10.4.3 修复建议
用户每次订单 Token 不应该能重复提交,避免产生重放订购请求的情况。在服务器
订单生成关键环节,应该对订单 Token 对应的订购信息内容、用户身份、用户可用积分
等进行强校验。
10.5 业务上限测试
10.5.1 测试原理和方法
业务上限测试主要是针对一些电商类应用程序在进行业务办理流程中,服务端没有对
用户提交的查询范围、订单数量、金额等数据进行严格校验而引发的一些业务逻辑漏洞。
通常情况下,在业务流程中通过向服务端提交高于或低于预期的数据以校验服务端是否对
所提交的数据做预期强校验。存在此类脆弱性的应用程序,通常表现为查询到超出预期的
信息、订购或兑换超出预期范围的商品等。
10.5.2 测试过程
该项测试主要判断应用程序是否对业务预期范围外的业务请求做出正确回应,如图
10-26所示。
图10-26 测试流程图
步骤一:在业务查询-受理记录查询中,应用程序只允许登录用户查询6个月内的受理
记录,但是通过抓包分析出查询请求中存在明文字段month,如图10-27所示。
图10-27 实际业务查询范围
步骤二:将month 设置的查询范围调高到6 个月以上并提交,应用程序返回了超过6
个月的受理记录,表明服务器端并没有限制用户的查询时间,如图10-28所示。
图10-28 修改查询范围
步骤三:成功查询到大于 6 个月的办理记录,表明该功能不符合业务要求,如图10-29所示。
图10-29 超出限制范围的查询结果
10.5.3 修复建议
在服务器端应该对订单 Token 对应的订购信息内容、用户身份、用户可用积分等进
行强校验。服务端应考虑交易风险控制,对产生异常情况的交易行为(如用户积分数额为
负值、兑换库存数量为 0 的商品等)应当直接予以限制、阻断,而非继续完成整个交易流
程。
11.1 业务流程绕过测试
11.1.1 测试原理和方法
该项测试主要针对业务流程的处理流程是否正常,确保攻击者无法通过技术手段绕过
某些重要流程步骤,检验办理业务过程中是否有控制机制来保证其遵循正常流程。例如业
务流程分为三步:第一步,注册并发送验证码;第二步,输入验证码;第三步,注册成
功。在第三步进行抓包分析,将邮箱或手机号替换为其他人的,如果成功注册,就跳过了
第一步和第二步,绕过了正常的业务流程。
11.1.2 测试过程
攻击者访问注册页面,注册测试账户,充值提交并抓取数据包,填写任意充值金额并
抓包,获取订单号,利用订单号构造充值链接并访问链接,查看是否充值成功,如果充值
成功说明存在业务流程绕过问题,如图11-1所示。
以某社交网站为例,经过测试发现订单生成后流程走至链接
http://www.xxx.com/index.php?controller=site&action=payok&out_trade_no=,只要提供对
应的充值订单号就可以绕过支付环节,未经支付直接充值成功。
图11-1 业务流程绕过测试流程
步骤一:新注册一个账号进行测试,如图11-2所示。
图11-2 注册账号
账号余额为0,如图11-3所示。
图11-3 账户余额
步骤二:对账号充值并用Burp Suite工具进行数据包截取,金额可随意填写,如图11-4所示。
图11-4 充值并抓包
步骤三:截获支付订单数据包,放弃支付,获取生成的订单号,如图11-5所示。
图11-5 获取支付订单号
步骤四:利用获取的订单号构造链接
http://www.xxx.com/index.php?
controller=site&action=payok&out_trade_no=充值订单号,直接访问这个链接即可成功充
值,如图11-6所示。
图11-6 支付成功
充值后的余额如图11-7所示。
图11-7 充值后的余额
11.1.3 修复建议
针对此类漏洞,建议对敏感信息如身份 ID、账号密码、订单号、金额等进行加密处
理,并在服务端对其进行二次比对。
第12章 密码找回模块测试
12.1 验证码客户端回显测试
12.1.1 测试原理和方法
找回密码测试中要注意验证码是否会回显在响应中,有些网站程序会选择将验证码回
显在响应中,来判断用户输入的验证码是否和响应中的验证码一致,如果一致就会通过校
验。
12.1.2 测试流程
填入要找回的账号,通过Burp抓取返回包找到正确验证码,将正确验证码发送给服务
端已达到密码重置的目的,如图12-1所示。
图12-1 验证码发送流
步骤一:网站中一般第一步会要求用户填写账号信息以便发送验证码到用户的邮箱或
者手机号中等待用户查收校验,如图12-2所示。
图12-2 找回密码界面
步骤二:在找回密码测试中需要对发送验证码的请求抓包,观察它的响应结果。本书
中使用工具Burp Suite拦截请求,如图12-3所示。
图12-3 发送验证码请求包
步骤三:拦截到请求包后,通过观察可以发现object参数是验证码的发送邮箱。
POST/member/same/password?type=email&object=xxxxxx@126.com HTTP/1.1Host:www.xxxxx.com
如果是这个账号的用户,那么就可以在自己的邮件中看到验证码,但是如果不是自己
的账号当验证码发生泄露后任意账号密码修改的漏洞就触发了。
步骤四:查看响应包中的内容,如图12-4示。
图12-4 查看验证码响应包
步骤五:当响应包中返回验证码后就泄露了找回密码的凭证,攻击者只需要利用响应
中的验证码就可以通过找回密码功能修改密码,这样就绕过了只有用户自己邮箱或者手机
才能看到验证码的条件而达到密码修改的目的,如图12-5所示。
图12-5 验证码校验成功进入密码修改界面
12.1.3 修复建议
避免返回验证码到响应包中,验证码一定要放在服务端校验。
12.2 验证码暴力破解测试
12.2.1 测试原理和方法
找回密码功能模块中通常会将用户凭证(一般为验证码)发送到用户自己才可以看到
的手机号或者邮箱中,只要用户不泄露自己的验证码就不会被攻击者利用,但是有些应用
程序在验证码发送功能模块中验证码位数及复杂性较弱,也没有对验证码做次数限制而导
致验证码可被暴力枚举并修改任意用户密码。
在测试验证码是否可以被暴力枚举时,可以先将验证码多次发送给自己的账号,观察
验证码是否有规律,如每次接收到的验证码为纯数字并且是4位数。
12.2.2 测试流程
验证码暴力破解是指在密码重置的过程中使用 Burp Suite 不断地尝试对验证码进行猜
解的测试。一旦验证码猜解成功即可对被攻击账号进行密码重置,如图 12-6所示。
图12-6 验证码发送流程
步骤一:在某 App 的找回密码功能模块中要求用户输入手机号并发送验证码,可以
先将验证码发送到自己手机号来查看验证码是否有规律,可以被暴力枚举。案例中验证码
为4位数,如图12-7所示。
图12-7 验证码是4位数字
步骤二:当确定用户验证码可以暴力枚举后,可以抓取验证码校验请求,对验证码进
行暴力破解。在验证码未知的情况下,可以先填写任意4位数字,如图12-8所示。
图12-8 抓取验证请求包
步骤三:当请求包被拦截后可以观察参数名为mm的请求值是用户的手机号码,参数
名为pno的请求值是验证码(在还不知道验证码的情况下随意填写的),参数名为pas的参
数值是验证码校验成功后要修改的密码,如图12-9所示。
图12-9 验证码校验请求包
请求包如下:
步骤四:这里可以将请求包发送到Burp Suite工具中的Intruder模块中,并把pno验证
码参数设置为变量载入 4 位数字的密码字典进行枚举测试,可以通过 length 响应长度来观
察payload请求的验证码是否和其他请求不一样,如果发生不一样的情况可能就是真实的
验证码。如图12-10所示,从响应包内容可以观察出验证码枚举猜解正确并修改密码成
功。
图12-10 验证码暴力枚举
12.2.3 修复建议
为了避免出现验证码被暴力破解的情况,建议对用户输入的验证码校验采取错误次数
限制并提高验证码的复杂度。
12.3 接口参数账号修改测试
12.3.1 测试原理和方法
找回密码功能逻辑中常常会在用户修改密码接口提交参数中存在传递用户账号的参
数,而用户账号参数作为一个可控的变量是可以被篡改的,从而导致修改账号密码的凭证
或修改的目标账号出现偏差,最终造成任意账号密码修改的漏洞,如图12-11所示。
图12-11 修改密码接口存在email参数
通常在找回密码逻辑中,服务端会要求用户提供要修改的账号,然后给这个账号发送
只有账号主人才能看到的凭证。比如给这个账号主人绑定的邮箱或手机号发送验证码,或
者找回密码的链接,这样可以保证只有账号主人才可以看到这些凭证。但是如果服务端对
账号的控制逻辑不当,就会导致原有账号被篡改为其他账号,服务端把凭证发送给篡改后
的账号的邮箱或手机,最终造成可利用凭证重置任意账号密码的漏洞。
12.3.2 测试流程
接口参数账号修改测试流程为拦截前端请求,通过修改请求内邮箱或手机号等参数,
将修改后数据发送给服务器进行欺骗达到密码重置的目的,如图12-12所示。
步骤一:在某网站的找回密码功能中,当输入用户账号后会出现发送重置密码邮件的
按钮。在单击发送按钮时抓包,可以看到用户的邮箱已经出现在了数据包的email参数值
中,那么尝试将email参数修改为我们自己的邮箱会出现什么情况?如图12-13所示。
步骤二:修改email参数的值后,网站提示邮件已经发送成功,此时可以打开我们自
己的邮箱查看修改密码邮件是否收到,如图12-14所示。
图12-12 接口参数修改流程
图12-13 修改密码绑定邮箱可修改
图12-14 发送邮件成功
步骤三:可以看到修改密码的链接已经发送到邮箱中,打开链接即可修改目标用户的
密码,尽管目标用户绑定的并不是我们的邮箱,服务端仍将邮件发送到了我们篡改后的邮
箱中,如图12-15所示。
图12-15 接收到修改密码邮件
步骤四:通过上面的案例可以看到,服务端并没有校验这个邮箱是否是该账号绑定的
邮箱,而是直接向请求中的email参数对应的邮箱发送邮件。类似这种直接修改请求参数
的情况不仅在发送邮件时存在,如果修改密码请求中包含目标账号参数,也可以通过篡改
账号参数重置目标账号密码,如图12-16所示。
图12-16 重置密码页面
例如,某个找回密码发送给用户邮件中的接口URL如下:
http://www.xxx.com/repwd?account=abcabc@126.com&token=1239392342234
那么只需要将account参数修改为我们需要的账号,如foo@163.com,修改后如下:
http://www.xxx.com/repwd?account=foo@163&token=1239392342234
因为这里的Token可重复使用,这样就可以直接修改掉foo@163.com账号的密码了,
在测试找回密码功能模块时要留意数据包参数中的账号是否可修改。
12.3.3 修复建议
对找回密码的 Token 做一对一的校验,一个 Token 只能修改一个用户,同时一定要
保证Token不泄露。
12.4 Response状态值修改测试
12.4.1 测试原理和方法
Response状态值修改测试,即修改请求的响应结果来达到密码重置的目的,存在这种
漏洞的网站或者手机App往往因为校验不严格而导致了非常危险的重置密码操作。
这种漏洞的利用方式通常是在服务端发送某个密码重置的凭证请求后,出现特定的响
应值,比如true、1、ok、success等,网站看到回显内容为特定值后即修改密码,通常这
种漏洞的回显值校验是在客户端进行的,所以只需要修改回显即可。
12.4.2 测试流程
Response 状态值修改测试流程主要是分析服务端校验后的结果,正确和错误分别是
什么样的返回结果,通过修改返回结果为正确来欺骗客户端,以达到密码重置的目的,如
图12-17所示。
图12-17 Response状态值修改测试流程
步骤一:某网站的找回密码功能需要发送验证码到用户手机,用户输入收到的验证码
即可重置密码。但是如果他的回显值被修改呢?我们来做个测试,输入要找回的目标手机
号,短信认证码可以随便填写,然后单击“找回密码”按钮对该请求抓包,如图12-18所
示。
图12-18 找回密码页面
步骤二:可以看到这个请求包含了validateCode和phone两个参数,在Burp Suite中右
击intercept选项,选择Do intercept→Response to this request,设置后就可以看到这个请求
的回显Response包了,如图12-19所示,接着单击“Forward”转发这个请求。
图12-19 设置请求响应拦截
步骤三:转发后可以看到Response的回显包已经成功接收到了,但是包返回的值是
false,通常false是失败的含义,也就是说服务端校验验证码的时候发现验证码不一致然后
返回了false给客户端,这里我们可以尝试修改false值为true,然后单击“Intercept is on”按钮
关闭拦截让数据包正常发送,如图12-20、图12-21所示。
图12-20 服务端返回false
步骤四:接着可以看到页面直接跳转到了重置密码页面,如图12-22所示,于是轻松
达到了任意密码修改的目的,在这个测试过程中只需要知道目标的账号而不需要知道任何
绑定邮箱或者验证码就可以修改密码。
图12-21 修改false为true
图12-22 进入重置密码页面
12.4.3 修复建议
注意不要在前端利用服务端返回的值判断是否可以修改密码,要把整个校验环节交给
服务端验证。
12.5 Session覆盖测试
12.5.1 测试原理和方法
找回密码逻辑漏洞测试中也会遇到参数不可控的情况,比如要修改的用户名或者绑定
的手机号无法在提交参数时修改,服务端通过读取当前session会话来判断要修改密码的账
号,这种情况下能否对Session中的内容做修改以达到任意密码重置的目的呢?
在某网站中的找回密码功能中,业务逻辑是:由用户使用手机进行注册,然后服务端
向手机发送验证码短信,用户输入验证码提交后,进入密码重置页面。
对网站中Session覆盖的测试如下:
(1)需要准备自己的账号接收凭证(短信验证码);
(2)获得凭证校验成功后进入密码重置页面;
(3)在浏览器新标签重新打开找回密码页面,输入目标手机号;
(4)此时当前 Session 账户已经被覆盖,重新回到第二步中打开的重置密码页面即
可重置目标手机号。
12.5.2 测试流程
步骤一:在找回密码页面中输入 A 手机号(尾号 3274),然后单击“下一步”按钮,
如图12-23所示。
图12-23 找回密码第一步
步骤二:单击“立即验证”按钮,接收短信验证码。输入验证码通过验证后,就可以进
入密码重置页面了,如图12-24、图12-25所示。
图12-24 找回密码第二步验证手机号
图12-25 进入重置密码页面
步骤三:这里我们密码重置的目标账号是B手机号(尾号为5743),接下来打开一个
新的标签并进入找回密码第一步的页面,输入B手机号后单击“下一步”按钮,如图12-26所
示。
图12-26 新标签重新进入找回密码覆盖session
步骤四:此时成功进入第二步,向B手机号(尾号为5743)发送验证码。B手机收到
的短信验证码我们无法得知,但是不要担心,在这一步服务端已经将当前Session会话设
置为B手机号(尾号为5743)的用户,这个时候再刷新A手机号(尾号3274)密码重置页
面。
步骤五:通过观察页面上显示的手机号,可以看出已经由A手机号(尾号3274)改为
了B手机号(尾号为5743),这说明Session成功覆盖了。这意味着重置密码将修改的是B
手机号(尾号为5743)的密码,如图12-27所示,这样就又诞生了一个任意密码重置漏
洞。
图12-27 重新进入找回密码页面
12.5.3 修复建议
Session覆盖类似于账号参数的修改,只是以控制当前Session的方式篡改了要重置密
码的账号,在重置密码请求中一定要对修改的账号和凭证是否一致做进一步的校验。
12.6 弱Token设计缺陷测试
12.6.1 测试原理和方法
在找回密码功能中,很多网站会向用户邮箱发送找回密码页面链接。用户只需要进入
邮箱,打开找回密码邮件中的链接,就可以进入密码重置页面了。找回密码的链接通常会
加入校验参数来确认链接的有效性,通过校验参数的值与数据库生成的值是否一致来判断
当前找回密码的链接是否有效。
例如,网站给出的找回密码的url如下,单击这个链接将跳转到重置密码页面。
http://www.xxx.com/findpwd?uid=xx-uu-xx-sxx&token=1497515314
观察这个链接的参数,uid参数可能是对应修改密码的账户,Token就是之前提到的校
验参数了,这个参数的值看起来像一个时间戳,猜测系统生成这个token的机制就是使用
的时间戳。把这个值通过时间格式化后发现确实变成了日期,那么这个Token就是可预测
的一个时间范围的时间戳,只需要通过这个时间段就可以推测或者暴力枚举出系统生成的
时间戳值了,如图12-27所示。
图12-28 时间戳转换
类似这样的弱Token现象有很多,比如将用户的uid加密成MD5或者base64编码,或者
直接用uid+4位随机数等这种可预测性的内容作为Token,测试时只需要多发几个找回密码
的请求观察系统每次发送的找回密码链接中的参数值是否有规律即可。
12.6.2 测试流程
步骤一:在类似的接收凭证方式的密码找回功能中,填写邮箱或者手机号,多单击几
次发送验证信息,可以在邮箱中获得多个找回密码的凭证,如图12-29、图12-30所示。
图12-29 发送验证信息
图12-30 接收多个找回密码邮件
图12-31 找回密码邮件内容
步骤二:邮箱中收到多封密码找回邮件,观察链接中的密码找回凭证是否有规律可
循,以下列出几个找回密码的链接。
第一封邮件:
http://www.xxx.com/index.php?m=CustomerService&a=resetPwdEml&token=dGVz dEAxMjYuY29tJjk5NTk=
第二封邮件:
http://www.xxx.com/index.php?m=CustomerService&a=resetPwdEml&token=dGVz dEAxMjYuY29tJjI2ODI=
第三封邮件:
http://www.xxx.com/index.php?m=CustomerService&a=resetPwdEml&token=dGVz dEAxMjYuY29tJjk4NzY=
步骤三:通过对比发现Token参数在不断地变化,参数似乎是通过base64编码的,对
此可以对这三个链接中的Token参数做base64解码操作,结果如表12-1所示
表12-1 解码结果
步骤四:解码后可以发现每一个Token的值是可以预测的,Token的生成机制应该
是“base64编码(用户邮箱+随机4位验证码)”,这样就可以通过暴力枚举获得验证码,加
上用户名再进行base64编码,最后得到任意用户的密码找回凭证。
12.6.3 修复建议
密码找回的Token不能使用时间戳或者用户邮箱和较短有规律可循的数字字符,应当
使用复杂的Token生成机制让攻击者无法推测出具体的值。
12.7 密码找回流程绕过测试
12.7.1 测试原理和方法
很多网站的密码找回功能一般有以下几个步骤。
(1)用户输入找回密码的账号;
(2)校验凭证:向用户发送短信验证码或者找回密码链接,用户回填验证码或单击
链接进入密码重置页面,以此方式证明当前操作用户是账号主人;
(3)校验成功进入重置密码页面。
在找回密码逻辑中,第二步校验凭证最为重要。不是账号主人是无法收到校验凭证
的,试想有没有办法可以绕过第二步凭证校验,直接进入第三步重置密码呢?
用户修改密码需要向服务器发送修改密码请求,服务器通过后再修改数据库中相应的
密码,所以在测试中我们首先要收集三个步骤的请求接口,重点是收集到最后一步重置密
码的接口,这样我们可以直接跳过凭证校验的接口去尝试直接重置密码。
在下面的密码找回案例中,需要用户填写要找回的账号然后验证身份,之后才可以进
入设置新密码的页面,我们需要对这个流程所有请求的接口做分析,找出最后一步重置密
码的接口,接着使用URL测试是否可以跳过验证身份环节。
12.7.2 测试流程
步骤一:先注册一个自己的账号用于测试所有流程,如图 12-32 所示,在找回密码页
面中先输入自己的账号单击“下一步”按钮,找回密码页面
URL
为
GET/account/findPassword.html。
图12-32 找回密码流程界面
步骤二:进入凭证验证流程,这里使用的是自己的账号,所以直接获取凭证,输入后
进入下一步,如图
12-33
所示。当前第二步的验证凭证
URL
为
GET/forgetpwd/findPassNext.do。
步骤三:通过验证以后就可以进入第三步重置密码了,如图12-34所示。当前重置密
码的URL为GET/forgetpwd/emailValidateNext.do。
图12-33 第二步发送邮箱凭证验证
图12-34 第三步重置新密码
步骤四:通过使用自己的账号使用正常顺序流程找回密码成功,我们也获取到了三个
步骤的所有URL,最后整理如下。
(1)GET/account/findPassword.html//输入用户账号页面
(2)GET/forgetpwd/findPassNext.do//验证身份页面
(3)GET/forgetpwd/emailValidateNext.do//设置新密码页面
接下来可以尝试在第一步输入账号后进入第二步验证身份页面,在这个页面直接修改
URL为第三步的URL,访问看看是否可以直接进入密码重置页面,如图12-35所示。
图12-35 第二步发送邮箱凭证验证
经过测试以后发现不需要验证身份可以直接进入重置密码页面,如图 12-36 所示,那
么最重要的验证身份这一步就被轻松绕过了,如图12-37所示。
图12-36 第二步发送邮箱凭证验证
图12-37 跳过第二部验证修改密码成功
12.7.3 修复建议
防止跳过验证步骤一定要在后端逻辑校验中确认上一步流程已经完成。
第13章 业务接口调用模块测试
13.1 接口调用重放测试
13.1.1 测试原理和方法
在短信、邮件调用业务或生成业务数据环节中,如短信验证码、邮件验证码、订单生
成、评论提交等,对业务环节进行调用(重放)测试。如果业务经过调用(重放)后多次
生成有效的业务或数据结果,可判断为存在接口调用(重放)问题。
13.1.2 测试过程
如图13-1所示,在进行接口调用重放测试时,攻击者与普通用户的区别在于他会通过
工具(如Burp Suite)抓取订单请求,然后在短时间内通过Burp Suite工具的Repeater对请
求(如订单请求)进行多次重放,服务器则会根据请求在短时间内执行多个有效操作(如
生成订单)。
测试过程以某购买机票系统为例。
步骤一:如图13-2所示,在购买机票“提交订单”环节抓取数据包。
图13-1 接口调用重放测试流程图
图13-2 提交订单
步骤二:如图13-3所示,使用Burp Suite工具对生成订单的数据包进行重放测试。
步骤三:如图13-4所示,查看返回结果,订单在1分钟内重复生成。
图13-3 Burp Suite抓取提交订单的请求
图13-4 一分钟内生成重复订单
13.1.3 修复建议
(1)对生成订单环节采用验证码机制,防止生成数据业务被恶意调用。
(2)每一个订单使用唯一的Token,订单提交一次后,Token失效。
13.2 接口调用遍历测试
13.2.1 测试原理和方法
Web 接口一般将常见的一些功能需求进行封装,通过传入不同的参数来获取数据或
者执行相应的功能,其中一个最常见的场景就是通过接口传入id参数,返回对应id的一些
信息。在安全测试中,我们可以使用Burp
Suite作为HTTP代理,记录所有请求和响应信
息,通过Burp Suite以登录后的状态对整站进行爬取,再使用过滤功能找到传入id参数的
HTTP请求,然后通过Intruder对id参数进行遍历,看是否返回不同的响应信息。如果不同
的id值对应不同用户的信息,则说明存在漏洞。
13.2.2 测试过程
如图13-6所示,攻击者在测试前,使用Brup Suite的爬虫功能对网站进行爬取,然后
筛选出包含用户标识参数的请求(如id、uid),对筛选后的每一个请求进行分析,判断
其是否包含敏感信息。如果包含敏感信息,则通过Brup Suite的Intruder设置用户标识参数
为变量来进行遍历,如果返回他人信息,则漏洞存在。
图13-5 接口调用遍历测试流程图
步骤一:如图13-6所示,使用Burp Suite的爬虫功能,从重点关注的目录(一般为网
站根目录)开始爬取,在 HTTP history 选项卡中选中要开始爬取的项,单击鼠标右键,
选择“Spider from here”,爬取登录后的网站链接。
图13-6 使用Burp Suite爬取网站根目录
如图13-7所示,爬取的结果会在Target→Site map中显示,在爬取完毕后,再使用Burp Suite的过滤功能筛选出带有uid参数的链接,没有包含uid字符串的HTTP请求会被隐藏起
来,不会在HTTP history中显示。
图13-7 过滤出带有uid的请求
如图13-8所示,在请求中找到uid参数出现的位置。
图13-8 定位uid参数的出现位置
步骤二:如图13-9所示,查看对应的HTTP请求的响应包中是否带有想要的信息。由
HTTP
请求的参数我们可以猜测到这个请求的功能,如
method
参数值为
video.getUserVideoRecordList,作用是获取对应 uid 的视频播放的历史记录,由响应内容
可以确定。
图13-9 查看对应的请求和响应
HTTP响应中包含一些敏感信息,如观看视频时的ip 地址、视频id、视频的标题等。
如图13-9所示,第一个title的值为All Polished&#039;";<;\/img>;,在浏览
器的console终端通过document.write函数解码输出后,得到All Polished'"</img,如图13-10
所示。
如图13-11所示,将title的值和视频历史播放记录进行比较,可以发现完全一致。
图13-10 解码响应中的title值
图13-11 与历史播放记录进行比较
步骤三:如图13-12所示,将HTTP请求发送到Intruder,设置后四位数字为变量,进
行遍历测试。
图13-12 发送到Intruder
如图13-13所示,我们设置后四位数字为变量。
图13-13 设置变量
如图13-14所示,设置Payload为0000~9999的数字。
图13-14 设置payload
设置完Payload后,单击“Start attack”按钮即可开始遍历测试。
步骤四:分析 Intruder 的测试结果,不存在对应的 uid 时,服务器会返回 code为-201
的响应;存在时,返回的响应会包含"ip"(带双引号)这个字符串,以此来过滤出成功的
请求,如图13-15所示。
图13-15 对Interder结果进行过滤
如图13-16所示,可以看到过滤后的请求,均是有播放记录的请求,确认存在接口调
用遍历测试漏洞。
图13-16 确认漏洞
13.2.3 修复建议
在Session中存储当前用户的凭证或者id,只有传入凭证或者id参数值与Session中的一
致才返回数据内容。
13.3 接口调用参数篡改测试
13.3.1 测试原理和方法
在短信、邮件调用业务环节中,例如短信验证码、邮件验证码。修改对应请求中手机
号或邮箱地址参数值提交后,如果修改后的手机号或邮箱收到系统发送的信息,则表示接
口数据调用参数可篡改。
13.3.2 测试过程
如图13-17所示,攻击者拥有账号B,用户拥有账号A。攻击者对账号A进行密码找回
操作,服务器给账号 A 的邮箱或者手机发送密码重置信息,攻击者进入验证码验证环
节,此时攻击者单击“重新发送验证码”并拦截重新发送这个请求,将请求中的接收验证码
用户的邮箱或者手机修改为自己的。如果接收到密码重置信息,则存在漏洞。
图13-17 接口调用参数篡改测试流程图
测试过程以某手机App系统为例。
步骤一:如图13-18所示,在短信验证码页面单击“重新发送”同时抓取数据包。
图13-18 发送验证码并使用Burp Suite抓包
步骤二:如图13-19所示,在截取数据中将param.telno参数(指定发送手机号码)修
改为其他手机号码。
图13-19 Burp Suite修改参数值
步骤三:如图13-20所示,修改后被指定的手机号收到相应验证码短信。
图13-20 确认漏洞
13.3.3 修复建议
(1)会话Session中存储重要的凭证,在忘记密码、重新发送验证码等业务中,从
Session获取用户凭证而不是从客户请求的参数中获取。
(2)从客户端处获取手机号、邮箱等账号信息,要与 Session 中的凭证进行对比,
验证通过后才允许进行业务操作。
13.4 接口未授权访问/调用测试
13.4.1 测试原理和方法
在正常的业务中,敏感功能的接口需要对访问者的身份进行验证,验证后才允许调用
接口进行操作。如果敏感功能接口没有身份校验,那么攻击者无须登录或者验证即可调用
接口进行操作。在安全测试中,我们可以使用Burp Suite作为HTTP代理,在登录状态下记
录所有请求和响应信息,筛选出敏感功能、返回敏感数据的请求。在未登录的情况下,使
用浏览器访问对应敏感功能的请求,如果返回的数据与登录状态后的一致,则存在漏洞或
缺陷。
13.4.2 测试过程
如图13-21所示,攻击者在测试前,使用Brup Suite的爬虫功能对网站进行爬取,通过
MIME
Type筛选出与接口相关的请求,对筛选后的每一个请求进行判断是否包含敏感信
息。如果包含敏感信息,则复制请求URL到未进行登录的浏览器进行访问,如果访问后返
回之前的敏感信息,则存在漏洞。
图13-21 接口未授权访问测试流程图
步骤一:登录后使用Burp
Suite的爬虫功能,从重点关注的目录(一般为网站根目
录)开始爬取,在HTTP
history选项卡中选中要开始爬取的项,右键选择“Spider
from
here”。爬取的结果会在Target→Site
map中显示。如图13-20所示,在爬取完毕后,使用
Burp Suite的MIME type过滤功能,筛选出接口相关的HTTP请求,重点关注json、script、
xml、text MIME type等。
图13-22 对MIME type进行过滤
步骤二:如图12-23所示,对接口相关的请求进行查看,查看响应中是否包含想要的
敏感信息,如个人电话、IP地址、兴趣爱好、网站历史记录、身份证、手机号、住址等信
息。
图13-23 查找包含敏感信息的HTTP请求
通过查看响应包的具体信息,可以发现返回页面包含敏感信息,如ip地址、视频的历
史播放等信息,通过这些信息可以了解其位置及关注点。
步骤三:如图13-24所示,将完整的请求URL复制到未登录的浏览器中,查看能否访
问对应URL的内容。如果能够返回敏感信息,则说明漏洞存在;如果需要登录验证后才能
访问,则不存在该漏洞。
图13-24 未登录状态下访问URL
在未进行登录的浏览器上,能够直接返回对应URL的页面内容而无须验证其身份,则
该网站存在接口未授权访问的漏洞。
13.4.3 修复建议
(1)采用Token校验的方式,在url中添加一个Token参数,只有Token验证通过才返
回接口数据且Token使用一次后失效。
(2)在接口被调用时,后端对会话状态进行验证,如果已经登录,便返回接口数
据;如果未登录,则返回自定义的错误信息。
13.5 Callback自定义测试
13.5.1 测试原理和方法
在浏览器中存在着同源策略,所谓同源是指域名、协议、端口相同。当使用Ajax异步
传输数据时,非同源域名之间会存在限制。其中有一种解决方法是JSONP(JSON
with
Padding),基本原理是利用了HTML里<script></script>元素标签,远程调用JSON文件来
实现数据传递。JSONP 技术中一般使用 Callback(回调函数)参数来声明回调时所使用的
函数名,这里往往存在安全问题,由于没有使用白名单的方法进行限制Callback的函数
名,导致攻击者可以自定义Callback内容,从而触发XSS等漏洞。
13.5.2 测试过程
如图13-25所示,攻击者在测试前,使用Brup Suite的爬虫功能对网站进行爬取,筛选
出带有Callback或者jsonp参数的请求,对请求响应的Content-Type进行判断,如果Content-Type为text/html,则进行下一步,接着攻击者对Callback参数进行分析,如果Callback参数
允许攻击插入HTML标签,则存在漏洞。
图13-25 CallBack测试流程图
步骤一:如图13-26所示,使用Burp Suite的爬虫功能,从重点关注的目录(一般为网
站根目录)开始爬取,在 HTTP history 选项卡中选中要开始爬取的项,右键选择“Spider from here”。
如图13-27所示,爬取的结果会在Target→Site
map中显示。在爬取完毕后,再使用
Burp Suite的过滤功能找到带有Callback参数的链接,如图13-28所示。
图13-26 从网站根目录开始爬取
图13-27 切换到Site map标签页
图13-28 使用callback关键词进行过滤
在输入关键词之后,再单击图13-28中序号“1”的位置即可让过滤生效。步骤二:如图
13-29所示,找到URL带有callback参数的链接。
图13-29 定位到callback参数位置
步骤三:查看URL对应的HTTP
Response的Content-Type类型是否为text/html。如果
Content-Type为text/html,我们输入的HTML标签才会被浏览器解析。如图12-30所示,
Content-Type类型为text/html,将对应的请求发送到Repeater,继续步骤四。
图13-30 观察响应的Content-Type
步骤四:如图13-31所示,查看callback参数是否存在过滤及可控,这时我们需要在
callback参数值前追加一些文本类的HTML标签,不直接使用script等标签是避免waf等防护
设备的检测。我们这里使用的HTML标签是一级标题标签<h1>。
如图13-32所示,根据Response的内容,我们可以了解到callback参数不存在过滤及可
控。进一步测试发现info参数对Response的输出内容没有影响,删除掉info参数,精简
URL。
图13-31 测试callback参数是否可控
图13-32 精简漏洞URL
步骤五:如图13-33所示,将callback参数更换成带有恶意行为的HTML标签,进行利
用。
图13-33 确认漏洞
13.5.3 修复建议
(1)严格定义 HTTP 响应中的 Content-Type 为 json 数据格式:Content-Type:
(2)建立callback函数白名单,如果传入的callback参数值不在白名单内,跳转到统
一的异常界面阻止其继续输出。
(3)对callback参数进行HTML实体编码来过滤掉“<”、“>”等字符。
13.6 WebService测试
13.6.1 测试原理和方法
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的用于描述Web Service及其函数、参数和返回值的
语言。
通过上面的描述,我们可以知道WebService就是一个应用程序向外界暴露出一个能通
过Web进行调用的API。这个API接收用户输入的参数,然后返回相关的数据内容。如果
一个WebService完全信任用户的输入,不进行过滤,则有可能导致SQL注入漏洞的发生。
13.6.2 测试过程
如图13-34所示,攻击者在测试前,通过爬虫或者目录扫描等方法找到服务器的
WebService链接,接着使用WVS(Web Vulnerability Scanner)的Web Services Editor功能
导入各个接口函数,通过关键词(如Get、Exec)定位到相关的接口函数,通过HTTP
Editor对每一个接口函数的输入参数进行测试(如SQL注入、文件上传等),如果出现预
期效果(如数据库报错、不同的延时等),则存在漏洞。
图13-34 WebService测试流程图
步骤一:找到服务器的WebService的链接,在WebService后面加上“?wsdl”,服务器
便会返回WSDL描述函数信息,如图13-35所示。
步骤二:如图13-36所示,使用WVS(Web
Vulnerability
Scanner),单击左边栏
的“Web Services Editor”。
在Operation选项列表中,可以看到WebService定义的多个函数,选择其中一个,
WVS便会显示需要输入的参数值。在选择的时候,我们尽量选择一些可能会涉及数据库
操作的函数,比如函数名以Get开头的,一般是从数据库返回一些信息;比如以Exec开头
的,一般是直接执行SQL语句或者特定指令。如图13-37所示,这里选择的是
ExecNonQuery函数,从函数名可以看出,这应该是用来执行非查询语句的接口。其中接
收一个名为sql的参数,从命名看,这个参数应该用来指定要执行的SQL语句。
图13-35 获取WebService链接
图13-36 使用WVS查看WebService
图13-37 查看ExecNonQuery函数的参数细节
步骤三:如图13-38所示,单击“HTTP Editor”切换到HTTP请求界面,我们可以发送
SOAP请求,以及接收请求后的响应。
图13-38 单击“HTTP Editor”切换到HTTP请求
如图13-39所示,我们修改sql参数的值为“1'”,查看响应内容。
图13-39 修改sql参数
如图13-40所示,结合微软官方的文档信息,System.Data.SqlClient.SqlConnection 是.NET Framework 连接 SQL Server 的类库,由此可知后端数据库使用的是 SQL Server数
据库。
步骤四:如图13-41所示,在了解数据库类型后,我们可以使用具体的非查询类的
SQL语句去测试输入参数是否存在SQL注入漏洞。这里要使用select语句等查询类的SQL语
句,其返回响应为false。
图13-40 分析异常信息
图13-41 测试非查询语句
测试是否存在漏洞,应该使用延时类的SQL语句,通过返回响应的时间间隔来确认是
否可以直接执行SQL语句。这里由于是SQL Server,应该使用SQL Server的延时语句,所
以使用“waitfor delay'0:0:3'”,这里'0:0:3'代表3秒。如图13-42所示,WVS显示的时间
间隔大于3000 ms,与SQL语句延时的时间一致,存在漏洞。
图13-42 延时注入3秒
如图13-43所示,延时5秒“waitfor delay'0:0:5'”。
图13-43 延时注入5秒
步骤五:剩下的利用步骤和常规的 SQL 注入测试一致,使用 Wireshark 或者Burp Suite将WebService的请求抓取下来,保存到文本文件。在需要测试的参数值处添加星
号“*”,如图13-44所示。
图13-44 保存请求到文件中
然后通过sqlmap对参数进行检测即可,sqlmap对应的具体参数是-r,如图13-45和图
13-46所示。
图13-45 使用sqlmap进行测试
图13-46 确认漏洞存在
13.6.3 修复建议
(1)为WebService添加身份认证,认证成功后才允许访问和调用。
(2)WebService中接收输入参数的函数,在后端应该对输入参数进行过滤及净化,
在处理后才入库查询。
(3)在敏感功能的函数中,添加密码认证,认证后才允许调用敏感功能的函数。
14.1 账号安全归纳
随着网络的快速发展,出现了种类繁多的网络应用,包括E-mail、IM即时聊天工具
(QQ、MSN)、网络商店、BBS论坛、网络游戏等。各类应用均需要身份识别,因此身
份认证是网络信息安全的基本保障。网络服务器通过身份认证与访问控制的方式对合法注
册用户进行授权。用户首先通过注册(账号与密码)成为网络服务器的合法用户,只有通
过身份认证的用户才能访问资源。账号与密码成为各类网络应用必不可少的一部分,与此
同时账号和密码所面临的安全问题也越来越多。
例如,2011年某网站上600万用户资料可公开下载,而其存储密码的方式还是明文。
同时,2015年某论坛泄露2300万用户的信息,泄露的2300万用户数据包括用户名、注册邮
箱、加密后的密码等。2015年10月,某漏洞报告平台接到一起数据泄密报告后发布新漏
洞,该漏洞显示某网站用户数据库疑似泄露,影响到过亿数据,泄露信息包括用户名、密
码、密码密保信息、登录IP及用户生日等。
互联网上关于账号的安全问题日益凸显,本章总结的关于账号安全的相关漏洞包括密
码泄漏、暴力破解、弱口令、密码重置、登录账号绕过、重放攻击、网络钓鱼、信息泄
露、中间人攻击等。希望广大读者可以引以为鉴,不再出现此类问题。
14.2 账号安全相关案例
14.1.1 账号密码直接暴露在互联网上
GitHub是一个分布式的版本控制系统,开发者可以通过GitHub上传项目源代码。不过
由于开发者的安全意识不足,可能会上传部分敏感信息,包括邮件的账号密码、数据库的
配置信息、管理员的密码、备份文件、重要源代码等。
通过搜索引擎可灵活查找各类敏感信息,搜索语法如下。
(1)邮件配置信息查询:site:Github.com smtp password;
(2)数据库信息泄露:site:Github.com sa password;
(3)svn信息泄露:site:Github.com svn;
(4)数据库备份文件:site:Github.com inurl:sql。
14.2.1.1 某企业数据库配置信息泄露
步骤一:利用各类搜索引擎搜索敏感文件,搜索的语法为“site:github.com password”,就可以直接在GitHub网站上找到配置信息。如图14-1所示,可以获得某企业
数据库配置信息。
图14-1 数据库配置信息
步骤二:利用数据库配置信息成功登录数据库,可获得大量企业用户信息,如图14-2
所示。
图14-2 成功登录数据库
14.2.1.2 某著名厂商数千名员工信息泄漏
步骤一:通过GitHub查找到某厂商的一个开源项目,如图14-3所示,发现其中一份文
件包含一个加密信息。
图14-3 网站配置信息
步骤二:通过base64解密,发现是一个HTTP请求包,并且包含Cookies值。将请求包
的内容复制到浏览器即可登录内部系统,如图14-4所示。
图14-4 利用数据包登录后台
步骤三:如图14-5所示,在该系统可以获得该企业数千名员工信息。
图14-5 内部通讯录
14.1.2 无限制登录任意账号
由于各类应用的安全防护手段参差不齐,导致攻击者可以利用漏洞绕过登录限制,或
者利用已经认证的用户,通过修改身份ID登录任意账号。
14.2.2.1 某大学网站SQL注入漏洞可绕过登录限制
步骤一:某学校网站后台为http://www.xxx.edu.cn/login.asp,登录界面如图14-6所
示。
图14-6 绕过登录测试
步骤二:因网站登录处过滤不严格导致存在SQL注入漏洞,利用万能密码,可以绕过
登录的限制成功登录后台,如图14-7所示。
图14-7 成功登录
14.2.2.2 某APP客户端可以劫持任意账号
步骤一:在某App的官网上查看已经注册的用户,如图14-8所示。
图14-8 查看注册用户ID
步骤二:通过浏览器审查元素,如图14-9所示,可以得到该用户的ID值。
图14-9 查看用户ID
步骤三:下载该客户端,单击微博授权登录,如图14-10所示。
图14-10 授权登录
步骤四:在登录过程中截取数据包,如图14-11所示,修改uid里面的数据,即可登录
其他人的账号。
图14-11 替换用户ID
步骤五:如图14-12所示,成功利用微博劫持他人账号并登录成功。
图14-12 成功登录他人账号
14.1.3 电子邮件账号泄露事件
电子邮箱业务基于计算机和通信网的信息传递业务,利用电信号传递和存储信息,为
用户传送电子信函、文件数字传真、图像和数字化语音等各类型的信息。电子邮件最大的
特点是,人们可以在任何地方、任何时间收、发信件,解决了时空的限制,大大提高了工
作效率,为办公自动化、商业活动提供了很大便利。但电子邮件账号泄露,也将引发大量
的信息泄露。
14.2.3.1 邮件账号引发的信息泄漏
步骤一:如图14-13所示,通过搜索引擎查找某公司公开于互联网的文件。
图14-13 敏感文件查找
步骤二:下载该XLS文件,从文件中获得某企业员工的邮件账号密码,如图14-14所
示,成功登录邮件系统。
图14-14 登录邮件系统
步骤三:在一份邮件中发现该公司部分信息,包括VPN登录地址、OA系统及内网各
个系统的登录方式,利用该邮件的账号密码均能登录各类内网系统,从而获得大量敏感数
据。如图14-15所示,成功拨入VPN,任意访问内网系统。
步骤四:如图14-16所示,成功登录OA系统,可以获取职工个人信息,包括手机号
码、身份证、工作内容等。
图14-15 登入VPN
图14-16 登录OA系统
步骤五:如图14-17所示,成功登录内部订单系统,查看大量订单数据。
图14-17 登录内部数据平台
14.1.4 中间人攻击
中间人攻击,即所谓的Main-in-the-middle(MITM)攻击,顾名思义,就是攻击者插
入到原本直接通信的双方中间,让双方以为还在直接跟对方通信,但实际上双方的通信对
象已变成了攻击者,同时信息已经被中间人获取或篡改。而中间人攻击不仅可以捕获
HTTP未加密的传输数据,更可以捕获HTTPS协议加密的数据。
HTTPS中间人攻击一般分为SSL连接建立前的攻击,以及HTTPS传输过程中的攻击。
常见的HTTPS中间人攻击,会首先需结合ARP、DNS欺骗、伪造CA证书等技术,来对会
话进行拦截。
14.2.4.1 SSL证书欺骗攻击
SSL证书欺骗攻击较为简单,首先通过DNS劫持和局域网ARP欺骗甚至网关劫持等技
术,将用户的访问重定向到攻击者的设备上,让用户机器与攻击者机器建立HTTPS连接
(使用伪造的CA证书),而攻击者机器再跟Web服务端连接。这样攻击者的机器分别与
用户和真正的服务器建立 SSL 连接,通过这两个连接之间转发数据,就能得到被攻击者
和服务器之间交互的数据内容。但用户的浏览器会提示证书不可信,只要用户不单击继续
就能避免被劫持。所以这是最简单的攻击方式,也是最容易识别的攻击方式。如图14-18
所示,为SSL证书欺骗攻击流程。
图14-18 证书欺骗过程
14.2.4.2 SSL劫持
SSL劫持,是指将页面中的HTTPS超链接全都替换成HTTP版本,让用户始终以明文
的形式进行通信。在现实生活中,用户在浏览器上输入域名,大部分采用直接输入网址的
方式,从而会忽略该网站采用的协议类型。例如打开百度,一般会直接输入
www.baidu.com,用户向百度发送一个 HTTP 请求,而不是 HTTPS。HTTP是以明文传输
数据的,因此如果利用 SSL 劫持攻击,使 HTTPS 协议的网站降级到HTTP,就能获取敏
感数据。
有部分网站并非全部采用HTTPS协议,只是在需要进行敏感数据传输时才使用
HTTPS 协议,如登录认证、传输敏感身份数据等时候。中间人攻击者在劫持了用户与服
务端的会话后,将HTTP页面里所有的HTTPS超链接都换成HTTP,用户在单击相应的链
接时,使用HTTP协议来进行访问。这样即使服务器对相应的URL只支持HTTPS链接,但
中间人攻击者一样可以和服务建立HTTPS连接之后,将数据使用HTTP协议转发给客户
端,实现会话劫持。
SSL劫持攻击手段更让人防不胜防,因为用户无法提前知道网站是否使用HTTPS
或
者 HTTP,而在用户的浏览器上更不会弹框告警或者网页错误显示。如图11-19所示为SSL
劫持攻击流程。
图14-19 SSLStrip攻击示例
如图14-20所示,可利用SSLStrip工具成功劫持Gmail账号。
图14-20 劫持Gmail账号
14.1.5 撞库攻击
撞库是黑客通过收集互联网已泄露的用户和密码信息,生成对应的字典表,尝试批量
登录其他网站后,得到一系列可以登录的用户名和密码组合。由于很多用户在不同网站使
用的是相同的账号和密码,因此黑客可以通过获取用户在 A 网站的账户从而尝试登录B网
站,这就可以理解为撞库攻击。
14.2.5.1 某知名公司子站存在撞库风险
步骤一:某知名公司官方网站用户登录有验证码校验机制,但有个子站没有限制登录
次数,因此可利用该子站进行撞库攻击,在该子站验证成功后再返回主站进行登录,如图
14-21和图14-22所示。
图14-21 子站登录界面
图14-22 登录数据包
步骤二:如图14-23所示,利用捕获到的数据包通过Burp Suite的intruder模块进行撞库
攻击。
图14-23 Burp Suite暴力破解
步骤三:利用该子站撞库攻击的结果,返回主站登录尝试,如图14-24所示,成功登
录主站。
图14-24 利用撞库成功登录
14.3 防范账号泄露的相关手段
随着互联网和各类网络应用的快速发展,关于保护账号安全的措施也迫在眉睫。总结
本章的账号安全相关案例,建议企业在防护账号和密码方面使用如下措施:
(1)核查数据库中的账号和密码存储方式,自行加密用户敏感数据,严格限制数据
(2)采用 HTTPS 协议对账户认证过程实现加密封装,确保身份认证过程无法被窃
取。
(3)加强网络信息安全意识,网络管理人员对内部员工进行安全意识培训,禁止使
用弱口令,禁止公开个人账号密码,定期修改密码。
(4)使用数字证书认证。数字证书是通过运用对称和非对称密码体制等密码技术建
立起一个严密的身份认证系统,从而保证信息除发送方和接收方外不被其他人窃取。
(5)了解互联网账号泄露事件,存在账号泄露事件时第一时间通知客户修改个人账
号和密码,避免撞库攻击。
(6)加强对网站的安全防护能力,定期进行安全评估和升级更新,避免攻击者利用
漏洞获取账户信息。
第15章 密码找回安全案例总结
密码找回功能中潜在的逻辑漏洞,将使互联网用户的账户面临严重的安全风险。本章
将全面剖析常见密码找回逻辑漏洞案例,使读者了解和掌握该功能中存在的问题,规避密
码找回安全风险。
15.1 密码找回凭证可被暴力破解
密码找回凭证是指在密码找回过程中,服务端向用户的注册手机或者邮箱中发送的验
证码或特殊构造的URL等用于用户自证身份的信息。当用户凭证的验证次数未做限制或限
制不严可被绕过时,攻击者可以通过暴力枚举用户凭证的方式,冒充该用户重置其密码。
其业务流程如图15-1所示。
图15-1 业务流程图
15.1.1 某社交软件任意密码修改案例
2012年,某社交软件的官网上新增了一个忘记账号或密码的链接。
步骤一:单击忘记密码链接后,进入重设密码选择页,如图15-2和图15-3所示。
图15-2 忘记密码链接
图15-3 重设密码选择页
步骤二:选择使用手机号重设密码,并输入一个真实注册用户的手机号码,如图15-4
所示。
图15-4 重设密码页面
步骤三:单击“下一步”按钮后,系统提示将发送验证码到注册手机,如图15-5所示。
图15-5 发送验证码页面
步骤四:单击“我已收到验证短信”后,系统弹出重置密码确认页,需要输入手机上收
到的验证码作为密码找回凭证。核对成功则可以成功进行密码重置,如图15-6所示。
图15-6 发送验证码页面
步骤五:单击“OK”并对该请求进行抓包,获取到包文:
check=false&phone=186XXXXXXXX&……&verifycode=1234。
步骤六:根据以上包文信息可以发现该密码找回功能的验证码比较简单,只有4位数
字,可以尝试枚举修改包文中的verifycode进行暴力破解。几次尝试后收到系统提示“您的
提交请求过于频繁,请稍后再试。”说明该网站的密码找回功能是对用户凭证的验证频率
做了限制的,只能想办法绕过其限制。
步骤七:经过一系列尝试后发现,在phone=186XXXXXXXX的号码后面随机添加不
为数字的字符时,可以绕过此限制。于是推测其漏洞点在于判断 phone=186XXXXXXXX
的尝试次数时未对phone的值进行提纯,所以可以利用在号码后添加随机字符的方式绕过
限制。但在下一步操作的时候,只取了phone中的数字部分,然后再取出此号码的
verifycode进行比对,比对成功则修改密码,如图15-7所示。
图15-7 暴力破解示例
15.2 密码找回凭证直接返回给客户端
有些信息系统在密码找回功能的设计上存在逻辑漏洞,可能会将用于用户自证身份的
信息的密码找回凭证以各种各样的方式返回到客户端。这样攻击者只要通过在本地抓取数
据包并对其内容加以分析就能获取到其他用户的密码找回凭证,从而冒充该用户重置密
码,如图15-8所示。
图15-8 测试流程图
15.2.1 密码找回凭证暴露在请求链接中
步骤一:进入某直播网站登录处,单击忘记密码,选择通过注册手机找回密码,如图
15-9所示。
图15-9 通过注册手机找回密码
步骤二:输入手机号码,单击获取验证码,然后使用Firebug查看请求链接,发现验
证码直接出现在请求链接中,如图15-10所示。
图15-10 验证码出现在请求链接中
步骤三:直接输入请求链接中暴露出来的验证码即可修改密码。
15.2.2 加密验证字符串返回给客户端
步骤一:进入某电商官网按正常流程执行找回密码功能,填写好邮箱和图片验证码,
进入下一步,然后使用抓包工具抓取请求包。
步骤二:分析返回的数据包,发现其中包含了一个加密字符串,将其记录下来,如图
15-11所示。
图15-11 抓包返回数据结果
步骤三:之后,邮箱中会收到一个找回密码用的验证码。将该验证码在页面上填好,
单击下一步按钮即可进入密码重置页面,如图15-12所示。
步骤四:仔细观察发现,密码重置页面URL中的加密验证字符串和之前返回数据包中
的加密字符串是同一个,如图15-10和图15-11所示。既然如此,则可以绕过邮箱验证码校
验,直接利用抓包工具获取到的加密字符串构造到URL中进行任意密码重置,如图15-12
所示。成功重置并登录了官方客服的账号,如图15-13所示。
图15-12 密码重置页面
图15-13 密码重置并登录成功
15.2.3 网页源代码中隐藏着密保答案
步骤一:进入某邮箱网站官网,单击“找回密码”按钮,再单击“网上申诉”链接,如图
15-14所示。
步骤二:在网上申诉页面直接查看源代码,发现源代码中不但有密码提示问题,还在
Hide表单里隐藏着问题答案。通过该方式,可获得任意用户修改密码问题答案,从而可以
修改其他用户邮箱密码,如图15-15所示。
图15-14 网上申诉链接
图15-15 密保答案泄露
15.2.4 短信验证码返回给客户端
步骤一:进入某商城网站首页,单击忘记密码。
步骤二:使用一个已注册的手机号码,通过短信验证方式找回密码,如图15-16所
示。
图15-16 通过短信验证方式找回密码
步骤三:输入图片验证码,单击获取短信验证码,如图15-17所示。
图15-17 获取验证码
步骤四:此时抓取数据包,发现服务端直接将短信验证码646868返回给了客户端,将
短信验证码填写到验证码处即可成功重置其密码。同理,通过该方式,可以重置其他用户
的密码,如图15-18所示。
图15-18 返回短信验证码
15.3 密码重置链接存在弱Token
有些信息系统的密码找回功能会在服务端生成一个随机 Token 并发送到用户邮箱作
为密码找回凭证。但一旦这个 Token 的生成方式被破解,攻击者就可以伪造该Token作为
凭证重置其他用户的密码。测试流程如图15-19所示。
图15-19 测试流程图
15.3.1 使用时间戳的md5作为密码重置Token 步骤一:进入某网站先按正常流程取回一次密码,查看邮箱,邮件内容如图15-20所
示。
图15-20 邮件内容
步骤二:从邮件内容中可以看出参数vc为一串md5值,u为用户邮箱。将参数vc解密
后为1496732066。于是猜测参数vc应该为id值,尝试遍历id值并修改变量u,查看是否可以
修改其他用户密码,结果发现不可行。
步骤三:再仔细观察vc参数,发现和UNIX时间戳格式相符,于是使用UNIX时间戳转
换工具验证,转换成功,如图15-21所示。
图15-21 UNIX时间戳转换
步骤四:大致推测出该系统找回密码的流程。用户取回密码时,先产生一个精确的时
间戳并与账号绑定记录在数据库内,同时将该时间戳作为密码找回凭证发送到用户的注册
邮箱。只要用户能够向系统提供该时间戳即可通过认证,进入密码重置流程。但对攻击者
来说,只要编写一段程序在一定时间段内对时间戳进行暴力猜解,很快就可以获得找回密
码的有效链接,如图15-22所示。
图15-22 测试exp
步骤五:最终成功重置密码并登录到个人中心,如图15-23所示。
图15-23 重置密码成功
15.3.2 使用服务器时间作为密码重置Token
步骤一:进入某积分兑换商城,首先用 2 个账号在两个浏览器窗口中同时找回密码来
进行对比,如图15-24所示。
步骤二:对比邮箱中收到的找回密码链接,我们可以看出,找回密码使用的随机
Token只相差4,那么攻击者通过遍历Token的方式即可重置其他用户的密码,如图15-25所
示。
图15-24 开始找回密码
图15-25 重置密码链接
15.4 密码重置凭证与用户账户关联不严
有些信息系统在密码找回功能的校验逻辑上存在缺陷,只校验了密码重置凭证是否在
数据库中存在,但未严格校验该重置凭证和用户账号之间的绑定关系。这种密码重置凭证
与用户账户关联不严的逻辑漏洞就让攻击者可以通过在数据包中修改用户账号达到重置其
他密码的目的,如图15-26所示。
图15-26 业务流程图
15.4.1 使用短信验证码找回密码
步骤一:进入某手机厂商官网,首先填写自己的手机号码进行密码找回。
步骤二:收到验证码后填入验证码和新密码提交,这时候使用数据抓包工具进行抓
包,将数据包中的username修改为其他账号,post上去后就可以使用自己设置的密码登录
其他账号,如图15-27所示。
图15-27 重置密码链接
15.4.2 使用邮箱Token找回密码
步骤一:进入某公共信息网站使用真实信息找回密码后,系统会发送一封邮件到绑定
的邮箱。邮件中的找回密码链接如下:
http://**.**.**.**/test.do?method=resetPassword&id=用户ID值
&authcode=XXX&Email=邮箱地址
步骤二:访问后可直接进入用户密码重置页面。在该页面输入新密码,并在提交时使
用抓包工具抓取数据抓包,可获得以下内容:
org.apache.struts.taglib.html.TOKEN=83accc27d5178f832d9f22a1d02bdacf&org.apache.struts.taglib.html.TOKEN=83accc27d5178f832d9f22a1d02bdacf&rt Password=123456&passwordw=123456&rtEmail=邮箱&idtagCard=用户ID
步骤三:虽然包文中含有org.apache.struts.taglib.html.TOKEN和
org.apache.struts.taglib.html.TOKEN两个Token参数,但因为并没有和用户ID进行绑定验
证,依然可以通过修改用户ID重置他人密码。随机修改了一个用户ID并提交后,提示密
码重置成功,如图15-28所示。
图15-28 密码重置成功
15.5 重新绑定用户手机或邮箱
有些信息系统在绑定用户手机或者邮箱的功能上存在越权访问漏洞。攻击者可以利用
该漏洞越权绑定其他用户的手机或者邮箱后,再通过正常的密码找回途径重置他人的密
码。
15.5.1 重新绑定用户手机
步骤一:首先注册一个某邮箱的测试账号,然后会跳转到一个手机绑定的页面上,如
图15-29所示。
图15-29 绑定手机页面
步骤二:注意此处链接中有个参数为uid,将uid修改为其他人的邮箱账号。填入一个
你可控的手机号码,获取到验证码。确定后这个目标邮箱已经被越权绑定了密保手机,如
图15-30所示。
图15-30 手机号码绑定成功
步骤三:走正常的密码取回流程,发现这个邮箱多了一个通过手机找回密码的方式,
这个手机尾号就是刚刚绑定的手机号码,如图15-31所示。
步骤四:获取验证码并填入新密码,最终成功重置了目标账户的密码,如图15-32所
示。
图15-31 找回密码流程
图15-32 找回密码成功
15.5.2 重新绑定用户邮箱
步骤一:某网站用户注册后的激活页面链接如下:
http://**.***.com/user/test/2815193
步骤二:链接尾部的一串数字是用户的ID,通过修改这个ID即可进入其他用户的页
面,如图15-33所示,该页面提供了更改邮箱地址的功能,可在此处将邮箱地址修改为自
己的测试邮箱。
图15-33 用户激活页面
步骤三:然后使用该测试邮箱进行密码找回,即可重置目标用户的密码,如图15-34
所示。
图15-34 重置密码成功
15.6 服务端验证逻辑缺陷
有些信息系统的服务端验证逻辑存在漏洞。攻击者可以通过删除数据包中的某些参
数、修改邮件发送地址或者跳过选择找回方式和身份验证的步骤,直接进入重置密码界面
成功重置其他人的密码。
15.6.1 删除参数绕过验证
步骤一:某邮箱系统可以通过密码提示问题找回密码,如图15-35所示。
图15-35 通过密码提示问题找回密码
步骤二:首先随机填写密码答案,然后进入下一步,抓包后将问题答案的整个字段都
删除再提交,如图15-36所示。
图15-36 抓包截图
步骤三:因服务端验证逻辑存在缺陷,无法获取到问题答案的情况下直接通过了验
证,密码重置成功,如图15-37所示。
图15-37 密码修改成功
15.6.2 邮箱地址可被操控
步骤一:某网站可以通过注册时填写的邮箱来找回密码,但为防止网络不稳定等因素
导致邮件发送失败,找回密码页面提供了“重新发送邮件”的功能,如图15-38所示。
图15-38 重新发送邮件
步骤二:单击重新发送邮件,然后抓包拦截请求,将数据包中的邮箱地址改为自己的
测试邮箱,如图15-39所示。
图15-39 抓包截图
步骤三:进入自己的测试邮箱,单击收到的链接,密码重置成功,如图 15-40所示。
图15-40 修改密码成功
15.6.3 身份验证步骤可被绕过
步骤一:进入某网站的密码找回功能,输入账号和验证码,如图15-41所示。
步骤二:确定后,直接访问 http://**.***.com.cn/reset/pass.do 即可跳过选择找回方式
和身份验证的步骤,直接进入重置密码界面,如图15-42所示。
图15-41 密码找回界面
图15-42 重置密码界面
步骤三:最终成功修改密码并登录到个人中心,如图15-43所示。
图15-43 登录成功
15.7 在本地验证服务端的返回信息——修改返回包绕过验证
有些信息系统在密码找回功能的设计上存在逻辑漏洞,攻击者只需要抓取服务端的返
回包并修改其中的部分参数即可跳过验证步骤,直接进入密码重置界面。
修改返回包绕过验证案例如下。
步骤一:进入某电商网站,单击忘记密码,输入用户名admin后选择手机找回,单击
发送验证码,然后随便填写一个验证码,单击下一步按钮,如图15-44所示。
图15-44 验证手机
步骤二:此时抓包并拦截返回的数据包。经过测试,将返回码改成 200 即可绕过验证
逻辑,如图15-45所示。
图15-45 修改返回包
步骤三:直接跳转到了重置密码页面,如图15-46所示。
图15-46 重置密码页面
15.8 注册覆盖——已存在用户可被重复注册
有些信息系统的用户注册功能没有严格校验已存在的用户账号,导致攻击者可以通过
重复注册其他用户账号的方式重置他人密码。
已存在用户可被重复注册案例如下。
步骤一:进入某快递网站,单击用户注册,输入用户名admin,在鼠标离开输入框后
会提示该账号已注册,如图15-47所示。
图15-47 注册界面
步骤二:输入一个未注册的用户名并提交表单,同时用抓包工具截取数据包并将
username修改为admin,如图15-48所示。
图15-48 抓包并修改用户名
步骤三:此时 admin 用户的密码被重复注册的方式修改了,但原用户的所有信息却没
有改变,也就是说这时候攻击者获取了用户的信息,包括姓名、身份证、手机号等。
15.9 Session覆盖——某电商网站可通过Session覆盖方式重置他人密码
有些服务器密码找回功能的服务端校验存在漏洞,攻击者使用密码找回链接重置密码
时可以通过Session覆盖的方式成功重置其他用户的密码。
某电商网站可通过Session覆盖方式重置他人密码案例如下。步骤一:使用自己的账
号进行密码找回,如图15-49所示。
图15-49 密码找回
步骤二:收到邮件后先不要打开链接,如图15-50所示。
图15-50 收到邮件
步骤三:在同一浏览器内打开网站再次进入密码找回页面,输入其他人的账号,如图
15-51所示。
图15-51 其他用户的身份验证界面
步骤四:单击发送“找回密码邮件”后停在该页面,如图15-52所示。
图15-52 发送邮件成功
步骤五:在同一浏览器中打开第二步中自己邮箱中收到的链接,然后设置一个新密
码,如图15-53所示。
图15-53 密码设置界面
步骤六:使用新设置的密码,成功登录进了其他人的账户,如图15-54所示。
图15-54 登录成功
15.10 防范密码找回漏洞的相关手段
(1)在密码找回功能设计时对用户凭证的验证次数和频率进行限制,防止攻击者对
用户凭证的暴力枚举攻击。
(2)对密码找回的各个环节进行梳理,记录分析所有交互数据,避免密码找回凭证
等敏感信息直接返回给客户端。
(3)对服务端密码重置Token的生成算法进行审计,避免使用容易被攻击者破解的
简单算法。
(4)密码重置凭证应与账户严格绑定,并设置有效时间,避免攻击者通过修改账户
ID的方式重置他人密码。
(5)对客户端传入的数据要进行严格的校验,手机号、邮箱地址等重要信息应和后
台数据库中已存储的信息进行核对,不应从客户端传入的参数中直接取用。避免攻击者通
过篡改传入数据的方式重置他人密码。
(6)对用户注册、手机邮箱绑定等业务逻辑进行审计,避免攻击者通过用户重复注
册和越权绑定等漏洞间接重置他人密码。
第16章 越权访问安全案例总结
16.1 平行越权
攻击者请求操作(增、删、查、改)某条数据时,Web 应用程序没有判断该数据的
所属人,或者在判断数据所属人时直接从用户提交的表单参数中获取(如用户ID),导
致攻击者可以自行修改参数(用户ID),操作不属于自己的数据,如图16-1所示。
图16-1 平行越权流程图
16.1.1 某高校教务系统用户可越权查看其他用户个人信息
某高校教务系统存在平行越权漏洞。通过测试发现,学号有规律可循,学号后4位是
连续的数字,普通用户登录系统后可越权查看其他学生的学籍信息、课程成绩等敏感信
息。
步骤一:以“高某某”学号为12xxxx0031为例,登录教务系统,并查看该账号的学籍信
息。查看学籍信息链接为
http://host/search.do?m=xsx&xh=12Sxxx0031,如图16-2所
示。
图16-2 查看学号为12xxxx0031的学生的学籍信息
步骤二:访问学号为 12Sxxx0032 的学生的学籍信息,链接为 http://host/search.do?
m=xsx&xh=12Sxxx0032,如图16-3所示。
图16-3 越权查看其他学号(12xxxx0032)的学籍信息
步骤三:访问学号为 12Sxxx0033 的学生的学籍信息,链接为 http://host/search.do?
m=xsx&xh=12Sxxx0033,如图16-4所示。
图16-4 越权查看学号12xxxx0033的学籍信息
16.1.2 某电商网站用户可越权查看或修改其他用户信息
某电商网站存在越权漏洞可任意进行读取或删除其他用户收货地址、订单信息等操
作。
步骤一:注册账号并登录,当前用户名为 april,UserID 为 460,添加收货地址并查
看“我的地址簿”,如图16-5所示。
图16-5 查看UserID为460的地址簿
步骤二:使用Burp Suite抓包,修改cookie中的UserID为460,提交后服务器返回地址
信息,如图16-6所示。
图16-6 越权查看UserID为460的地址信息
步骤三:修改cookie中的UserID为360,提交后服务器返回地址信息,如图16-7所示。
图16-7 越权查看UserID为360的地址信息
步骤四:在前台下单并提交后,单击查看“我的订单”,如图16-8所示。
图16-8 单击“我的订单”查看订单详细信息
同时使用Burp Suite抓包发现用户ID为460,其订单详细信息如图16-9所示。
图16-9 使用Burp Suit查看当前UserID(460)订单信息
步骤五:修改cookie中的UserID为360,提交后服务器返回的订单信息如图16-10所
示。
图16-10 越权查看UserID为360的订单信息
16.1.3 某手机APP普通用户可越权查看其他用户个人信息
某手机APP查看“个人信息”功能存在平行越权漏洞,可越权查看其他用户个人信息。
步骤一:注册用户并登录后单击“系统设置→个人信息”处查看个人信息,如图16-11
所示。
图16-11 查看当前个人用户信息
步骤二:使用Burp Suite抓包并修改studentId为188750,提交后服务器返回的其他用
户信息如图16-12所示。
图16-12 越权查看studentId为188750的用户信息
步骤三:修改studentId为138850,提交后服务器返回的其他用户信息如图16-13所
示。
图16-13 越权查看studentId为138850的用户信息
16.2 纵向越权
16.2.1 某办公系统普通用户权限越权提升为系统权限
服务器为鉴别客户端浏览器会话及身份信息,会将用户身份信息存储在 Cookie中,
并发送至客户端存储。攻击者通过尝试修改Cookie中的身份标识为管理员,欺骗服务器分
配管理员权限,达到垂直越权的目的,如图16-14所示。
某办公系统存在纵向越权漏洞,通过修改Cookie可直接提升普通用户权限为系统权
限。
图16-14 纵向越权流程图
步骤一:使用普通权限账号a02登录办公系统,成功登录后访问链接
http://host/aaa/bbb/editUser.asp?iD=2,尝试修改权限。
由于普通用户无法访问修改权限模块,系统会跳转到NoPower页面提示用户无操作权
限,如图16-15所示。
图16-15 a02用户没有权限访问该模块
步骤二:使用Burp Suite修改Cookie中的Tname参数为admin,欺骗服务器该请求为系
统管理员发出的,成功提升账号a02为系统管理员权限,如图16-16所示。
图16-16 将a02用户Cookie中的Tname修改为admin
步骤三:再次访问权限修改modifyuser页面http://host/aaa/bbb/editUser.asp?iD=2,
如图16-17所示可成功访问。
图16-17 a02账号权限提升成功
16.2.2 某中学网站管理后台可越权添加管理员账号
攻击者通过删除服务器响应数据包中的跳转JS代码,未经身份验证直接进入后台“添
加用户”页面。然后利用Cookie先后添加普通用户A与B,虽然A与B不能直接修改自己的
权限,但A与B可相互修改对方的权限,因此攻击者利用A将B的权限修改为管理员权限,
并以 B 的身份登录后台,最终实现垂直越权获得管理员权限,如图16-18所示。
图16-18 纵向越权流程图
某学校网站管理后台存在越权漏洞,可以越权添加管理员账号。
步骤一:访问登录页面,尝试登录,如图16-19所示。
图16-19 身份认证未通过
访问 http://www.xxx.com/WEB/ABC/addUser.aspx 可直接打开添加用户页面,如图
16-20所示。
图16-20 未授权访问新增用户模块
添加账号test,密码123456,添加完用户返回首页登录,如图16-21所示。
图16-21 使用新添加的用户登录系统
步骤二:登录成功后,提示没有分配管理权限,然后会强制退出管理系统,如图16-
22所示。
图16-22 test用户没有被管理员分配权限
但此时会生成一个Cookie,如图16-23所示。
图16-23 查看test用户的Cookie
步骤三:使用该Cookie访问http://www.xxx.com/WEB/ABC/userList.aspx,可直接打
开分配权限的页面。其中test用户不能修改自己的权限,但可以修改其他用户的权限。再
添加一个新用户test2,两者可以互相添加权限,如图16-24所示。
图16-24 新增另一用户test2
步骤四:使用test账号修改test2账号的权限为管理员权限,如图16-25所示。
图16-25 修改test2用户为管理员权限
步骤五:使用test2账号重新登录,成功进入管理后台,如图16-26所示。
图16-26 test2用户成功登录管理员后台
16.2.3 某智能机顶盒低权限用户可越权修改超级管理员配置信息
攻击者以普通管理员身份登录后台,通过搜集信息获得管理员请求数据包进行重放,
越权修改超级管理员模块的设置,如图16-27所示。
图16-27 纵向越权流程图
某智能机顶盒设备在后台管理上存在越权漏洞,在同一网络中的任意用户可以利用受
影响的页面,越权修改超级管理员的设备配置信息。
步骤一:使用超级管理员登录,配置 user 密码。智能机顶盒设备的超级管理员的账
户名和密码为 chinanet/123456,登录后查看该机顶盒的设备信息,如图 16-28所示。
图16-28 超级管理员登录系统后台
使用超级管理员登录后,在“管理”模块下的“用户管理”中配置 user 用户的密码,如图
16-29所示。
图16-29 user用户密码配置
步骤二:使用超级管理员配置proxy代理地址,通过超级管理员在“应用”模块下
的“proxy代理”中配置,然后获取相关的测试链接和参数,设置的值如图16-30所示。
图16-30 proxy代理配置
步骤三:通过这次的简单配置后,使用抓包软件进行抓取提交的链接和参数,如图
16-31所示。
图16-31 修改proxy代理的数据包
步骤四:退出超级管理员,清除浏览器的Cookie信息,使用user账号登录操作。与超
级管理员相比,user用户在“应用”模块中只有简单的“日常应用”一项权限,并没有其他的
权限,如图16-32所示。
图16-32 user用户应用信息
步骤五:利用 user 用户的权限来进行配置以前没有权限配置的 proxy 代理的地址信
息,直接使用hackbar工具通过POST方式提交数据,如图16-33所示。
图16-33 user用户越权提交数据
通过抓取的数据包可以看出,使用的是 user 用户权限进行提交的,如图 16-34所示。
图16-34 user用户越权提交的数据包信息
步骤六:再次使用超级管理员chinanet账户登录,单击进入“proxy代理”的配置,此时
内容已经发生改变了,如图16-35所示。
图16-35 越权提交数据的结果
16.2.4 某Web防火墙通过修改用户对应菜单类别可提升权限
攻击者以低权限身份请求登录系统,系统根据category参数的值(system.audit)分配
权限。攻击者修改category值为system.admin,系统根据category值重新分配权限为超级管
理员,如图16-36所示。
图16-36 纵向越权流程图
该系统程序对用户权限的控制是限制菜单及功能模块的访问,可以通过修改用户对应
的菜单类别的方式来改变用户身份欺骗系统,以达到访问其他权限模块的目的。
步骤一:以 audit 用户身份登录系统,使用 Burp Suite 抓包 category 的值system.audit 修改为system.admin,如图16-37所示。
图16-37 修改category参数的值为system.admin
步骤二:category值修改以后,单击Forward,进入管理员管理界面,如图16-38所
示。
图16-38 audit提升为system.admin权限
步骤三:将useradmin账户权限设置为最大,如图16-39所示。
图16-39 将useradmin修改为最大权限
步骤四:使用useradmin账户登录系统,useradmin拥有管理员权限,如图16-40所示。
图16-79 登录useradmin账户
16.3 防范越权访问漏洞的相关手段
实现应用程序的完善的访问控制不是件容易的事,越权漏洞防不胜防,本章从越权漏
洞相关案例给出以下几点建议:
(1)对于开发者而言,一定要有安全意识,时刻保持警惕。
(2)永远不要相信来自客户端(用户)的输入,对于可控参数进行严格的检查与过
滤。
(3)执行关键操作前必须验证用户身份,多阶段功能的每一步都要验证用户身份。
(4)对于直接对象引用,加密资源ID,以防止攻击者对ID进行枚举。
(5)在前端实现的验证并不可靠,前端可以验证用户的输入是否合规,要在服务端
对请求的数据和当前用户身份做校验。检查提交CRUD请求的操作者(Session)与目标对
象的权限所有者(查数据库)是否一致,如果不一致则阻断。
(6)在调用功能之前,验证当前用户身份是否有权限调用相关功能(推荐使用过滤
器,进行统一权限验证)。
(7)把属主、权限、对象、操作的场景抽象成一个统一的框架,在框架内统一实现
权限的管理和检查。
第17章 OAuth 2.0安全案例总结
17.1 OAuth2.0认证原理
Oauth 允许用户让第三方应用访问该用户在某一网站上存储的私密资源(如照片、视
频、联系人列表),而无须将用户名和密码提供给第三方应用的协议。
OAuth 2.0 认证流程如图 17-1 所示。原理很简单,用户访问 App,App 访问
Authorization Server请求权限,Authorization Server得到用户同意后,返回Token,App通
过这个Token向Authorization Server索要数据,App只能从Authorization Server获取服务器
数据,而无法直接访问Resource Server。下面用Facebook的Oath2.0登录过程作为举例。
步骤一:App向Oauth Server请求的URL里面带着该App的id、key、请求的类型、返回
一串的access_token和事件类型code。
https://facebook.com/dialog/oauth?
response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=REDIRECT_URI&scope=email 步骤二:回调,跳转到权限确认页面等待用户确认授权。
https://facebook.com/dialog/oauth?
response_type=code&client_id=28653682475872&redirect_uri=example.com&scope=email 该页面通过redirect_uri,回调到指定的callback页面。
图17-1 OAuth 2.0认证流程图
步骤三:利用返回的access_token,将App的id、key以及code代码发包到POST
https://graph.facebook.com/oauth/access_token。
这一步是为了获取Token。
步骤四:Oauth Server返回Token,这时,就可以通过Token获取用户授权的资源了。
资料参考:
· http://oauth.net/2/
· https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
17.2 OAuth2.0漏洞总结
17.2.1 某社交网站CSRF漏洞导致绑定劫持
某社交网站-百度 OAuth 2.0 认证流程中,没有提供有效的方式来抵抗针对redirect_uir 的CSRF攻击。如果攻击成功,攻击者不需要知道受害用户的账号和密码就可登录受害账
号。
某社交网站-百度
OAuth
2.0
认证流程中链接为
https://openapi.baidu.com/oauth/2.0/authorize?
response_type=code&client_id=foRRWjPq8In3SIhmKQw1Pep3&redirect_uri=http://www.xxxx.com/bind/baidu/baiduLoginCallBack。
某社交网站并没有加入state参数来抵抗针对redirect_uir的CSRF攻击。如果攻击者重新
发起一个某社交网站百度OAuth
2.0认证请求,并截获OAuth
2.0认证请求的返回:
http://www.xxxx.com/bind/baidu/baiduLoginCallBack?code=f056147c661d0b9
fbb6cd305567cb994。
攻击者诱骗已经登录的某社交网站用户单击立即绑定(比如通过邮件或者
QQ等方
式),如图17-2所示,网站会自动将用户的账号同攻击者的账号绑定到一起,如图17-3所
示。
图17-2 某社交网站-百度账号绑定
图17-3 百度账号绑定成功
修复建议:OAuth 2.0提供了state参数用于CSRF认证服务器将接收到的state参数按原
样返回给redirect_uri,客户端收到该参数并验证与之前生成的值是否一致。除此方法外也
可使用传统的CSRF防御方案。
17.2.2 某社区劫持授权
以某社区账号登录“微博通”应用的授权页面为例,如图17-4所示。
图17-4 授权页面
http://open.xxxx.cn/oauth/authorize.php?oauth_token=e65d28ab0862cbd517c67c3cc 6f2247e052ad9c22&oauth_callback=http%3A%2F%2Fm.wbto.cn%3A80%2F%3Fc%3D
m_setting%26m%3Dauth%26b%3Dcallback%26pid%3D24%26aid%3D%26wbto%3D16
58628_953c148f2d%26oauth_token%3De65d28ab0862cbd517c67c3cc6f2247e052ad9c22%26oauth_token_secret%3D2fde10390cd1a2477abaa3dcd44e4b99
其中,oauth_callback没有与应用的oauth_token进行绑定,没有对可用性进行校验,可
以修改为任意地址。这里我们把oauth_callback的值改为xxx.org,并没有提示uri 非法。登
录并授权,跳转到了指定的地址,用户的 oauth_token 泄露,如图 17-5所示。
图17-5 跳转到xxx.org
修复建议:请遵循OAuth协议规范,将应用的oauth_token与oauth_callback绑定,对
oauth_callback进行有效性校验。
17.3 防范OAuth2.0漏洞的相关手段
关于防范OAuth2.0漏洞的安全建议如下。
(1)绑定劫持安全建议
OAuth 2.0提供了state参数用于防御CSRF。认证服务器接收到的state参数按原样返回
给redirect_uri,客户端收到该参数并验证与之前生成的值是否一致。
(2)授权劫持安全建议
用户授权凭证会由服务器转发到 redirect_uri 对应的地址,如果攻击者伪造redirect_uri 为自己的地址,然后诱导用户发送该请求,之后获取的凭证就会发送给攻击者伪造的回调
地址。攻击者使用该凭证即可登录用户账号,造成授权劫持。正常情况下,为了防止该情
况出现,认证服务器会验证自己的 client_id 与回调地址是否对应。常见的方法是验证回调
第18章 在线支付安全案例总结
目前网络在线消费和支付,已遍布人们生活的衣食住行等各个方面,比如网上商城在
线购物、水电燃气在线缴费、手机话费在线充值等。由于在线消费和支付过程中涉及真金
白银,一旦存在漏洞,将会带来重大的经济损失。
18.1 某快餐连锁店官网订单金额篡改
篡改订单金额的流程如图18-1所示。
图18-1 篡改订单金额流程
步骤一:登录某快餐连锁官网,选择快餐后,显示要支付的金额46元,在Chrome浏
览器中,按 F12 快捷键,在浏览器下方弹出开发者工具,选择最左侧的箭头,如图18-2所
示。
图18-2 调用开发者工具
步骤二:单击已输入金额46元的地方,可以看到该处HTML代码如图18-3所示。
图18-3 查看金额部分HTML代码
步骤三:把金额46元修改为0.01元,如图18-4所示。
图18-4 修改快餐实际金额
步骤四:调用支付宝接口,可以用0.01元购买价值46元的快餐,如图18-5所示。
图18-5 通过支付宝进行支付
18.2 某网上商城订单数量篡改
篡改订单数量的流程如图18-6所示。
图18-6 篡改订单数量流程图
步骤一:在某网上商城购买商品,在购物车中填入购买数量时,可以填入负数,如图
18-7所示。
图18-7 将物品一的数量修改为负数
步骤二:通过填入负数,服务器端会进行数量相加,运算过程及结果是-1*55+1*59=4
元,因此造成支付漏洞,如图18-8所示。
图18-8 最终支付金额
18.3 某服务器供应商平台订单请求重放测试
订单请求重放测试流程如图18-9所示。
步骤一:在某服务器供应商平台上购买服务器资源,购买时通过抓包并进行多次重放
测试,有90%的概率发生购买服务器价格为0元的情况,订单如图18-10所示。
图18-9 订单请求重放测试流程图
图18-10 购买订单
步骤二:服务器可以进行管理和运行,如图18-11所示。
图18-11 购买后的服务器运行状态
18.4 某培训机构官网订单其他参数干扰测试
订单其他参数干扰测试流程如图18-12所示。
图18-12 订单其他参数干扰测试流程
步骤一:在某培训机构官网上进行课程报名,同时利用抓包工具抓包,直接修改金额
发现无法修改成功,因为该参数是直接和schoolid绑定的。
通过观察和测试发现,订单中的配送方式参数可以利用,且运费金额可以修改,但该
参数的数值在服务器端会有验证,课程费用和配送运费不能低于0,否则订单无法成功提
交。
步骤二:接下来重新选择一门课程,课程的价格是1700元,同时将运费修改为-1699
元,两者相加最终费用为1元,如图18-13所示。
图18-13 抓包并修改运费
步骤三:订单成功提交,提示应付金额为1元,如图18-14所示。
图18-14 订单成功提交提示
步骤四:可以在历史订单里发现,该订单已提交成功,只需付款1元即可生效,如图
18-15所示。
图18-15 成功提交的订单历史截图
18.5 防范在线支付漏洞的相关手段
在线支付对广大消费者和商家来说日益重要,稍有不慎就会给商家带来经济损失,为
了减少或者避免在线支付环节中的业务安全问题,希望商家采取以下措施进行预防。
(1)针对订单金额篡改的预防措施
将订单中的商品价格封装为码表形式,即每个商品拥有一个ID,每个ID对应一条相
应的价格。用户访问前台选择商品并提交,服务器端验证商品 ID,然后计算商品总额并
生成订单。
(2)针对订单数量篡改的预防措施
· 在服务器端判断提交商品ID中数量参数值不低于0,如果数量参数值低于0,则直接
提示错误信息,让客户修正。
· 通过数据类型判断正确后,同时判断商城库存对应商品的剩余量,如果剩余量低于
商品的购买数量,则直接提示错误信息,让客户修正。
(3)针对订单请求重放测试的预防措施
无论支付成功还是失败时,使用的订单编号必须唯一,并且永久记录订单编号,不允
许二次使用。
(4)针对其他参数(如运费)干扰测试的预防措施
在服务器端判断订单中运费参数值不低于0,如运费参数值低于0,则直接提示错误信
息,让客户修正。