再论验证码安全:请及时销毁你的验证码

我在中讲到了如何使用C#模拟用户登录具有验证码网站。今天我就换位思考一下,站在网站开发人员的角度讲一讲验证码的的一个安全问题:及时销毁网站中的验证码。

为了方便大家理解,这里我就以一个投票的应用网站为例进行说明。投票网站首先要防止的就是用户不断点击投票按钮来重复投票;当然,避免重复投票的解决办法有很多,比如记录IP、写入Session、Cookie甚至还有要求用户输入身份证号码等。但是你记录IP,那我就写一个程序来模拟发包,每投1票后自动换代理,然后继续投票,如果是写入到Session中那么我写个投票程序,每投1票就重新开启一个新的会话就是。如果是记入Cookie,那我该表Cookie的值再模拟投票发包,要输入身份证号进行验证?写个身份证号码生成程序也十分容易……

在投票机器人面前,记录IP、记录身份证号码、写入Session和Cookie等防作弊技术形同虚设。所以在投票网站中验证码功能必不可少。那么我们将验证码功能加入到网站投票中:

1.生成验证码图片的页面CreateImg.aspx,其后台代码为:

2.在用户单击投票按钮后触发的事件:

OK,大功告成!这个程序逻辑上有问题吗?没有吧,验证码是生成的图片,图片是有干扰因素的,不会被程序识别,而且验证码的内容是保存到服务器的,逻辑处理也是错。似乎一切都那么完美,但是事实并不是这样,对于这样的投票网站,我的投票机器人仍然肆无忌惮的不断切换IP,不断刷票。(要做投票机器人的同志们注意啦,不要看到投票的地方是有验证码的就一筹莫展了哦,也许他的网站就存在以下描述的漏洞哦!)

在平时使用IE浏览时,每投票一次后刷新页面,验证码生成页面被重新请求,所以Session值在请求验证码生成页时被替换,所以不会有什么问题。但是现在面对的是投票机器人,我的机器人在第一次请求时获得验证码的图片并展示给用户,用户肉眼识别验证码,然后输入程序的文本框中,由于服务器上验证码的内容并没有被销毁,而且投票程序也不会再请求验证码生成图片的URL,所以接下来每次使用相同的SessionID和用户输入的验证码值,服务器验证投票时  if (Session["CheckCode"].ToString().ToLower() != txbCode.Text.ToLower()) 都会返回false,验证码都是通过的,所以投票自然成功。终究是百密一疏啊!费尽心思防止投票作弊,最终却因为这一个地方的疏忽而前功尽弃,投票作弊成功,投票结果还是被投票机器人所左右。

也许有人想到了,那可以在Session中放置一个标记,如果投票成功了就将标记置“1”,下次请求时判断Session中标记为“1”就拒绝投票就是了。但是投票只是我这里举的一个例子,像论坛这种用验证码防止用户恶意灌水的总不可能限制用户只发一帖吧。论坛发帖时的验证码如果没有被及时销毁,那么我的灌水机器人就仍然可以到处肆意发帖了,哈哈哈哈。

要避免这个漏洞被利用还是很简单,只需要将上面的代码中投票完成后立即将验证码从服务器上销毁即可:

<div style="border-right: #cccccc 1px solid; padding-right: 5px; padding-left: 4px; font-size: 13px; border-top: #cccccc 1px solid; padding-bottom: 4px; border-left: #cccccc 1px solid; width: 98%; word-break: break-all; padding-top: 4px; border-bottom: #cccccc 1px solid; background-color: #eeeeee">

这样如果仍然使用相同的SessionID和验证码值,那么将会在 if (Session["CheckCode"] == null)这里判断出验证码已经过期,想成功投票?重新请求验证码页面获得验证码图片,然后重新输入验证码吧! 这个问题虽然看起来不以为然,但是正所谓“千里之堤毁于蚁穴”,只要验证码没有从服务器上销毁,那么页面上的验证码还是形同虚设,和验证码的图片地址为验证码

另外有人提到,这里是Session保存验证码才会有这个问题,那完全基于Cookie加密的呢?在前面的文章中我也提到过Cookie加密的方式保存验证码的内容,但是今天我又仔细想了一下,得出结论:验证码内容不能保存到客户端,也就是说根本就不应该使用Cookie加密的方式,Cookie加密保存验证码明文是没有什么意义的,必须要在服务器端保存与验证码相关的信息(比如验证码明文或者验证码加密解密密钥)。为什么不能使用Cookie加密保存验证码?我举个简单的例子吧:

比如现在页面上显示的验证码是1234,同时抓包发现提交的时候Cookie中有值:“EncryptCode=asdf”这是验证码的明文经过加密后的密文,我不知道加密算法是什么,但是我每次程序提交时就将1234作为验证码的值同时将“EncryptCode=asdf”作为Cookie的一部分发送到服务器,那么服务器将1234加密后与发送过来的Cookie值“asdf”一比较,二者相同,验证通过!!!

所以我认为验证码的明文是不可能完全基于客户端的,必须要在服务器上保存与验证码相关的信息(验证码明文或密钥)。既然要在服务器上保存相关信息,那么就可能出现这个漏洞。当然这是我想遍了所有验证码明文保存的方法后得出的结论,我还不敢拍胸脯说这是100%正确的,如果大家认为这个结论不正确,那希望能够提出具体的情况。

希望大家若做过验证码的都再回头看看自己的验证码内容在服务器上及时销毁没有。这个错误很容易犯,我在某大公司的网站上都发现了这个漏洞,可见犯此错的网站绝对不在少数。

最后希望大家的网站更加安全,更加健壮。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


