Vulnerability about captCha and Mitigation
vulnerability :
- The content of the graphic captcha can be recognized by OCR
- In a multi-stage process, the verification code is verified first. After success, the next step does not need the verification, so the package can be captured directly and the verification of the first step can be skipped
- The captCHA does not expire immediately after verification in the service segment. It will not be updated until the client requests again. As long as the client no longer requests the captcha, the original captcha can be used
- Whether the module generating captcha generates captcha according to the parameters provided. If so, it indicates that there is a vulnerability
- Some captchas are bound to a parameter in a packet, such as an attribute in a cookie, and are considered valid as long as they match. There are holes in this mechanism.
- In some cases, captchas are hidden in HTML source code or otherwise obtained in "clear text"
- On the server side, should the user name and password be verified only after the verification code is passed, if not, it indicates that there is a vulnerability?
- 图形验证码的内容可OCR识别
- 多阶段的过程,先校验验证码,成功之后的下一步不需要验证码,可以直接抓包,跳过第一步的验证
- 验证码在服务段校验后,没有立即失效,需要客户端再次请求才会更新,只要客户端不再请求验证码即可使用原来的验证码
- 生成验证码的模块是否根据提供的参数生成验证码,如果是说明存在漏洞
- 有些验证码与数据包中的某个参数绑定,比如cookie中的某个属性,只要它们相匹配,验证码就认为是有效的。这种机制存在漏洞。
- 在某些情况下,验证码隐藏在HTML源码或通过其他方式获得“明文”
- 在服务器端,是否只有在验证码检验通过后才进行用户名和密码的检验,如果不是说明存在漏洞。