一．前因
之前测试时遇见cookie时，基本只替换或修改，而将cookie为空的情况或者直接删除cooike参数给忽略了，直到现场见过别人将Cookie直接清空删除可成功访问登录，因而测试网站时也将此项加入测试项，或者说是也想找到类似的，果然时不我待，巧了，碰见了。涂码严重，请见谅。
二．绕过原密码认证修改个人密码
在修改密码的表单处，抓包将oldPwd参数直接删除，未能绕过原密码的认证，修改响应包中的success相关字段，也未能正常修改成功；后来再将POST的请求方式修改为GET的方式，成功修改密码，服务器端未对资源的请求方式进行限制，切对原密码为空的情况或者无此参数的情况进行校验，数据库未将oldPwd的值与存储在数据库的值进行比对。
修复：禁用PUT、DELETE、OPTIONS等请求方法,设置oldPwd参数不能为空，必须将oldPwd与其他值一同验证或加入其他不为空、随机具有时效性的标识。
此后也验证了服务器启用了其他方法：
三．横向越权修改密码
既然可以成功修改个人的密码，是否可以横向或纵向越权修改密码？
存储在数据库中的日志一般都包括操作人，起止时间，操作IP，操作内容，数据存储在数据库中一般为了区分识别，应也设置了一些唯一（有效）标识，而修改某些信息，一般也是在数据库中修改，并将修改后的结果呈现给用户。
案例：
注册登录后，在修改个人密码处，抓包发现id为可控参数，且为服务端可识别的标识，
直接修改id，发包显示修改密码成功。
接着就去找唯一(有效)标识，在浏览器上审查元素和源代码以及JS代码上翻找，尝试以sysUser,myUnitName为另一个已注册的账号名，构造User,Username为另一个已注册的账号名均失败，最终在一个链接的div标签中（已找不到截图了），MessAge将其后的hidden删去，在一个前半部分空白的框，底部位置发现存储着部分userId，便按着绕过原密码认证修改个人密码的老套路，修改请求方式，删除oldPwd参数，加入useId参数，重放发包，成功将密码修改。感觉相对而言，此方法略显鸡肋，userId无法精准构造，进而无法遍历。
后来请维护人员和管理员帮忙查下userId对应的账号并验证使用原密码已不可登录。
其他越权
低权限账号越权访问仅高权限账号或者其他账号拥有的路径和目录，删除、替换cookie登录页面，构造替换有规律的token值等。
修复
禁用PUT、DELETE、OPTIONS等请求方法，删除该链接及隐藏值，判断用户登录状态和访问权限，严格控制用户权限，添加无规律随机的token。
注：以上的测试均在授权下进行的。另外新手一枚，文笔粗糙，大佬们轻喷。希望能在90sec学习知识，分享交流。
- 通过
- 未通过
0 投票者