这是自己之前读了《Web攻防之业务安全实战指南》后,做了一个简单的总结

一.登录认证模块

1.暴力破解

使用burpsuite中Intruder使用字典爆破用户名和密码

修复建议

<1>增加验证码,登录失败一次更换一次

<2>限制登录失败次数

<3>条件允许时,添加使用手机或邮箱接收验证码进行登录

2.本地加密传输

使用Wireshark抓包,选择与公网连接的本地网卡并开启对网卡流量数据的捕获功能 查看抓包的HTTPS网站登录的请求数据包是否对登录请求数据信息进行加密传输

修复建议:在假设web应用的服务器上部署有效的SSL证书服务

3.Session

在登录页面点击注销用户,使用burpsuite抓包并记录本次登录的SessionID 再次重新登录,抓包,将上次记录的SessionID与本次登录的Session对比,判断是否相同

修复建议:首先判断客户端是否提交浏览器的留存Session认证会话属性标识,客户端提交请求时应删除留存的Session,并要求客户端重新生成Session

4.Session会话注销

通过burpsuite对已登录的页面进行抓包,发送到Repeater,再将已登录用户注销,然后在Repeater中模拟发包,查看是否登录成功

修复建议:在用户注销时立即销毁Session并清空客户端浏览器Session属性标识

5.Session会话时间超时

登录后经过30分钟查看是否仍为登录状态并可操作

修复建议:对每个Session会话设置生命周期(常规业务建议30分钟以内)

6.密文对比认证

*正确密文对比过程: 用户提交账号密码—服务器hash加密—与数据库中内容对比 *错误密文对比过程: 用户提交账号密码—客户端hash加密—服务器—与数据库中内容对比

使用burpsuite抓包,查看包中密码是否加密,若加密则为错误对比方式(一般为JavaScript加密),攻击者可看出加密方式利用爆破攻击

修复建议:使用正确的密文对比方式

7.登录失败信息

用户登录失败时,回显“用户名不存在”、“账号不存在”、“密码错误”等,会给攻击者提示进行猜解的账号是否存在,密码是否正确

修复建议:对登陆失败提示进行模糊处理,如“用户名或密码错误”、“登录失败”等

二.业务办理模块

1.订单ID篡改

抓包修改订单代表用户身份的id值,可以访问其他用户的订单页面

修复建议:后台查看订单时要通过Session机制判断用户身份,服务器端要校验订单与登录者身份一致。

2.手机号码篡改

以某网站挂失为例,抓包修改手机号码,即可挂失其他手机号码

修复建议:后台请求要通过Session判断用户身份,校验手机是否和登录者身份是否一致。

3.用户ID篡改

例如某商场的收货人信息,修改参数中的数字,会访问到其他用户的信息

修复建议:后台请求要通过Session判断用户身份,校验ID是否和登录者身份是否一致。

4.邮箱和用户篡改

发送邮箱时,抓包篡改其中的发件人参数,可伪造发件人进行钓鱼攻击。

修复建议:发送信息要通过Session机制判断用户身份。服务端需要校验邮箱、发件人、是否与登录者的身份一致。

5.商品编号篡改

一个需要三十元的商品,另一个需要五元的商品,将五元商品进入购买页面抓包将id修改价值为三十元的商品id,即使用五元购买到三十元的商品

修复建议:商品金额不要在客户端传入,服务器端要验证请求商品价格和交易金额是否一致。

6.竞争条件

竞争条件概念:当两个或多个进程试图在同一时刻访问共享内存,或读写某些共享数据,最后的竞争结果取决于线程执行的顺序(线程运行时序)

攻击者在提交订单时抓包,然后设置很多个线程重放此包。在众多请求中,可能就有余额未即使更新的将争取绕过金额、次数的判断

修复建议:在处理订单、支付等关键业务时,使用悲观锁或乐观锁保证事务的ACID特性(原子性、一致性、隔离性、持久性)。

三.业务授权访问模块

1.非授权访问

在IE中访问登录后敏感界面,再在其他浏览器复制其URL访问,看是否访问成功

修复建议:对未授权访问页面做Session认证,对用户访问的每一个URL做身份鉴别,校验用户ID和token

2.越权(水平、垂直)

例如某网站用户登录后查看个人信息,抓包修改用户ID可访问其他用户个人信息,实现水平越权。 用普通用户登录后台,修改密码,抓包将要修改密码的用户名改为最高管理员ID,达到修改管理员密码的垂直越权

修复建议:服务器端要校验身份唯一性,自己的身份只能查看、删除、修改、添加自己的信息

四.回退模块

1.回退

例如某网站修改密码有多个步骤(验证身份—重置密码—完成) 修改密码成功后,回退,看是否返回重置密码的界面

修复建议:对业务流程有多步时,如修改密码等,首先判断步骤的请求是否为上一步骤发起的

五.验证码机制

1.验证码暴力破解

注册时手机发送验证码,抓包对验证码实施爆破

修复建议:

<1>设置验证码失效时间,如60s

<2>限制验证码失败尝试次数

2.验证码重复使用

攻击者输入验证码提交时抓包,将数据包重复提交,查看是否提交多条信息

