（1）. 验证码在页面或者cookies中输出。这个时候只需要提取一下就能直接使用了。经过加密的也不行，也可以直接去替换密文。
（2）. 验证码验证完成后没有销毁，导致验证码重复使用。 验证码的值是在session中存储的，每次提交之后对比判断是否正确。如果验证完成后，没有更换或者清除session中的值，这时，如果不重新请求验证码就能一直使用之前的那个值了。 这里有一个案例 http://wooyun.org/bugs/wooyun-2010-025053 还比如 https://github.com/tianyu0915/DjangoCaptcha/blob/1b43e2af98b055c2e4b55a724f772b352de9c914/DjangoCaptcha/init.py
def check(self,code):
"""
检查用户输入的验证码是否正确
"""
_code = self.request.session.get(self.session_key) or ''
if not _code:
return False
return _code.lower() == str(code).lower()
比如说这个验证码用在用户登录页面上，每次提交都需要验证码。我就可以把第一次显示验证码aeft设置的cookies记录下来，每次提交这个cookies和对应的验证码aeft就行了。这样就能绕过验证码了。
我后来基于这个自己改写的验证码逻辑是
def check(self, code):
"""
检查用户输入的验证码是否正确
"""
_code = self.request.session.get(self.session_key) or ''
if not _code:
return False
expires_time = self.request.session.get(self.captcha_expires_time) or 0
# 注意 如果验证之后不清除之前的验证码的话 可能会造成重复验证的现象
del self.request.session[self.session_key]
del self.request.session[self.captcha_expires_time]
if _code.lower() == str(code).lower() and time.time() < expires_time:
return True
else:
return False
（3）. 验证码不过期 验证码应该是有过期时间的，验证的时候判断，如果超时就认为是输入错误。参考上面我的代码
（4）. 各种脑残的判断是否需要验证码的逻辑问题
- 是否需要验证码是放在cookies或者session中的。比如说你登录的时候，错误次数超过3就要出现验证码，每次输入错误都加1，这个值存放在cookies或者session中，如果攻击者每次请求之前清除了本地的cookies，那服务器没办法识别了。这个情况下，应该是在数据库中对用户名和是否需要验证码进行绑定。
- 有的系统中，没有请求验证码的时候session中对应的值是空字符串或者固定值，这样的话，前端拦截了验证码请求之后，这个值就不会发生变化，验证码字段直接提交空字符串或者固定值就行了。
（5）. 验证码太弱，容易被识别。 这个问题应该是安全和用户体验的平衡，常用的验证码识别技术参考 http://drops.wooyun.org/tips/4550 http://drops.wooyun.org/tips/141
（6）.新型验证码的问题 比如说 https://www.v2ex.com/t/138479 这个验证码就是可以通过代码模拟得到几乎100%的通过率。还有图片验证码和语言验证码同时出现的那种，可能语音验证码就比图片验证码更好识别。
