关于前端安全性

罗密欧与猪过夜YY
552 阅读6分钟

  • 昨天看了个大佬的文章，讲述的是一个无感刷新token，我觉得挺实用的，随后顺着大佬研究的再深入了下，发现有点牵扯到安全性，于是上网搜了下，也想当个笔记记录下。

  • 先粘贴一下这个网站，我觉得这个能作为一个面试中HR问你项目中的难点来讲出Token过期怎么办？6年老前端教你自动续期的骚操作！

  • 里面有讲到过HttpOnly + Secure，不了解这个是啥，所以我这边打算出个文章了解一下。

  • 在前端开发中，“Secure” 通常与 前端安全（Frontend Security）  相关，指的是保护前端应用、用户数据及交互过程免受各类安全威胁的技术、策略和实践。前端作为用户直接交互的层面，是安全防护的第一道防线，其安全性直接影响用户体验和数据安全。

前端安全的核心目标

  • 防止恶意攻击者通过前端漏洞窃取用户数据（如账号、密码、个人信息）。
  • 阻止攻击者篡改页面内容、注入恶意代码或诱导用户执行非预期操作。
  • 确保前端与后端的通信过程安全，避免数据在传输中被拦截或篡改。

常见的前端安全威胁及防护措施

1. XSS（跨站脚本攻击，Cross-Site Scripting）

原理：攻击者在页面中注入恶意脚本（如 JavaScript），当用户访问页面时，脚本被执行，从而窃取 Cookie、劫持会话或篡改页面内容。
分类：

  • 存储型 XSS：恶意脚本被存储到服务器（如数据库），用户访问时从服务器读取并执行（如论坛评论、用户资料）。

  • 反射型 XSS：恶意脚本通过 URL 参数等方式传递给服务器，服务器 “反射” 回页面并执行（如搜索框、URL 参数展示）。

  • DOM 型 XSS：恶意脚本通过修改页面 DOM 结构直接执行，不经过服务器（如利用document.write、innerHTML等 API）。

防护措施：

  1. 输入过滤：对用户输入的内容（如表单、评论）进行严格校验，过滤或转义特殊字符（如<、>、&、"等）。
  2. 输出编码：在页面渲染用户输入内容时，使用 HTML 编码（如将<转为&lt;）、JavaScript 编码等，避免脚本被解析执行。
  3. 使用 CSP（内容安全策略，Content-Security-Policy） ：通过 HTTP 响应头限制页面可加载的资源（如脚本、样式、图片的来源），禁止执行未授权的脚本（例如：Content-Security-Policy: default-src 'self' 仅允许加载本站资源）。
  4. 避免使用危险 API：如eval()、innerHTML（优先用textContent）、document.write()等，减少脚本注入风险。

总结：碰到XSS攻击，避免使用敏感的输入API，用户输入的东西全部进行过滤和转义

2. CSRF（跨站请求伪造，Cross-Site Request Forgery）

原理：攻击者诱导已登录的用户在不知情的情况下，向目标服务器发送恶意请求（如转账、修改密码）。由于请求携带用户的合法 Cookie，服务器可能误认为是用户主动操作。 防护措施：

  1. Token 验证：前端请求时携带后端生成的唯一 Token（如 CSRF Token），服务器验证 Token 合法性（Token 需与用户会话绑定，且不可预测）。

  2. SameSite Cookie 属性：在 Cookie 中设置SameSite=Strict或SameSite=Lax，限制 Cookie 仅在同站请求中携带，阻止跨站请求使用 Cookie。

  3. 验证 Referer/Origin：服务器检查请求的Referer或Origin头，确保请求来自可信域名。

  4. 二次验证：对于敏感操作（如转账），要求用户再次输入密码或验证码。

总结：碰到CSRF攻击，需要生成唯一的 CSRF Token 随后在进行请求中进行头部验证，碰到敏感操作需要使用验证码或者二次验证

3. 点击劫持（Clickjacking）

原理：攻击者通过 iframe 嵌套目标网站，并用透明层覆盖在恶意页面上，诱导用户点击 “看似安全” 的按钮，实际触发目标网站的敏感操作（如点击 “点赞” 实际执行 “删除账号”）。

防护措施：

  1. X-Frame-Options 响应头：服务器返回X-Frame-Options: DENY（禁止任何网站嵌套）或X-Frame-Options: SAMEORIGIN（仅允许同域名嵌套）。

  2. Content-Security-Policy（CSP） ：通过frame-ancestors 'self'限制 iframe 的父级域名，仅允许可信域名嵌套。

  3. 前端检测：通过 JavaScript 判断页面是否被嵌套在 iframe 中（如top !== self），若被嵌套则隐藏内容或提示风险。

总结：本来不想写这个的，但是我目前的项目确实在使用iframe嵌套，也就把这个带上了，直接就服务器返回X-Frame-Options: DENY禁止出现嵌套。

4. 敏感信息泄露

风险：前端存储或传输敏感信息（如密码、Token、银行卡号）时，可能被攻击者通过调试工具、网络抓包或本地存储窃取。

防护措施：

  1. 禁止在前端存储敏感信息：如密码、私钥等，应仅在后端存储，前端仅临时使用（如登录时的输入框）。

  2. 敏感数据传输加密：使用 HTTPS 协议（加密传输），避免 HTTP 明文传输。

  3. 对本地存储（LocalStorage/SessionStorage）内容加密：若必须存储非敏感数据（如用户昵称），可通过对称加密（如 AES）处理后再存储。

  4. 避免在 URL 中暴露敏感信息：URL 可能被记录在日志、浏览器历史中，禁止将 Token、用户 ID 等放入 URL 参数。

总结：这个挺有意思的，直接前端关于用户密码啊什么的就不要存储了，如果需要的话就加密，比如传输加密用HTTPS协议，然后放在Storage的缓存数据的话使用AES处理。

5. 依赖包安全

风险：前端项目依赖的第三方库（如 npm 包）可能存在已知漏洞（如通过npm audit可检测），攻击者可能利用这些漏洞注入恶意代码。

防护措施：

  1. 定期更新依赖：使用npm update或yarn upgrade更新到安全版本，避免使用长期未维护的库。

  2. 依赖审计：通过npm audit、snyk等工具检测依赖漏洞，并修复高风险问题。

  3. 最小化依赖：仅引入必要的库，减少攻击面。

总结：直接用 npm audit 进行监测，最小化依赖都是大家程序员的基本功了，更新依赖这种操作，我觉得我们程序员如果没什么非必要，代码能跑就不要动了

总结

  • 其实我面试的时候还真有Hr问过关于安全性的问题，但是我没放在心上，因为工作中写的项目大部分都是不对外的，今天偶然看见了个文章然后思索了后觉得自己缺少这方面的知识，还是补救一下比较好，如果你觉得这篇文章内容太多了，那就直接记住我总结的话去应答，这肯定是没问题的。
avatar
文章
阅读
粉丝