业务安全问题挖掘与总结

发布时间:2020年06月18日 阅读:95 次

   

登录认证模块

Tuesday, August 11, 2020

2:15 PM

   

安全问题1:暴力破解测试

在已知账密之一或未知的情况下进行暴力猜解,使用burp的intruder创建测试。

防范方法:

增加验证码,登录失败一次验证码变换一次。

登录失败次数策略限制,同一用户登录失败的情况下10分钟内连续失败5次锁定2小时。

条件允许的情况下加入多因素验证机制,如手机验证码邮箱验证码等。

   

安全问题2:传输加密测试

使用burp或者wireshark进行抓包

防范方法:

部署使用ssl证书加密

   

安全问题3:session会话固定测试

原理:用户推出应用系统时,应将客户端的session认证属性标记清空,系统重复利用session标识认证会话。攻击者可以利用该漏洞生成固定的session会话,诱骗用户利用攻击者生成的固定会话登录系统,从而导致用户的会话认证被窃取。

注销推出系统时,对当前浏览器授权的sessioniD进行记录,再次登录系统对本次授权的sessionID进行对比校验,判断服务器是否使用与上次相同的sessionID进行验证,若相同 存在漏洞。

防范方法:

客户端登录系统,判断客户端是否提交浏览器留存的session认证会话标识,客户端提交此信息到服务器时,应及时销毁浏览器留存的session认证会话,并要求客户端浏览器重新生成session认证会话标识。

   

安全问题4:session会话注销逻辑问题

用户退出系统,未清空session认证会话,该会话持续有效,此时攻击者获得该session认证会话会导致用户权限被盗取

测试:截取登录授权的系统页面使用burp保存session认证记录发送到repeater模块,退出系统后发送请求测试。

防范方法:用户注销系统,服务器应及时销毁session认证会话信息并清空客户端浏览器session属性标识。

   

安全问题5:session会话超时时间测试

对用户会话认证授权时间过长。使用burp发送至repeater模块长时间后重放。

防范方法:

对每个生成的session认证会话配置生命周期,常规业务建议30分钟到期。

   

安全问题6:cookie仿冒

对系统会话授权认证的cookie中的会话身份认证标识篡改测试,通过修改身份认证标识来判断是否改变用户身份会话,(张三改成李四)

防范方法:

建议对客户端标识的用户敏感信息数据,使用session会话认证方法避免被他人仿冒。

   

安全问题7:加密方法泄露

前台浏览器客户端对密码进行hash加密后传输给服务器与数据库加密值进行对比,如果加密值相同,则判定用户提交密码正确,流程会泄露密码加密方法导致安全隐患。

防范方法:

将密码加密过程和密文对比放置在服务器后台执行。重点:加盐或者在服务器上取随机值作为盐加密后发给服务器。

   

安全问题8:登录失败信息提示问题

登录失败,提示:用户名不存在  用户密码错误等。可以提供给攻击者信息便于针对性爆破测试。

防范方法:

模糊描述,使用:用户名或密码信息有误

   

   

   

   

业务办理模块

Tuesday, August 11, 2020

2:15 PM

   

安全问题1:订单ID篡改测试

在电子交易业务中,用户登录后下单购买商品,下单后用户可以查看订单详情。当开发人员没有考虑登录后用户权限隔离的问题就会导致平行权限绕过漏洞。攻击者只需要创建一个普通用户就可以通过篡改遍历订单的id,获得其他用户订单详情。漏洞会泄露客户隐私。

如http://xxxx.com/?policyNo=P12213111122抓包修复policyNo即可越权查看他人保单内容。

防范方法:

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

   

安全问题2:手机号码篡改

修改手机号码测试是否存在越权,先正常登陆,再通过抓包形式修改成其他手机号码。

防范方法:

后台请求要通过session机制判断用户身份,如果客户端传输手机号码,则服务端需要校验手机号是否和登陆者的身份保持一致,否则拒绝。

   

安全问题3:用户id篡改

创建一个普通账户,在部分涉及用户业务信息查询时抓包,然后遍历用户ID获取其他用户信息。

防范方法:

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

   

安全问题4:商品编号篡改

提交订单时,抓包篡改商品编号,导致商品与价格不对应但交易成功。攻击者从价格中获利。

防范方法:

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

   

安全问题5:竞争条件攻击

在服务器与数据库读写存在时序问题时,就可能存在竞争条件漏洞。攻击者利用多线程并发请求,在数据库中的余额字段更新之前多次兑换积分或者商品。例如:提交订单时抓包,然后设置多个线程重放此包,个别请求就可能争取绕过金额次数的判断,交易成功。退款时生成两单退款申请等。

防范方法:

在处理订单和支付关键业务时候,使用悲观锁或者乐观锁保证事务的ACID,避免数据的脏读。

   

   

   

业务授权访问模块

Tuesday, August 11, 2020

2:15 PM

   

安全问题1:未授权访问

获取登录后的前台或后台url,尝试换成其他浏览器访问,观察是否访问成功。