修复建议:验证码在一次验证后,服务端清空认证成功的Session

3.验证码客户端回显

输入手机号获取验证码,服务器会向手机发送验证码,通过浏览器工具抓包查看返回包,返回包中有可能包含验证码

修复建议:

<1>禁止验证码在客户端生成,应在服务器生成和验证

<2>设置验证码的时效

<3>验证码随机生成且一次失效

4.验证码绕过

验证码数据包发送后,查看返回包,将其中1,0,false等参数修改发送,绕过验证

修复建议:在服务器端增加验证码认证机制,进行二次校验

5.验证码自动识别

识别流程:图像二值化处理—去干扰—字符分割—字符识别 使用PKAV HTTP Fuzzer设定一个验证码包含的字符范围,用burp suite抓包,将请求数据包放入PKAV HTTP Fuzzer中,设置验证码标志位,用户名和密码标志位进行爆破

修复建议:

<1>增加背景元素的干扰

<2>字符的字体进行扭曲、粘连

<3>使用公式、计算等逻辑方法做验证码

<4>图形验证码与使用者相关,如用过的头像和购买过的商品

六.业务数据安全

1.商品支付金额篡改

交易时抓包篡改商品金额

修复建议:商品金额等原始数据校验应来自于服务器端,不应接收客户端传值

2.商品订购数量

将购买商品数量修改为负数

修复建议:服务器端应对异常交易(商品价格为负,数量为负,运费为负)直接予以限制、阻断

3.前端JS绕过

有时会限制商品购买数量,但使用前端JavaScript校验,可以抓包修改数量再提交

修复建议:不要相信客户端传值,校验应在服务器端进行

4.请求重放

提交订单时抓包,将数据包多次重放,查看是否生成多个订单

修复建议:每次订单的token不能重复提交,应在服务器端对token、订单信息、用户身份、用户余额进行强校验

5.业务上限

例如业务查询只允许查询近三个月的记录,查询时抓包修改数据包中的month并修改,成功查询到大于三个月的记录

修复建议:仍然在服务器端对各类信息进行强校验

七.业务流程乱序

1.业务流程绕过

例如某网站充值成功后会跳转到某url,其中包含订单号,将未支付的订单号替换上去,可绕过支付环节

修复建议:对身份ID、账号密码、订单号、金额做加密处理,并在服务器端做二次校验

八.密码找回模块

1.接口参数账号修改

某网站找回密码时,会向邮箱发送验证码邮件,抓包将数据包中Email修改为自己的邮箱,会发现邮件发送到自己的邮箱中

修复建议:找回密码的token做一对一校验,一个token只能修改一个用户

2.Session覆盖

找回密码时,输入A的手机号,通过手机接收验证码验证,此时再将目标账号找回密码到手机接收验证码界面,此时再刷新A验证界面,用户A变为了B,达到了session覆盖

修复建议:重置密码请求时要验证修改的账号和凭证是否一致

3.弱token设计缺陷

有时token会是一个时间戳,将token时间格式化后会变成日期,这样token就是一个可预测的时间范围内的时间戳,可采用推测或暴力枚举破解

解决方案:token不能使用时间戳或用户邮箱等有规律可循的数字字符

4.密码找回流程绕过

先使用自己的账号进行密码修改流程,记下每一步对应的URL,再将目标账号修改密码,再验证身份时直接输入下一步的URL,看是否能绕过身份认证

解决方案:在后端逻辑校验中确认上一步流程已完成

九.业务接口调用模块

1.接口调用重放

提交订单时抓包在repeater中多次重放,看是否会执行多个有效操作

修复建议:对生成订单环境采用验证码机制,并每一个订单生成一个token,订单提交后token失效

2.接口调用遍历

测试前用burp suite爬虫对网站爬取,筛选出包含用户标识参数的请求(id、uid),对筛选出的请求进行分析看是否包含敏感信息。如包含则对参数进行爆破,如果返回他人的信息则漏洞存在

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

3.接口未授权访问/调用

如果敏感接口没有身份验证,用burp suite在登录状态下记录所有请求和相应信息,筛选出敏感功能(MIME,type为json、script、xml、text),在未登录时访问对应敏感功能的请求,若返回数据正常,则存在漏洞

修复建议:

<1>采用token校验

<2>在接口被调用时,后端对会话状态验证,如已登录则返回数据,未登录则不返回

4.callback(回调函数)自定义

callback:用来声明回调时使用的函数名 若没有使用白名单限制callback函数名,那么攻击者可自定义callback内容,触发XSS等漏洞

修复建议

<1>严格定义HTTP响应中的Content-Type为json数据格式:Content-Type:application/json

<2>建立callback函数白名单

<3>对callback参数进行HTML实体编码

5.WebService

攻击者通过爬虫或目录扫描等方法找到服务器WebService链接,使用WVS的Web Services Editor导入各个接口函数,对每一个接口函数的输入参数进行Sql注入或文件上传测试,如果出现服务器报错、不同的延时等,则存在漏洞

修复建议

<1>为WebService添加身份认证

<2>WebService中接收输入参数的函数,在后端应进行参数过滤

<3>在敏感功能函数中添加密码认证