设计阶段产生,老司机也会产生、相对难发现、难以防护,相对容易利用 第三方逻辑缺陷、没有在设计初期进行安全审计、安全水平及对安全认知程度不一致
漏洞介绍:攻击者可以通过该漏洞获取用户名和对应弱口令密码,并进行登录操作 漏洞原理:由于没有设置登录失败次数限制,导致攻击者可以通过口令字典进行特定用户的密码爆破或通过用户名字典进行特定弱口令的用户枚举 漏洞点:系统登录点 漏洞修复: 对于固定用户名爆破密码
可以针对用户名进行错误次数计算,高于一定阈值账号锁定一段时间,或者添加验证码
但是不能永久锁定,可能被用来进行账户恶意锁定
对于固定密码枚举用户名、 需要计算IP对URL的请求情况,某个IP短时间大量请求登录应该加入黑名单 进行传输数据加密有一定的防护效果
漏洞介绍:会话固定攻击是利用服务器的session不变机制,借他人之手获得认证和授权,然后冒充他人 漏洞原理:在请求登录过程时候,URL带有一个session,登录成功之后会将登录成功的信息绑定到这个session中,攻击者可以发送带有session的URL给相关工作人员诱导其登录,相当于获取了其身份信息 漏洞点:在GET方法请求登录时候带有session值 修复思路:
只要避免在URL中带入session信息即可比较有效的防御
另外也要注意POST请求中带有sessionid进行session固定攻击,虽然可利用性比较低,但是建议修复
漏洞介绍:通过伪造cookie信息能够伪造其他用户进行登录。 漏洞原理:开发者为了方便将身份信息/登录信息明文或者只是简单编码、哈希之后存放在cookies中,网站通过获取得到的cookies进行授权或者身份验证 漏洞点:cookie中有明显或者只是简单编码、哈希的字段时候 修改lsLogin值为1可以判定为用户已经登录 修改cookie为asp163=UserName=admin 漏洞修复: Cookie不应该存储可理解的身份信息和登录信息 按照规定,cookie对身份信息和登录信息的存储只能通过存储足够长度的随机字符串进行,避免篡改
权限相关逻辑漏洞是逻辑漏洞中出现的最多的漏洞
漏洞介绍:即普通用户/管理员能访问其他普通用户/管理员才能够访问的系统信息或者系统功能
形成原因:在进行方法调用时候未进行请求用户和目标信息拥有者是否匹配一致,直接用userid/email之类的容易遍历的参数进行数据库查询
漏洞点:在普通用户/管理员登录后的能访问的链接或者功能中都可能存在
漏洞修复:
在权限管理中,平行越权的权限管理颗粒度最小
修复思路
需要在方法中进行相关的获取请求request
再利用getAttribute("userid")获取其userid
直接使用该userid作为参数进行数据增删查改,避免userid参数传输
漏洞介绍:即普通用户能够访问管理员甚至超级管理员才能够访问的系统信息或者系统功能
形成原因:程序再方法调用时候,缺少角色等级校验
漏洞点:在任何用户登录后才能访问的链接或者功能中都可能存在
对每一个传输的参数都要了解参数的目的,尝试将用户名改为admin尝试绕过
漏洞修复:
需要校验用户是否有权限访问这个方法
修复思路
获取请求request
再利用getAuttribute("roleid")获取其角色等级
检查角色等级是否合法,错误则直接返回错误跳转,返回页面必须仍然从Attribute中获取userid再进一步查询相关信息
值得注意的是切勿将错误跳转写到Javascript里面,还返回目标URL页面的相关信息。
漏洞介绍:即游客能够访问普通用户甚至超级管理员才能访问的系统信息或者系统功能
形成原因:主要是系统设计期间没有进行全局用户身份校验;或者校验存在缺陷
漏洞点:在任何用户登录后才能访问的链接或者功能中都可能存在
漏洞修复:
J2EE中存在filter,可以获取用户的cookie等信息
修复思路:
建立LoginList,值是当前在线用户的id
对所有需要登录访问到URL,获取请求request
再利用 getAttribute("userid") 获取其userid
检查userid是否存在于LoginList中,不存在则直接返回错误跳转
值得注意的是切勿将错误跳转写到Javascript里面,还返回目标URL页面的相关信息
漏洞介绍:攻击者通过突破图形验证码的验证,可以实现如登录爆破、验证码绕过等攻击
漏洞原理:
图形验证码在错误后未失效
返回验证码信息
分步验证验证码
漏洞点:任何存在图形验证码的功能中
漏洞修复
一旦验证码使用过了,必须要进行删除,重新生成验证码,可以梵高attribute中
验证码需要设置超时,时间一到立即删除旧验证码,用户需要获取新的验证码
验证码只需要返回图片,切勿将生成验证码的字符串也一并返回
验证码不应该进行分布校验,应该连同请求数据一起发送到目标服务器进行校验,服务器校验通过则返回合法数据,否则返回错误
漏洞介绍:攻击者通过密码找回逻辑漏洞,可以重置他人账号密码,危害他人账号安全
漏洞原理:其实是验证码漏洞的一种:
验证码时间长可爆破
返回重置密码凭证
若加密的重置密码凭证
漏洞点:任何密码找回处(可延伸至相似具有验证功能) 修改接受校验码目标
漏洞修复
一旦验证码使用过了,必须要进行删除,重新生成验证码,可以放到attribute中
验证码需要设置超时,时间一到立即删除旧验证码,用户需要获取新的验证码
校验凭证不能够随着返回包进行返回
验证码不应该进行分布校验,应该连同请求数据一起发送到目标服务器进行校验,服务器校验通过则返回合法数据,否则返回错误
校验凭证的生成需要进行随机生成,防止凭证破解
用户身份凭证和权限类漏洞修复一样,需要从attribute中获取
漏洞介绍:攻击者通过进行数值篡改进行攻击,从而获利
漏洞原理:
没有对传输数据添加相关的校验参数
后台未对参数值进行校验并直接使用数据包中的参数
漏洞点:抽奖、购买、转账、返现等功能
漏洞修复:
对于软件来说,需要保护好内存数据,防止内存数据篡改
计算传输数据的哈希,并将哈希附加在传输数据中作为校验值,避免被篡改
先校验数值,防止大整数和负数;接着利用传输的商品ID从数据库中获取商品单价重新进行价格计算;最后生成订单(订单号应为随机值)
漏洞介绍:攻击者通过篡改分步逻辑中的步骤数字,达到绕过支付、校验等效果
漏洞原理:程序逻辑分布进行,但是对步骤、验证信息、支付信息没有做好严格校验,导致修改步骤就直接绕过验证或者支付
漏洞点:任何分布逻辑且带步骤数字,或者利用JS进行步骤控制的功能中
漏洞修复
在请求最后一步时候需要带入前面的验证信息,服务端再进行一次校验信息的验证,验证正确方能继续执行数据操作
也可以及通过getAttributr("userid")获取userid进行userid和验证结果绑定,最后一步不带入验证信息,但是仍然要获取userid进行校验
再最后一步通过验证之后或者服务器收到支付信息后再生成相应的数据交给用户
漏洞介绍:可以通过同时重放大量数据包进行漏洞利用,通常用于突破限量、限额的问题都有奇效
漏洞原理:由于目标函数中,判断与数据修复两个步骤之间,或者两个数据修改步骤之间存在时间差,且函数未进行同步锁定,则可以造成漏洞
漏洞点:程序中存在限制,可以猜测到后台有判断与修改操作的方法
漏洞修复
-修复思路:使用synchronized关键字,可以限制同一时间内访问方法的只有单一线程
并不是每个条件竞争都必须修复
漏洞介绍:通过数据包重放,可以造成短信轰炸、邮件轰炸、重复提交订单等
漏洞原理:后台未进行相关操作的技术导致数据包重放
漏洞点:短信验证码、邮件校验、提交订单等功能。
修复方案:
修复思路(针对短信、邮件)
构造一个Hashmap<String,short>,存放邮箱或电话号码及对应次数
只要某个邮箱或者电话号码次数够了,就不能继续发送了
或者计算两次发送的时间间隔,时间过短就不继续发送了
通用修复方案
需要建立token机制或验证码机制,一次有效
漏洞介绍:通过添加对象字段相关参数进行数据篡改
漏洞原理:对象自动绑定被许多框架支持,它允许将HTTP请求参数自动的绑定到对象,开发者没有对其进行安全校验则容易导致数据篡改
漏洞点:常见的所有输入的地方都会出现这个漏洞,特别是金融、用户、缓存等。
漏洞修复:Spring MVC中可以使用@InitBinder注释,通过WebDataBinder的方法setAllowedFields、setDisallowedFields设置允许或不允许绑定的参数