逻辑漏洞

攻击者利用业务的设计缺陷，获取敏感信息或破坏业务的完整性， 其本质就是程序逻辑输入管控不严，没有对用户数据进行严格把控，导致程序不能够正常处理或处理错误，一般出现在登录注册、密码找回、信息查看、交易支付金额等。

逻辑漏洞类型

越权

水平越权

漏洞介绍：即普通用户/管理员能访问其他普通用户/管理员才能够访问的系统信息或者系统功能。

形成原因：在进行方法调用时候未进行请求用户和目标信息拥有者是否匹配一致，直接用userid/email之类的容易遍历的参数进行数据库查询。

漏洞点：在普通用户/管理员登录后的能访问的链接或者功能中都可能存在。

漏洞修复：在权限管理中，平行越权的权限管理颗粒度最小修复思路需要在方法中进行相关的获取请求request再利用getAttribute("userid")获取其userid直接使用该userid作为参数进行数据增删查改，避免userid参数传输。

垂直越权

漏洞介绍：即普通用户能够访问管理员甚至超级管理员才能够访问的系统信息或者系统功能。

形成原因：程序再方法调用时候，缺少角色等级校验。

漏洞点：在任何用户登录后才能访问的链接或者功能中都可能存在对每一个传输的参数都要了解参数的目的，尝试将用户名改为admin尝试绕过。

漏洞修复：需要校验用户是否有权限访问这个方法修复思路：获取请求request再利用。getAuttribute("roleid")获取其角色等级检查角色等级是否合法，错误则直接返回错误跳转，返回页面必须仍然从Attribute中获取userid再进一步查询相关信息值得注意的是切勿将错误跳转写到Javascript里面，还返回目标URL页面的相关信息。

登录

本地加密传输

cookie脆弱

漏洞介绍：通过伪造cookie信息能够伪造其他用户进行登录。

漏洞原理：开发者为了方便将身份信息/登录信息明文或者只是简单编码、哈希之后存放在cookies中，网站通过获取得到的cookies进行授权或者身份验证。

漏洞点：cookie中有明显或者只是简单编码、哈希的字段时候 修改lsLogin值为1可以判定为用户已经登录 修改cookie为asp163=UserName=admin

漏洞修复： Cookie不应该存储可理解的身份信息和登录信息 按照规定，cookie对身份信息和登录信息的存储只能通过存储足够长度的随机字符串进行，避免篡改。

Session劫持

漏洞介绍：会话固定攻击是利用服务器的session不变机制，借他人之手获得认证和授权，然后冒充他人。

漏洞原理：在请求登录过程时候，URL带有一个session，登录成功之后会将登录成功的信息绑定到这个session中，攻击者可以发送带有session的URL给相关工作人员诱导其登录，相当于获取了其身份信息。

漏洞点：在GET方法请求登录时候带有session值。

修复思路：只要避免在URL中带入session信息即可比较有效的防御另外也要注意POST请求中带有sessionid进行session固定攻击，虽然可利用性比较低，但是建议修复。

密文对比认证

暴力破解

漏洞介绍：攻击者可以通过该漏洞获取用户名和对应弱口令密码，并进行登录操作漏洞原理：由于没有设置登录失败次数限制，导致攻击者可以通过口令字典进行特定用户的密码爆破或通过用户名字典进行特定弱口令的用户枚举。

漏洞点：系统登录点

漏洞修复： 对于固定用户名爆破密码可以针对用户名进行错误次数计算，高于一定阈值账号锁定一段时间，或者添加验证码但是不能永久锁定，可能被用来进行账户恶意锁定对于固定密码枚举用户名、 需要计算IP对URL的请求情况，某个IP短时间大量请求登录应该加入黑名单 进行传输数据加密有一定的防护效果。

业务

订单ID

用户ID

在支付当中会出现当前用户的ID，比如：username=XXXXX，如果没有加以验证，其支付也是一次性支付没有要求输入密码什么的机制，那么就可以修改这个用户ID为其它用户ID，达到用其他用户的账号进行支付你的商品。

订单号码

商品ID

其他

验证

暴力破解

漏洞介绍：攻击者可以通过该漏洞获取用户名和对应弱口令密码，并进行登录操作。

漏洞原理：由于没有设置登录失败次数限制，导致攻击者可以通过口令字典进行特定用户的密码爆破或通过用户名字典进行特定弱口令的用户枚举。

漏洞点：系统登录点

漏洞修复： 对于固定用户名爆破密码可以针对用户名进行错误次数计算，高于一定阈值账号锁定一段时间，或者添加验证码但是不能永久锁定，可能被用来进行账户恶意锁定对于固定密码枚举用户名、 需要计算IP对URL的请求情况，某个IP短时间大量请求登录应该加入黑名单 进行传输数据加密有一定的防护效果。

绕过验证

漏洞介绍：攻击者通过篡改分步逻辑中的步骤数字，达到绕过支付、校验等效果。

