关于网络投票—小回顾

  • 内容
  • 评论
  • 相关

最近圣诞节来临,公司做活动,写了一个关于网络投票的小程序,当时只当一般,因为实属小众,几十个家庭的追逐投票而已,现在回想起来蛮有意思的,特意写下来回顾一下

使用环境要求:支持移动端,应用场景:小众,几十个家庭,活动时间十天,

初始印象, 这是一个很小的需求,然而这期间发生很多小事件,让它变得很值得回味...

架构上并没有什么特殊,只有一个要求,投票一人一天只能投一票

于是一个搭配浏览器缓存锁,IP锁的投票小程序编写完成了。

投入使用  :

第一个尴尬的问题诞生了

程序转给运作活动的同事,反馈问题 , IP锁对局域网锁定,现今大多数人都习惯于使用WiFi局域网了,但80%的WiFi局域网,对外访问都是一个公网IP,于是同一个环境下,出现一个问题,只有一个IP ,而一个IP只能投一票,你投了这个人,那么局域网内其他人就都被IP锁拒绝投给这个人,因为这个IP今天已经投过了。。这个其实对使用者关系网人脉圈的分享杀伤性很大,不利于传播,经过解释,为了防止被刷票而加上的IP锁,切换回手机移动网络就好

第二天上午,老板过来了解活动情况,试用一下,很不巧,点投票,程序提示已经投过,老板就说,我什么都没投怎么就已经投了,于是我一看WiFi,和老板同一WiFi下,我已经投过了。于是再和老板解释一遍这个IP锁问题,以及为什么这么做。最后协商去掉IP锁,因为这极其不利于办公室传播,同WiFi环境传播,只保留了浏览器缓存锁。

当然这其中的风险也阐述了,刷票几率不大,我们这次投票活动,只是针对几十个家庭而已,一般家庭应该并不懂得如何清除缓存,进行重投

 

于是第二个尴尬的问题诞生了

下午活动运作同事,告诉我,刷票了,几个人票数直往上涨,她们也能刷,可以一直投下去,于是我又重启IP锁,刷票情况稳定下来了,这方案并不友好,因为WiFi局域网传播确实是这种小众性质投票的主要传播方式和场所,于是我在浏览器缓存锁的基础上改进了IP锁,IP锁半解锁,同IP可以允许三次投票,这主要是为方便WiFi局域网传播投票,实验成功,使用也没问题,第二阶段算是过了

 

第三个尴尬来了

第二天,活动运作的同事反馈了,票数又有些刷了,另她可以投多票,当时我只想说现在的浏览器真给力,可以直接拒绝浏览器缓存写入,不写入就可以拒绝浏览器缓存锁,于是分给局域网的三票,等于一人刷了,票数又有些不正常化,直接禁了,换回最初的IP锁,死循环,无解了

 

解决方案:

这时有人和我说使用微信授权登录,这也就是登录锁,登录锁能完美解决当前遇到的问题,但这其实也并不友好,操作复杂度上升,整个移动端支持,需要重写登录模块,另外需要注册才行,仅微信支持,缩小使用范围了,家里老人使用可能性大幅削减,另已投入使用,变更成本急剧上升...

于是继续维持初版浏览器缓存锁,IP锁现状。

 

虚惊一场:

活动中期,运作那边又反馈了,又刷票了,一些人的票数猛然增长几十票,我核查投票IP现状,散乱无序,无重复,都是有效投票,数据并无问题,大概是某个群里传播出来的,如此反馈回去。。

 

真刷票了:

周末,反馈又刷票了,我当时在想,以现在的程序基础,不可能再出现刷票了,因为没有那么多IP,可是一个人的票数确实猛增了几百,再次核查,真实投票IP确实有几百,并无问题,细看,有问题。。。这次的投票IP大都集中于几个大的IP段,也就是说这些IP来源于某个机房,抑或者从某一个局域网一个一直变动的对外IP发出,不得不说遇上行家了,不过还好,属于一般性黑客或者某些IT技术达人,不算真正的高手,编写了一个IP地址段识别拦截,同IP段,增加投票锁定,于是这个算是过去了...

 

后续:

这些能拦住90%的人,包括一些一般性的黑客,技术达人什么的,但却拦不住那剩下的10%的高手,他们或许有很多的真实IP,抑或者会利用通信底层协议伪造真实IP,但这10%的人,我想应该不会用那些IP来干这件事,因为投入成本与收益完全不成比例,毕竟这只是一个几十个家庭参与的小型活动而已。

 

小小活动,没想到遇到这么多事情,下一次也许该慎重架构了!!!

 

 

-------------------------------------------------------------------------------------------------------------------

 

关键点备忘:

关于入侵的核心 ----- 入口 ,内部处理, 出口

关于前后端通信  ------ JSON状态通用协议: 状态码 ;问题描述;  数据   ---- 反欺骗的艺术

关于锁------缓存锁   I P锁    I P段半解锁   时间锁    长度锁  登录锁

已存在数据分析  ------反防备

HTTP报头信息的有效性判断------报头标示判断  ,  (来源判断----是否存在来源页)  ---防备脚本攻击

真实IP伪造,与之同步的DDos攻击:

PS:    获取页面来源IP 即可防备基于Http 层的IP伪造

UDP层面的真实IP伪造,难度几十倍上升,基于路由安全策略过滤,可以屏蔽一般性伪造,真实IP返回响应也会向真实IP转移,DDos丢失攻击.....

 

其实在登录锁拦截之下还有验证码拦截,验证码拦截,能解决所有没有跨过验证码手段的脚本刷票,但对于投票而言这样的用户体验并不友好。。。

 

 

 

 

 

 

 

评论

0条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注