防范方法:

未授权访问说明授权存在缺陷,需要对未授权的页面做session认证,并对用户访问的每一个url做身份鉴别,正确校验用户ID和Token等。

   

安全问题2:越权

抓包修改用户身份id测试,如不确定其他用户id可以使用burp的intruder的模块进行爆破。

防范方法:

服务端需要校验身份唯一性,自己的身份只能自己查看修改删除添加自己的信息。

   

   

   

输入输出模块

Tuesday, August 11, 2020

2:15 PM

   

安全问题1:sql注入

测试:报错,延时,布尔,盲注;

测试过程:

在url?后面加数字类似http://www.xxx.com/1.php?id=122   and 1=1  改and 1 =2

字符:在参数后加单引号或者%27 添加 'or'='1  

时间:sql语句加sleep进行延时。

防范方法:

过来敏感字符信息!使用预处理pdo 预编译语句。注意不要讲变量直接拼接到pdo语句中而是使用占位符进行数据库的增删改查。

   

安全问题2:xss

跨站一般分为反射 DOM 存储。直接在输入框输入脚本测试,绕过:双写,大小写,编码转换。

防范方法:

对用户的输入校验过滤敏感字符,特殊字符进行转义。信息搜索功能不应再搜索结果页面回显内容。同时设置出错页面,防止web服务器发生内部错误时将错误信息返回给客户端。

具体方法:1.定义允许的行为 2检查post和get请求的响应,确保返回值为预期。3.对用户提供的数据进行编码,从用户输入中移除冲突的字符,括号和单引号。4输入非字母和数字字符,先将编码转为HTML实体,然后再将其用在http响应中。

   

   

安全问题3:命令执行

应用需要调用一些外部程序去处理内容的情况下,就会用到一些执行系统命令的函数,当用户可以控制命令执行函数的参数时,将可注入恶意系统命令到正常命令中,造成命令执行攻击。可使用 & | || 连接正常命令。

防范方法:

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

   

   

   

   

   

回退模块测试

Tuesday, August 11, 2020

2:15 PM

   

验证:密码修改成功后,尝试是否可以进行回退,结果可以回到充值密码这一步可以修改密码成功无限制。

防范方法:

对于业务流程有多步的情况,如修改密码或充值密码业务,首先判断该步骤的请求是否是上一步骤的业务所发生器的,如果不是则返回错误或者业务失效。

   

验证码机制

Tuesday, August 11, 2020

2:15 PM

   

安全问题1:验证码爆破

验证码主要用户防止暴力破解,防止ddos,识别用户身份,常见的验证码主要是图片验证码,邮件验证码,滑动验证码,语音验证码。常见的验证码大部分为4-6位数字组成。如果没有对验证码的失效时间和尝试失败的次数做限制,攻击者就可以通过尝试这个区间内的所有的数字来进行暴力破解。

防范方法:

设置验证码失效时间,建议为3分钟,限制单位时间验证码失败的尝试次数,如5分钟连续失败5次即锁定该账号15分钟。

   

安全问题2:验证码重复使用

如果验证码认证成功后没有将session清空,将会导致验证码首次认证成功后可重复使用。测试时可以抓取携带验证码的数据包提交重复,查看是否提交成功。论坛留言比较多

防范方法:

针对验证码认证次数问题,建议验证码在一次认证成功后,服务端清空认证成功的session。

   

安全问题3:验证码客户端回显

比如在找回密码的页面,输入手机号获取验证码,服务器会向手机发送验证码,通过浏览器工具查看返回包信息,如果返回包含验证码,证明问题存在。

防范方法:

禁止验证码在本地客户端生成,应采用服务器端验证码生成机制。

设置验证码的时效性,验证码应随机生成,且使用一次失效。

   

安全问题4:验证码绕过

输入验证码信息提交后,抓取返回包修改进行绕过。

防范方法:

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

   

安全问题5:验证码自动识别

验证码过于简单,图像清晰能通过PKAV HTTPFuzzer工具分析出来。

防范方法:

增加背景元素干扰,如背景色 背景字母。字符的字体进行扭曲,使用公式,逻辑验证作为验证码,问答题等。

   

业务数据安全模块

Tuesday, August 11, 2020

2:15 PM

   

安全问题1:支付金额篡改

服务器卫队用户提交的业务数据进行强制校验,过度新来客户端提交的业务数据而导致的商品金额篡改漏洞。通过抓包修改业务流程中的交易金额等字段,如修改任意数额的金额提交,查看能否以修改后的金额数据完成业务流程。

防范方法:

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

   

安全问题2:商品订购数量的篡改

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

防范方法:

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

   

安全问题3:前端js限制绕过

很多商品在限制购买时在前端限制,未进行服务端校验,通过抓取客户端发送的请求包修改js端生成的交易数据即可。

防范方法:

交易数据必须在服务端校验。

   

安全问题4:请求重放