漏洞原理：程序逻辑分布进行，但是对步骤、验证信息、支付信息没有做好严格校验，导致修改步骤就直接绕过验证或者支付。

漏洞点：任何分布逻辑且带步骤数字，或者利用JS进行步骤控制的功能中。

漏洞修复：在请求最后一步时候需要带入前面的验证信息，服务端再进行一次校验信息的验证，验证正确方能继续执行数据操作也可以及通过getAttributr("userid")获取userid进行userid和验证结果绑定，最后一步不带入验证信息，但是仍然要获取userid进行校验再最后一步通过验证之后或者服务器收到支付信息后再生成相应的数据交给用户。

自动识别

图形验证码绕过

漏洞介绍：攻击者通过突破图形验证码的验证，可以实现如登录爆破、验证码绕过等攻击。

漏洞原理：图形验证码在错误后未失效返回验证码信息分步验证验证码。

漏洞点：任何存在图形验证码的功能中。

漏洞修复一旦验证码使用过了，必须要进行删除，重新生成验证码，可以梵高attribute中验证码需要设置超时，时间一到立即删除旧验证码，用户需要获取新的验证码验证码只需要返回图片，切勿将生成验证码的字符串也一并返回验证码不应该进行分布校验，应该连同请求数据一起发送到目标服务器进行校验，服务器校验通过则返回合法数据，否则返回错误。

数据

支付篡改

在支付当中，购买商品一般分为三步骤：订购、确认信息、付款。那么这个修改价格具体是修改哪一步时的价格呢？可以在这三个步骤当中的随便一个步骤进行修改价格测试，如果前面两步有验证机制，那么可在最后一步付款时进行抓包尝试修改金额，如果没有在最后一步做好检验，那么问题就会存在，其修改的金额值你可以尝试小数目或者尝试负数。

数量篡改

在支付的过程中，数量也同时决定着价格，比如：1个数量商品对应的是100，2个数据就是200，那么当你修改这个值数量值为负数时，那么其金额也会变为负数，最后就会导致支付问题的产生。

请求重放

漏洞介绍：通过数据包重放，可以造成短信轰炸、邮件轰炸、重复提交订单等。

漏洞原理：后台未进行相关操作的技术导致数据包重放。

漏洞点：短信验证码、邮件校验、提交订单等功能。

修复方案：修复思路（针对短信、邮件）构造一个Hashmap<String，short>，存放邮箱或电话号码及对应次数只要某个邮箱或者电话号码次数够了，就不能继续发送了或者计算两次发送的时间间隔，时间过短就不继续发送了通用修复方案需要建立token机制或验证码机制，一次有效。

其他

找回机制

客户端回显

Response状态值

Session覆盖

弱Token缺陷

token可爆破

找回流程绕过

通过两个不同账号的找回，获得验证码之后部分的数据包，而另一个账号找回密码时跳过验证码的部分直接进入成功验证之后的部分等。

接口

调用遍历

参数篡改

漏洞介绍：攻击者通过进行数值篡改进行攻击，从而获利。

漏洞原理：没有对传输数据添加相关的校验参数后台未对参数值进行校验并直接使用数据包中的参数。

漏洞点：抽奖、购买、转账、返现等功能。

漏洞修复：对于软件来说，需要保护好内存数据，防止内存数据篡改计算传输数据的哈希，并将哈希附加在传输数据中作为校验值，避免被篡改先校验数值，防止大整数和负数；接着利用传输的商品ID从数据库中获取商品单价重新进行价格计算；最后生成订单（订单号应为随机值）。

未授权访问

漏洞介绍：即游客能够访问普通用户甚至超级管理员才能访问的系统信息或者系统功能。

形成原因：主要是系统设计期间没有进行全局用户身份校验；或者校验存在缺陷。

漏洞点：在任何用户登录后才能访问的链接或者功能中都可能存在。

漏洞修复：J2EE中存在filter，可以获取用户的cookie等信息修复思路：建立LoginList，值是当前在线用户的id对所有需要登录访问到URL，获取请求request再利用 getAttribute("userid") 获取其userid检查userid是否存在于LoginList中，不存在则直接返回错误跳转值得注意的是切勿将错误跳转写到Javascript里面，还返回目标URL页面的相关信息。

Webservice测试

callback自定义

回退

回退重放

条件竞争

漏洞介绍：可以通过同时重放大量数据包进行漏洞利用，通常用于突破限量、限额的问题都有奇效。

漏洞原理：由于目标函数中，判断与数据修复两个步骤之间，或者两个数据修改步骤之间存在时间差，且函数未进行同步锁定，则可以造成漏洞。

漏洞点：程序中存在限制，可以猜测到后台有判断与修改操作的方法。

漏洞修复：修复思路：使用synchronized关键字，可以限制同一时间内访问方法的只有单一线程并不是每个条件竞争都必须修复。