在公司网站开发中，判断公司网站源码加密的强弱，不能仅看开发商宣称“用了什么算法”，而要看攻击者实际破解的成本。很多看似复杂的加密，在专业逆向人员面前可能只是“纸糊的”。作为网站维护者，你可以从以下四个核心维度进行实战化评估：

密钥管理：是“真钥匙”还是“摆设”

密钥是加密体系的心脏。如果密钥管理不当，再强的算法也形同虚设。

• 硬编码陷阱：检查前端 JavaScript 源码或后端配置文件中，是否存在写死的密钥（如 key: '123456' 或 SECRET_KEY = 'ctf_key'）。任何人打开网页源代码就能找到密钥，这种加密毫无意义。
• 伪加密检测：部分系统接口虽然接受密钥参数，但该密钥并未真正参与核心加解密运算，仅用于格式校验或生成固定盐值。
  • 黑盒测试方法：提供不同的密钥去加密同一段明文。如果生成的密文完全不变，或者变化规律极弱，说明密钥未实质性参与运算，属于高风险的“伪加密”。
• 密钥随机性：弱密钥（如 password、admin）极易被字典爆破。在 CTF 实战中，约 30% 的加密题目使用的是弱密钥，通过 rockyou.txt 等常见字典即可快速破解。

算法与模式：拒绝“魔改”与过时标准

算法本身的强度和实现方式直接决定了加密的上限。

• 淘汰算法预警：如果系统中仍在使用 DES（56位密钥易被暴力破解）或 MD5/SHA-1（存在碰撞攻击风险），属于弱加密。现代安全场景应优先选用 AES-128/256 或 SHA-256 及以上标准。
• 加密模式隐患：即使使用了 AES 算法，如果采用了不安全的 ECB 模式，相同明文块会生成相同的密文块，导致数据规律泄露。
  • 直观判断：观察加密后的数据，如果明文相似时密文也呈现出明显的规律性重复，极有可能使用了 ECB 模式。
• 警惕“魔改”算法：部分开发商为了“炫技”会对标准算法进行非标修改（魔改）。
  • 验证方法：提取其加密逻辑，使用 Node.js 等环境的标准算法库进行加解密测试。如果能用标准库成功还原明文，说明是标准算法；如果失败且无法通过常规手段还原，说明存在魔改。魔改算法往往缺乏安全审计，极易引入新的漏洞。
• 编码伪装：Base64 仅仅是编码而非加密。如果发现源码只是经过 Base64 转换，使用在线工具瞬间即可还原，这属于最弱的防护。

前端与存储：打破“客户端无秘密”的幻觉

前端代码运行在用户浏览器中，本质上对攻击者是透明的。

• 本地存储审查：打开浏览器开发者工具的 Application 标签页，检查 Local Storage、Session Storage、Cookies 和 IndexedDB。
  • 红线：搜索 token、password、idcard、mobile 等关键词。任何敏感信息如果以明文形式缓存在这里，一旦用户设备丢失或被恶意扩展读取，数据将直接泄露。
• 重放攻击防御：加密不仅防偷看，还要防篡改。
  • 测试场景：使用 Burp Suite 截获一个正常的加密请求（如支付或登录），原封不动地重复发送几十次。如果服务器没有通过“时间戳 + 防重放令牌”机制识别并拒绝重复请求，说明加密参数缺乏完整性保护，黑客可直接复制密文进行重放攻击。

源码加密强弱判定速查表

特别提醒：对于 PHP 等后端源码，单纯的文件加密（如 IonCube、SG11）只能增加逆向成本，无法绝对防止泄露。真正的强防护必须结合服务器权限隔离（Web 用户仅保留读取执行权限，禁止写入）、禁用危险函数（如 exec、shell_exec）以及文件完整性监控。如果服务器被入侵获取了 root 权限，任何源码加密方案都将失效。建议将“加密混淆 + 权限管控 + 运行环境隔离”结合作为立体防御体系。