业务逻辑漏洞分类
2020-04-27 11:02:02 6 举报
AI智能生成
业务逻辑漏洞的分类
作者其他创作
大纲/内容
业务办理模块
订单ID篡改测试
测试方法:对于一些购买东西的功能,当到订单详情页时,可以刷新页面拦截包,发送到 Repeater,修改其中的 id 订单号,看是否会返回对应的订单信息,如正常返回则存在此问题。
修复方法:在后台查看订单时要通过 Session 机制去判断用户身份,服务端要去校验相应订单和登录者的身份是否一致,如果不一致则应该拒绝请求,防止出现水平越权泄露个人隐私信息。
手机号码篡改测试
测试方法:对于一些登录后才可以使用的功能,发送请求时,可以拦截包观察其参数,如果其中包含手机号,可以尝试替换成另一个号码,查看返回结果是否有变化,如果有变化则存在此问题。
修复方法:后台要通过 Session 的机制来判断用户身份,如果其中有手机号参数时,应该在服务器端判断用户的身份信息和手机号是否一致,从而防止水平越权的问题发生。
用户ID篡改测试
测试方法:很多业务请求中都会有 UserID 参数,而后台判断其身份时也会根据这个参数来做判断,如果碰到类似参数,可尝试修改其值为另一个账号,如果系统返回了相应的信息,则存在此问题。
修复方法:后台要通过 Session 的机制来判断用户的身份,当程序逻辑需要用到 ID 号时,要在服务器判断传过来的 ID 是否和当前用户的 ID 一致,防止其产生越权问题。
邮箱和用户篡改测试
测试方法:例如有一个发邮件功能,当写好邮件内容,填好收件人后,发送时拦包修改其发件人的邮箱地址,可以成功发送。然后收件人收到的邮件也会成功显示刚才修改发件人的名,则就存在此问题。
修复方法:后台通过 Session 判断用户的身份,如果在传输的过程中需要用到类似上例中的邮箱参数,则需要在服务器端判断传过来的邮箱和当前登录的用户是否一致,避免问题的发生。
商品编号篡改测试
测试方法:在一些商城中,购买商品时在生成订单页时或者是支付时,抓包可以修改其支付的金额,或者是修改其商品的 id,实现低价买高价商品,1 分钱买商品等情况,则确定存在此问题。
修复建议:对于商品的金额,不建议从客户端传入,防止被篡改。如果必须从客户端传入,则应在服务端接收后检查商品价格和交易金额是否一致。也可以对支付的金额做一个签名校验,不一致时则组织该交易。
竞争条件测试
测试方法:拦截请求,发送到 Intruder,把线程设置多点,比如所 100,然后开始跑,随后对比数据,看是否有异常。
修复方法:在处理订单、支付等业务时,使用悲观锁或乐观锁保证事务的 ACID 特性(原子性、一致性、隔离性、持久性),并避免数据脏读(一个事务读取了另一个事务未提交的数据)。
输入/输出模块
Sql注入
测试方法:如果是登录前的连接可以直接用 sqlmap -u 去跑,如果是登录后才能访问的连接,用 burp 拦截包,复制到 sqlmap 目录下随便一个 txt 文件,直接用 sqlmap -r 去跑。也可以直接使用 burp 的插件 sqlipy 直接去跑,更方便
修复方法:过滤参数中的特殊字符,或对字符进行转义。现在基本上项目都用框架来写,需要参数化。框架机制虽越来越完善,但不能排除此问题,没以前多了,但依然不少。
XSS
测试方法:反射类型一般搜索功能出现的比较多,存储型的一般新增内容编辑内容中出现的比较多,测试的时候输入一小段 js 代码来验证是否会执行,以确定是否存在此问题。
修复方法:过滤特殊符号,实体化特殊符号,过滤 js 关键字。另外建议对敏感信息设置 httponly 属性,防止 xss 攻击窃取 cookie 内容,反射类型时,尽量不要把信息回显到页面。
命令执行
测试方法:如果有类似接收命令到服务端执行的功能,则可以测试此问题,例如 url 中的某个参数接收命令,可以直接输入命令,看服务器是否有返回信息,或将执行结果重定向到一个文件中,查看此文件。
修复方法:过滤特殊符号,避免造成命令连接。对于可接收的命令,罗列白名单。
验证码机制
验证码暴力破解测试
测试方法:只要是有接收验证码的功能都可以测试,发送到任意一个手机号,随便输入验证码,拦截包发送到 intrude,只给验证码加 $,直接使用 burte forcer 把爆破字符设置成 0-9,爆破后根据长度排序即可。
修复方法:设置验证码的失效时间,建议为 180 秒。同时限制单位时间内验证码失败的尝试次数,例如 5 分钟内连续失败 5 次即锁定账号半小时。
验证码重复使用测试
测试方法:一个提交请求带验证码的功能,输入正确验证码后拦截请求到 repeater,不修改验证码,修改其他参数信息,看是否可以重复提交,如果重复提交成功,则存在此问题。发生此问题的原因是验证码认证成功后没有将 session 及时清空,这会导致验证码首次认证成功后可重复使用。
修复方法:建议验证码认证成功后,服务端清空认证成功的 session,防止有效验证码重复使用。
验证码客户端回显测试
测试方法:例如找回密码功能,输入手机号和相关信息后,服务器给手机号发送短信,这时候可以通过 f12 查看 response 返回的信息中是否包含验证码,如果包含则存在此问题。造成此问题的原因是验证码在客户端生成的而非服务端。
修复方法:建议就是不要在客户端生成,要在服务端生成。同时设置其时效性,例如 180 秒,随机生成且一次有效。
验证码绕过测试
测试方法:例如一个注册功能,输入一个牛点的手机号,随便输入一个验证码,发送给服务器,然后拦截服务器返回的信息,在 forward 前右键选择 Do intercept 下的 Response to this request,然后再放行,这时服务器会返回响应信息,一般会有状态码,例如 0 代表成功,1 代表失败,把返回的结果码改成 0,再放行,成功注册则存在此问题。
修复方法:建议在服务端进行验证码校验时,对客户端提交的验证码进行二次校验。
验证码识别测试
测试方法:直接拿工具识别就行,可以用 pkav http fuzzer,这个一般个人感觉没有测试的必要,在测试的过程中,可以让其加固的时候设置下登录失败的次数等策略,验证码可以不加。
修复方法:单对验证码可识别的情况,修复时,可以增加背景的干扰,例如背景色、背景字幕等。字符的字体进行扭曲,粘连,也可以使用公式、逻辑验证方法等作为验证码,也可以使用选择联系人头像、购买过的物品为验证码。
业务流程乱序
测试方法:流程乱序测试也就是绕过正常的业务流程测试,例如一个注册功能,第一填写注册的手机号并发送验证码,第二步输入验证码,第三注册成功。乱序测试的话,可以拦截第三步的数据包,将其注册的信息例如手机号,替换成他人的,如果注册成功,则存在乱序的问题。 再例如,一个充值的功能,在拦截包的过程中发现充值成功后会有一个充值成功的连接,例如是 xxx.com/index.php?controller=site&action=payok&out_trade_no=aaaa,其中 aaa 是充值订单号。接下来注册一个新账号进行充值,在支付产生订单时复制其订单号然后取消支付,把订单号贴到充值成功后的连接中充值成功,则存在乱序问题。
修复方法:首先建议对敏感信息进行加密处理,例如身份 id、账号密码、订单号、金额等。其次,建议在服务器端对其信息进行二次校验,避免修改乱序等情况。
业务接口调用
接口调用重放测试
测试方法:接口调用重放测试可以理解成重放测试,接口也就是数据请求,功能很多,例如发布文章,发布评论,下订单,也可以理解成只要请求有新的数据生成,能重复请求并成功,都可以算请求重放,也就是接口重放测试。
修复方法:对生成订单缓解可以使用验证码,防止生成数据的业务被恶意调用。或是每一个请求有唯一的一个 token,请求提交后,token 失效这样。也可以参考微信的做法,在参数中添加 timestamp 和 nonce,并对其进行签名加密。
接口调用遍历测试
测试方法:例如有一个功能,是浏览商品的历史记录。把其用户的浏览历史记录 url 发送到 intruder,遍历其用户的 id,看返回 response 信息中是否有正常返回的,且是其他用户的,则证明存在接口遍历问题。
修复方法:在 session 中存储当前用户的凭证或者 id,只有传入凭证或者 id 参数值与 session 中的一致再返回数据内容。
接口调用参数篡改测试
测试方法:例如在一些短信验证码、邮件验证码等功能业务中,比如修改其他用户密码,发送后,再次点击重新发送,拦截其请求,修改为自己的账号,如果自己收到了验证码,则存在此问题。
修复方法:会话 session 中存储重要的凭证,在忘记密码、重新发送验证码等业务中,从 session 获取用户凭证而不是从客户请求的参数中获取。从客户端处获取手机号、邮箱等账号信息,要与 session 中的凭证进行对比,验证通过后才允许进行业务操作。
接口未授权访问
测试方法:只要是登录后才可以返回相关信息的接口,在未登录状态下也可以返回的,就是未授权访问。在一般的网站测试中,可以 http history 中选择网站的根目录地址,然后右键 spider from here 进行爬去相关的 url,然后在 target 栏下的 site map 中利用 mime type 进行筛选,主要关注一下 json、script、xml 等这些类型,然后把 url 贴到浏览器中看是否能访问来验证。
修复方法:利用 token 校验的方式,在 url 中添加一个 token 参数,只有 token 验证通过才返回接口数据且 token 使用一次后失效。在接口被调用时,后端对会话状态进行验证,如果已经登录,便返回接口数据,如果未登录,则返回自定义的错误信息。
callback自定义测试
测试方法:因为同源策略,很多网站都会使用 JSONP,而 JSONP 一般会使用 callback 回掉函数,如果这个函数没有做相关的措施,可以随意传入 js 代码并执行则存在此问题。
修复方法:首先可以定义下 content-type 为 json 格式,content=application/json。其次建立 callback 函数白名单,如果传入的函数不是白名单内的,则组织并转到异常页。最后可以对 callback 参数进行 html 实体编码来过滤掉一些特殊字符。
webservice测试
登录认证模块
暴力破解测试
测试方法:例如登录,输入账号密码,burp 拦截包发送到 Intruder,把系统变量的 $ 符 clear 掉,给密码加上 add,加载上密码字典,根据返回的长度或者 response 的信息来判断正确密码。
修复方法:一、增加验证码,登录失败的时候,变换验证码。(登录失败,验证码不变不算。验证码工具可识别不算。)二、限制登录频率,例如,5 分钟内登录失败次数超过 10 次则锁定账号 1 小时。三、可以添加手机验证码或邮箱验证码,实现双重验证。
本地加密传输测试
测试方法:输入账号密码登录,拦包,查看包信息,如果账号密码明文传输则存在此问题。
修复方法:服务器使用 SSL 证书服务。
Session会话固定测试
测试方法:登录账号成功后记录下 SessionID 的值,然后退出系统,再次登录,如果第二次的 SessionID 值和第一次的相同,则存在此问题。
修复方法:用户退出系统时销毁其 SessionID,客户端登录时重新生成 SessionID。
Sessin会话注销测试
测试方法:用账号密码登录系统,记录其 SessionID 的值,随便拦截一个登录后才可以发送成功的请求,发送到 repeater,然后退出系统,在 repeater 栏 go 一下,如果服务器正常返回信息则存在此问题。
修复方法:用户退出系统后,服务器及时销毁 Session 认证会话,并清空浏览器的 Session 属性标识。
Session会话超时测试
测试方法:用账号密码登录系统,随便拦截一个登陆后才可以发送成功的请求,发送到 repeater,这时候不要和服务器有任何交互,停一段时间,再回来 go 一下,如果服务器正常返回相关信息,则存在此问题。
修复方法:系统要配置会话的生命周期,建议时间是 30 分钟,一般的业务系统 30 分钟即可,以此来降低会话认证时间过长而导致的信息泄露风险。
Cookie仿冒测试
测试方法:使用一个账号登录,找一个可以证明身份的页面,例如首页的欢迎 xxx 或者是个人中心显示昵称的地方,刷新该页面拦截请求,观察 Cookie 中的字段和值,例如 userid=xxx,把 xxx 改成 admin,forword 放行,页面显示 admin 的信息,则存在此问题。
修复方法:对于客户端标识的用户信息,使用 Session 会话认证方式,避免通过 Cookie 去仿冒其他人的身份。
密文对比认证测试
一般情况下网站输入用户名和密码后,传到后台会对其进行加密,随后和数据库里面的值做对比,以此来判断用户名和密码是否正确。但有些网站不是这么做的,他们会在前端做好加密,然后传到后台直接和数据库里面的值做对比,这时候问题就出现了,截包你可以知道它的加密方式,依然可以去做暴力破解。
测试方法:用账号密码登录,拦截请求,查看传输信息,是不是通过一些加密方式对账号和密码进行了加密,如果有则存在此问题。
测试方法:用账号密码登录,拦截请求,查看传输信息,是不是通过一些加密方式对账号和密码进行了加密,如果有则存在此问题。
修复方法:把这个加密对比的方法放到后台去执行。
登录失败信息测试
测试方法:不填账号和密码直接点登录,填入账号不填密码点登录,填入密码不填账号点登录,填入错误的账号不填密码点登录,填入错误的密码不填账号点登录,填入错误的账号和密码点登录,根据提示来判断,如果单提示账号错误,或者单提示密码错误,则存在此问题。
修复方法:使用模糊的提示方法,例如账号或密码错误。
业务授权访问模块
未授权访问
测试方法:访问一个地址,且这个地址是需要认证身份后才可以访问的,随后把这个地址复制到其他浏览器,若能成功访问,则存在此问题。
修复方法:对于未授权访问的页面做 session 认证,并对每一个 url 做身份鉴别,正确校验用户 id 和 token。
越权测试
水平越权
测试方法:在测水平越权时,通常会拦截一些包然后查看能证明身份的东西,例如 id 为 1,这时候改为 2 就会返回 2 的内容,则可以证明存在水平越权。
修复方法:服务端校验身份唯一性。
垂直越权
测试方法:在测试垂直越权时,通常是普通用户登录后,查看一些功能时把能证明身份的东西进行修改,例如 user 为 test,这时候改为 admin,如果成功返回管理员的相关信息,则存在垂直越权。
修复方法:服务端校验身份唯一性。
回退模块
测试过程:回退测试字面理解就是退一步的意思。例如一些修改密码的操作或者是付款成功后等业务模块,操作完成后返回上一步,如果可以正常的再次操作,则存在此问题。
修复方法:对于存在此问题的业务,且是多步骤操作的,建议判断其请求是否是上一个步骤所发起的,如果不是则返回错误提示或页面失效。单步骤建议也判断其请求是否是从规定的 url 连接上发起的。
业务数据安全
商品支付金额篡改测试
测试方法:在一些电商系统或是支付购买商品功能处,生成订单后去支付时,拦截其请求,看支付金额是否可以修改,修改后提交至服务区器,如果成功返回,且存在此问题。
修复方法:对于一些支付类的信息,不能在前端控制,其校验信息应该由后端来完成。
商品订单数据篡改测试
测试方法:这个和商品支付金额负数,提交后弱服务器成功返回,则存在此问题。
修复方法:后端应该对其风险进行控制,对异常的交易行为进行限制和阻断,其异常行为例如积分为负、交易商品数量为负、交易商品数量和金额不符,商品数量为 0 等。
前端JS绕过测试
测试方法:例如一个促销活动购买商品的功能,其商品有购买数量限制,比如没人限购 1 份,这时输入 1 发送请求,拦截数据包修改其值,修改为多份时,如果成功提交,则存在此问题。
修复方法:对于类似的功能,其关键的数据信息校验应该由服务端完成,而不能只以前端来做判断。例如,商品的金额,商品的折扣,商品的数量和限购等。
请求重放测试
测试方法:例如一些商品订购功能,生成订单时抓取其请求,然后发送到 repeater,不断的 go,如果一个请求可以多次成功,生成多个订单,则存在此问题。其危害在于一次购买多次收货。
修复方法:可以添加随机的 token 作为验证,一次请求后即失效。在服务器端生成订单的时候,要对订单 token 对应的订购信息内容、用户身份、用户积分等一些信息进行强制校验。
业务上限测试
测试方法:说是业务上限测试,也可使说是对前几条的总结或结合,例如一个查询订单功能,只能查最近 6 个月的订单,请求后抓包,修改其值为 12 则可以查看一年的订单,则存在此问题。
修复方法:修复方法:可以添加随机的 token 作为验证,一次请求后即失效。在服务器端生成订单的时候,要对订单 token 对应的订购信息内容、用户身份、用户积分等一些信息进行强制校验。
密码找回模块
验证码客户端回显测试
测试方法:在很多的修改密码功能中,第一步都会要求用户输入手机号或者邮箱来验证用户的身份,那么验证码就可能会出现在响应包中,有些程序会将验证码放在响应包中。拦截发送验证码的的请求,查看其 response 的信息,是否包含其验证码,包含验证成功,则存在此问题。
修复方法:避免将验证码回显在响应包中,验证的比对应放在服务端进行。
验证码暴力破解测试
测试方法:一般情况下,只有用户自己通过手机或邮箱来收取验证码,但当服务器没有对错误的次数做限制时,则可导致暴力破解。首先应该知道验证码的规律,例如是 4 位数字,或 6 位数字,然后手机发送验证码后,任意输入一个符合规则的验证码,拦截包发送到 intruder,对验证码添加标记进行枚举测试,跑出结果后根据 length 长度来找出正确验证码。
修复方法:建议对错误的次数做限制,避免被爆破,同时设置验证码的有效期,然后再加大其复杂度。
接口参数账号修改测试
测试方法:这个也可以分为多种情况,例如修改密码时,需要发送用户凭证,拦截数据包,将凭证的地址(手机号或者是邮箱等)改为自己的,如果自己可以收到,则存在此问题。再例如,直接修改自己的,拦截数据包,将其中修改的账号换成他人的,如果成功修改,则也存在此问题。
修复方法:建议对修改连接增加 token 来做验证,一个 token 只能修改一次且 token 只能使用 1 次。
response状态值修改测试
测试方法:例如一个修改密码功能,第一步需要输入手机号和接收到的验证码,通过后才可以进行第二步的修改。通常如果第一步验证成功,一般服务器都会返回类似 ok、1、success、true 这种的状态值。那么在拦截数据包后可以右键选择 do intercept->reponse to this request,这样下一步就会显示服务器的返回包,修改其状态值,然后直接 intercept is on 关闭拦截数据包,如果跳转到修改密码页,则存在此问题。
修复方法:前端不要利用服务器的返回值来判断是否修改密码,在整个校验的流程中,都应该在服务器进行。
session覆盖测试
session 覆盖测试第一步:输入自己的手机号和自己的短信验证码跳到密码重置页,打开一个新的标签页,粘贴密码重置页的 url,放在这里做备用。第二步:回到刚才输入自己手机号的那个页面回退一步,此时输入目标用户的手机号,然后发送验证码。第三步:目标用户不知道有没有收到验证码,但此时的 session 已经有自己的换成了目标用户的。第四步:打开刚才备用的那个重置密码页,刷新一下,如果有显示修改的账号手机号,则此时应该会变成目标的手机号。重置后可以成功修改目标用户的密码。则存在此问题。
修复方法:在重置密码的请求中,一定要对修改的账号和凭证是否一致做进一步的校验。
弱token设计缺陷测试
测试方法:很多密码找回功能都会将重置密码链接发送到邮箱,可以发送多次,然后观察其 url 的规律,很多网站的重置密码链接的 token 并不安全,例如使用时间戳作为 token,或者是 id 经过 md5 作为 token,或者是 base64 编码后作为 token,观察规律后就可以伪造 url 进行目标用户的重置,如果中间加油随机数,则可以暴力破解下。
修复方法:建议设置 token 的复杂度,不要有规律可循,如果加随机验证码,建议位数多点。同时 token 设置失效时间,避免恶意攻击者有足够的时间进行爆破。
密码找回流程绕过测试
测试方法:当找回密码分为多步时,例如一步输入账号页,第二步验证身份页,第三步修改密码页。可以先用自己的账号走一遍流程,把每一步的流程都拦截数据包,依次记录下整个过程中所有的 url,然后直接访问第三步的 url 页面地址,如果可以成功打开并修改,则存在密码找回绕过问题。
修复方法:建议在后台要验证上一步的操作是否已经完成,避免被绕过。
0 条评论
下一页