常见逻辑漏洞,如商品购买成功后,参照订购流程进行完全模拟正常订购流程重放操作。验证交易流程中随机数,时间戳等生成机制是否正常。

防范方法:

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

   

安全问题5:业务上限未定义

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

防范方法:

在服务器端对订单token对应的信息进行强校验,服务端应考交易风险控制,对产生的异常情况的交易行为应该予以限制 阻断。

   

   

业务流程乱序

Tuesday, August 11, 2020

5:23 PM

   

安全问题1:业务流程绕过

测试业务流程处理是否正常,确保攻击者无法通过技术手段逃过某些重要重要流程步骤,检查办理业务过程中是否有控制机制来保证其遵循的正常流程。

攻击者访问注册页面,注册测试账户,充值提交并抓取数据包,填写任意充值金额并抓包,获取订单号,利用订单号构造充值链接并访问链接,查看是否充值成功。如果成功则存在此问题

防范方法:

针对此问题,建议对敏感信息如身份id 账号面,订单号 ,金额等进行加密处理,并在服务端进行二次对比。

   

密码找回模块

Tuesday, August 11, 2020

5:23 PM

   

安全问题1:验证码客户端回显

找回密码的验证码会在响应中回显,有些网站程序会选择将验证码回显在响应中来判断用户输入的验证码是否和响应中的验证码一致过一致通过校验。

防范方法:避免返回验证码在响应包中,验证码一定要在 服务端校验。

   

安全问题2:验证码暴力破解

找回密码功能,通常把验证凭证通过邮箱或手机号发给用户,可以多发几次观察验证码复杂性,如果复杂度较低,可以尝试暴力枚举。

防范方法:建议对用户输入验证码校验采取错误次数限制并提高验证码的复杂度。

   

安全问题3:接口参数账户修改

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

测试中,可以修改成他人id或者使用他人id找回密码 篡改联系人信息 邮箱 手机号等。

防范方法:

对找回密码的token做一对一的校验,一个token只能修改一个用户。同时一定要保证token不泄露。

   

安全问题4:response状态值修改

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

防范方法:

注意不要在前段利用服务器返回的值判断是否可以修改密码,要把整个校验环节交给服务端验证。

   

安全问题5:session 覆盖

测试方法:1.需要准备自己的账号接收凭证(短信验证码)2.获取凭证校验成功后进入密码重置页面3.在浏览器新标签重新打开找回密码的页面,输入目标手机号4.此时当前的session账户被覆盖,重新回到第二步打开的重置密码页面即可重置目标手机号。

   

安全问题6:密码找回绕过

大多数网站密码找回包括,用户输入找回密码的账号,校验凭证,向用户发送验证信息找回密码链接等。校验成功进入重置密码页面。第二步尤为重要。

测试:正常操作一遍流程,在获取三步的URL之后,尝试输入账号之后,1-3步,绕过第二步。

安全防范:

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

   

业务接口调用模块

Tuesday, August 11, 2020

5:46 PM

   

安全问题1:接口调用重放

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

防范方法:

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

   

安全问题2:接口调用遍历

web接口一般将常见的一些功能需求进行封装,通过传入不同的参数来获取数据或者执行相应的功能,其中一个最常见的场景就是通过接口传入id参数,返回对应id的一些信息。在安全测试中,我们可以使用burp记录请求信息,整站点爬取后,通过intruder对id参数进行遍历,看是否返回不同的响应信息,如果不同id值对应不同用户的信息,则说明存在漏洞。

防范方法:

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

   

安全问题3:接口调用参数修改

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

防范方法:

会话session中存储重要的凭证,在忘记密码重发验证码等业务中从session获取用户凭证而不是从客户端请求的参数中获取。

从客户端处获取手机号 邮箱等账号信息,要与session中的凭证进行对比,验证通过后才允许进行业务操作。

   

安全问题4:接口未授权访问

测试中,可以使用burp作为代理在登录状态下记录所有的请求和响应信息,筛选出敏感功能,返回敏感数据的请求,在未登录的情况下,使用浏览器访问对应敏感功能的请求,如果返回的数据与登录状态后的一致,则存在漏洞或缺陷。

防范方法:

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

   

安全问题5:callback自定义

在浏览器中存在同源策略,所谓同源是指协议 域名端口相同,当使用ajax异步传输数据时,非同源域名之间会存在限制,其中有一种解决方法jsonp,基本原理是利用了HTML里的<script></script>元素标签,远程调用json文件来实现数据传递,jsonp技术一般使用callback参数来声明回调时所使用的函数,这里往往存在安全问题,由于没有使用白名单的方法

   

安全问题6:webservice问题

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

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

找到webservice的链接,在后面加入?Wsdl服务器会返回wsdl描述的函数信息。

防范方法:

为webservice添加身份认证,认证成功后可允许访问和调用。 webservice中接收输入参数的函数,在后端应该对输入参数进行过滤和净化,在处理后才入库查询。在敏感功能的函数中,添加密码认证,认证后才允许调用敏感功能的函数。

Tag:
相关文章

发表评论: