急需求解html密码验证并实现页面跳转
急需求解HTML密码验证并实现页面跳转
上周帮朋友改一个静态站点,急需他提了个需求:给某个页面加个密码框,求解输对了跳转到下载页,密码面跳输错了给个提示。验证听起来简单,并实但他之前找人写的现页代码直接用明文密码写在JS里,任何人右键查看源代码就能看到。急需他问我有没有稍微体面一点的求解方案。
先说清楚一件事:纯前端的密码面跳密码验证,本质上没有安全性可言。验证只要密码逻辑跑在浏览器里,并实有心人总能扒出来。现页但如果你的急需目的只是“别让随便点进来的人看到内容”,而不是求解对抗真正的攻击者,那用HTML+JS确实能应付。密码面跳
最粗暴的写法是这样:
<input type="password" id="pwd"> <button onclick="check()">进入</button> <script> function check(){ var v = document.getElementById('pwd').value; if(v === 'abc123'){ window.location.href = 'target.html'; } else { alert('密码错误'); } } </script> 这段代码能用,但问题很明显。密码暴露在源码里,而且alert弹窗体验很差。我朋友那个页面是给客户预览用的,弹个系统警告框显得特别业余。
稍微改进一下,可以把提示信息渲染到页面上,而不是用alert。再给回车键加个监听,用户体验会好很多:
<input type="password" id="pwd" placeholder="请输入访问密码"> <p id="msg" style="color:red;"></p> <button id="btn">确认</button> <script> var pwd = document.getElementById('pwd'); var msg = document.getElementById('msg'); var btn = document.getElementById('btn'); function verify(){ if(pwd.value === 'abc123'){ location.replace('target.html'); } else { msg.textContent = '密码不对,再试试'; pwd.value = ''; pwd.focus(); } } btn.addEventListener('click', verify); pwd.addEventListener('keydown', function(e){ if(e.key === 'Enter') verify(); }); </script> 这里用了location.replace而不是href,好处是跳转后用户按返回键不会回到密码页。对于“一次性通过”的场景,这个细节挺重要。
但密码还是明文。怎么办?可以做个简单的哈希。浏览器有原生的crypto API,用SHA-256把用户输入转成哈希值,再跟预设的哈希比对。这样源码里看不到原始密码:
async function sha256(str){ var buf = new TextEncoder().encode(str); var hash = await crypto.subtle.digest('SHA-256', buf); return Array.from(new Uint8Array(hash)) .map(b => b.toString(16).padStart(2,'0')).join(''); } async function verify(){ var h = await sha256(pwd.value); if(h === '预设的哈希值'){ location.replace('target.html'); } else { msg.textContent = '密码不对,再试试'; } } 你可以先在控制台算好密码的SHA-256值,把那个字符串硬编码进去。这样别人查看源码只能看到一个哈希,没法直接反推出密码。当然,理论上彩虹表能撞出来弱密码,但对付一般场景足够了。
还有一个坑要注意:如果你的页面是用file://协议直接打开的,crypto.subtle在某些浏览器里会返回undefined。必须走http或https才行。本地测试的话,起个简单的服务器,比如python -m http.server,就能解决。
另外,跳转目标页本身也得做点防护。如果target.html是公开可访问的,那别人直接输URL就绕过了密码页。纯静态方案没法根治这个问题,但可以加一层referrer检查,或者把目标内容也做一次轻量验证。真要安全,还是得上后端。
我最后给朋友的方案就是SHA-256哈希比对加location.replace,页面提示用DOM操作,回车键绑定。他看完说够用了,反正只是防同事误点,不是防黑客。这话说得实在——技术方案从来都是看场景的,脱离需求谈安全没意义。
相关文章
360又爆高危漏洞了。这次不是那种“理论上可能被利用”的唬人玩意儿,是实打实能让你电脑裸奔的那种。安全研究员把漏洞细节挂出来的时候,我第一反应是:得,又是它。 漏洞出在360安全卫士的“主动防御”模块2026-10-17
我见过太多老板花大价钱做了个漂亮网站,然后往那儿一扔,跟供财神似的。三个月后一看后台,访问量个位数,那数字比他们公司当月的销售报表还寒碜。网站不是名片,是个24小时营业的推销员——可你把这推销员锁在屋2026-10-17
信息安全专业的排名,说到底拼的是三样东西:师资、实战资源、以及学校能给你的起点。 清华和上交大稳坐第一梯队,这没什么悬念。清华的网安研究院背靠信息学院,密码学、系统安全方向有院士坐镇,学生大一就能进实2026-10-17
一个分号,一个单引号,一次条件判断的改写,就能让数据库把不该说的话全吐出来。sql注入点不是漏洞,是程序员的自信留下的后门。 我在一个老牌电商后台见过最典型的案例。登录框,用户名密码,看起来人畜无害。2026-10-17
内部网站这事,真不是买台服务器、装个WordPress就能糊弄过去的。我见过太多公司,花两周搭出来的"内部网",最后沦为没人看的电子公告栏——上面挂着三年前的年会照片,和一份永远没人更新的通讯录。 先2026-10-17
我花了三个小时,就为了把公司电脑上的一个网页端口暴露到公网。路由器设置改了十遍,防火墙规则加了八条,最后发现运营商把80端口封得死死的。那晚我盯着屏幕上的“连接超时”,突然意识到——内网穿透这玩意儿,2026-10-17

最新评论