1 min to read
2024 初中古诗文大赛初赛线上答题网页问题剖析
组委会技术有待提高

作者:icer233 2024-11-09
前言
2024 年初中古诗文大赛初赛线上答题的网页(http://gu.mei94.com/zhong/)存在诸多严重问题。从代码规范到界面设计,从信息录入系统、设备检验方法,再到题库存储和题目顺序生成与存储等方面,都有着令人难以接受的缺陷。
糟糕的代码规范
在查看网页代码时发现,很多变量竟然使用拼音命名,这严重违反了良好的编程规范,降低了代码的可读性和可维护性。
失败的界面设计
该网页仅做了手机端适配,当在电脑端打开时,两边都是空白区域,这种不完善的设计严重影响了用户在电脑上使用的体验。
形同虚设的信息录入系统
信息录入系统存在重大漏洞,它连基本的身份证、手机号格式检验都没有。甚至身份证号输入框能输入字符,这可能导致大量无效信息录入,影响后续流程的准确性。
简陋的设备检验方法
检验是否同一设备答题的信息仅存于 Cookie 里,既没有考虑 IP,也没有检查机器码。这种检验方式更像是检验浏览器,而非设备,使得设备检验功能名存实亡。
存在严重安全隐患的题库储存方法
查看网页源代码后发现,选择题和填空题题库竟然直接储存在源代码里。这种方式极为愚蠢,甚至无需登录就能获取全部题目。
-
选择题在
body > div > div.dan.page.activeTime > div.tiMuWrap > div.tiMuBox
(有选项) -
填空题位于
body > div > div.tian.page > div.tiMuWrap > div.tiMuBox
。
漏洞百出的题目顺序储存方法
选择题题目顺序生成与存储问题
- 选择题的题目顺序生成方式如下:
- 生成包含1 - 150的序号数组
- 使用
_shuffleArray()
函数打乱数组顺序 - 从打乱后的数组中取出前90个序号
- 处理结果
- 储存至
_shufCookdan
变量
填空题题目顺序生成与存储问题
-
填空题的题目顺序生成方式如下:
-
生成包含1 - 50的序号数组
-
使用
_shuffleArray()
函数打乱数组顺序 -
从打乱后的数组中取出前20个序号
-
处理结果
-
储存至
_shufCooktian
变量
-
更糟糕的是,网站在刚打开且用户未填写信息时就已经生成好了题目顺序且没有任何加密。
因此,我们可以在考试开始前,在控制台输入以下代码:
console.log(_shufCookdan)
console.log(_shufCooktian)
通过这种方式,就能提前获得单选题和填空题的题号,再结合题库内容,就可以提前知晓考试内容。而且,这些信息在 Cookie 中也有储存,进一步加大了信息泄露的风险。
惊为天人的与服务器传输数据方法
- 该网页先用
POST
方法向http://gu.mei94.com/zhong/api/?c=setu
发送了用户表单的用户信息, 收到了一个响应包含一个id
和p
,其中id
用于识别用户,并且似乎你是第几个答题的人,id
就是多少,p
也是一个对于每个用户的唯一码,后面用于检测时间等。 - 在选择题答完后用
POST
方法向http://gu.mei94.com/zhong/api/?c=setdan
发送了用户的选择题答案,负载是每一题的用户选择,用户id
和nj
(年级) - 填空题答完后用
POST
方法向http://gu.mei94.com/zhong/api/?c=settian
发送了用户的填空题答案,负载是每一题的用户答案,用户id
和nj
(年级)
这意味你或许可以手动发包直接提交结果而不用一个一个选择(可以在控制台里直接给用户选择列表(_userDanPick
)这个变量赋值,再修改_danId
来跳到特定踢好而不是一个一个按“上一题”和“下一题”)
改进策略
- 解决信息录入验证问题,如需要手机验证码、将身份证等信息发回服务器验证。
- 代码全部使用英文命名。
- 设备检验方面考虑IP等因素,同时与已经提交过的录入信息结合,防止一人多次答题。
- 题库和题目序号全部储存在服务器,每次点击“下一题”时服务器再发包到前端(为了防止网络延迟影响作答,也可以提前一题发)
- 对于题目内容的加密,可以用传统加密方法如AES+字体字符映射(如构建一个字体,如将“一”显示为“二”,使得源代码中的题目内容是乱码,防止用户用selenium等模拟用户操作答题,只能OCR)
或许你认为以上加密方法并不是很强,但是如果能将前面的一人一次的检测做好的话,可以大大加强安全性,因为你没有时间去研究网页原理。
评论