引言 本文从Linux小白的视角, 在CentOS 7.x服务器上搭建一个Nginx-Powered AspNet Core Web准生产应用。 在开始之前,我们还是重温一下部署原理,正如你所常见的.Net Core 部署图: 在Linux上部署.Net Core App最好的方式是在Linux机器
引言: 多线程编程/异步编程非常复杂,有很多概念和工具需要去学习,贴心的.NET提供Task线程包装类和await/async异步编程语法糖简化了异步编程方式。 相信很多开发者都看到如下异步编程实践原则: 遵守以上冷冰冰的②③条的原则,可保证异步程序按照预期状态正常运作;我们在各大编程论坛常看到违背
一. 宏观概念 ASP.NET Core Middleware是在应用程序处理管道pipeline中用于处理请求和操作响应的组件。 每个组件是pipeline 中的一环。 自行决定是否将请求传递给下一个组件 在处理管道的下个组件执行之前和之后执行业务逻辑 二. 特性和行为 ASP.NET Core处
背景 在.Net和C#中运行异步代码相当简单,因为我们有时候需要取消正在进行的异步操作,通过本文,可以掌握 通过CancellationToken取消任务(包括non-cancellable任务)。 Task&#160;表示无返回值的异步操作, 泛型版本Task&lt;TResult&gt;表示有返
HTTP基本认证 在HTTP中,HTTP基本认证(Basic Authentication)是一种允许网页浏览器或其他客户端程序以(用户名:口令) 请求资源的身份验证方式,不要求cookie,session identifier、login page等标记或载体。 - 所有浏览器据支持HTTP基本认
1.Linq 执行多列排序 OrderBy的意义是按照指定顺序排序,连续两次OrderBy,后面一个有可能会打乱前面一个的排序顺序,可能与预期不符。 要实现sql中的order by word,name类似效果; LINQ 有ThenBy可以紧接使用, ThenBy记住原本排序的值,然后再排其他值,
ASP.NET Core 核心特性:开源、跨平台、高性能是其决战JAVA的必胜法宝,最引人关注的跨平台特性 到底是怎么实现? &#xA; 本文分Unix、Windows剖析跨平台内幕,读完让你大呼过瘾。
前导 Asynchronous programming Model(APM)异步编程模型以BeginMethod(...) 和 EndMethod(...)结对出现。 IAsyncResult BeginGetResponse(AsyncCallback callback, object state
引言 最近在公司开发了一个项目,项目部署架构图如下: 思路 如图中文本所述,公司大数据集群不允许直接访问外网,需要一个网关服务器代理请求,本处服务器A就是边缘代理服务器的作用。 通常技术人员最快捷的思路是在服务器A上部署IISʺpplication Request Routing Module组件
作为一枚后端程序狗,项目实践常遇到定时任务的工作,最容易想到的的思路就是利用Windows计划任务/wndows service程序/Crontab程序等主机方法在主机上部署定时任务程序/脚本。 但是很多时候,若使用的是共享主机或者受控主机,这些主机不允许你私自安装exe程序、Windows服务程序
引言 熟悉TPL Dataflow博文的朋友可能记得这是个单体程序,使用TPL Dataflow 处理工作流任务, 在使用Docker部署的过程中, 有一个问题一直无法回避: 在单体程序部署的瞬间(服务不可用)会有少量流量无法处理;更糟糕的情况下,迭代部署的这个版本有问题,上线后无法运作, 更多的流
合格的web后端程序员,除搬砖技能,还必须会给各种web服务器配置Https,本文结合ASP.NET Core部署模型聊一聊启用Https的方式。 温故知新 目前常见的Http请求明文传输,请求可能被篡改,访问的站点可能被伪造。 HTTPS是HTTP加上TLS/SSL协议构建的可进行加密传输、身份认
长话短说 前文《解剖HttpClientFactory,自由扩展HttpMessageHandler》主要讲如何为HttpClientFactory自定义HttpMessageHandler组件, 现在来完成课后的小作业: 将重点日志字段显示到Nlog的LayoutRenderer上。 本文实现一个
引言问题 作为资深老鸟,有事没事,出去面试;找准差距、定位价值。 面试必谈哈希, Q1:什么是哈希? Q2:哈希为什么快? Q3:你是怎么理解哈希算法利用空间换取时间的? Q4:你是怎么解决哈希冲突的? Q5:你有实际用写过哈希算法吗? 知识储备 哈希(也叫散列)是一种查找算法(可用于插入),哈希算
前言 如题,有感于博客园最近多次翻车,感觉像胡子眉毛一把抓, 定位不了生产环境的问题。 抛开流程问题,思考在生产环境中如何做故障排除,&#160;发现博客园里面这方面的文章比较少。 .Net 本身是提供了sos.dll工具帮助我们在生产中故障排除,通过提供有关内部公共语言运行时(CLR)环境的信息,
.NET程序是基于.NET Framework、.NET Core、Mono、【.NET实现】开发和运行的 ,定义以上【.NET实现】的标准规范称为.NET Standard .NET Standard .NET标准是一组API集合,由上层三种【.NET实现】的Basic Class Library
长话短说 上个月公司上线了一个物联网数据科学项目,我主要负责前端接受物联网事件,并提供 参数下载。 webapp 部署在Azure云上,参数使用Azure SQL Server存储。 最近从灰度测试转向全量部署之后,日志时常收到: SQL Session超限报错。 排查 我在Azure上使用的是 S
临近年关,搜狗,360浏览器出现页面无法成功跳转,同域Cookie丢失? 也许是服务端 SameSite惹的祸。&#xA;本文揭示由于Chrome低版本内核不识别 SameSite= None, 引发的单点登录故障。
本文聊一聊TraceID的作用和一般组成,衍生出ASP. NETCore 单体和分布式程序中 TraceId 的使用方式
通过给 HttpClint请求的日志增加 TraceId,解锁自定义扩展 HttpClientFacroty 的姿势