核心概念
这么多年的开发中,没有关注过前端安全的问题,只是又简单的一点点的认知,直到面了一家很注重安全的公司,面试结束很讽刺的对我说了句,大环境不好,还是不要换工作了。 你要说能用到多少,看公司项目了,但是下面这些起码还是记着比较好
攻击方式 | 简要说明 | 主要防御手段 |
---|---|---|
跨站脚本攻击(XSS) | 攻击者向网页注入恶意脚本,在用户浏览器中执行以窃取信息或进行恶意操作。 | 输入过滤与转义、内容安全策略(CSP)、避免使用危险的API(如 innerHTML )、HttpOnly Cookie。 |
跨站请求伪造(CSRF) | 攻击者诱导用户在已登录目标网站的情况下,访问恶意网站并发起非预期的操作请求(如转账)。 | CSRF Token、SameSite Cookie、校验请求来源(Referer/Origin)。 |
点击劫持(Clickjacking) | 攻击者通过透明iframe覆盖恶意按钮在合法页面上,诱导用户点击。 | 设置 X-Frame-Options 响应头、使用 CSP 的 frame-ancestors 指令。 |
第三方依赖风险 | 引入的第三方库或组件可能存在已知漏洞,被利用来攻击用户。 | 定期使用 npm audit 或 yarn audit 检查漏洞、最小化依赖、锁定版本。 |
本地存储泄露 | 敏感数据(如Token)存储在localStorage中,可能被XSS窃取。 | 优先使用HttpOnly Cookie存储敏感信息、如需本地存储则进行加密。 |
开放重定向(Open Redirect) | 网站接受用户控制的输入作为重定向目标,诱导用户跳转到钓鱼网站。 | 对重定向目标URL进行白名单校验、避免直接使用用户输入构造跳转链接。 |
JSONP劫持 | 通过未授权的JSONP接口窃取用户的敏感数据。 | 减少JSONP接口的使用(推荐使用CORS机制)、在服务器端对数据请求进行认证。 |
关键原理
XSS跨站脚本攻击
XSS攻击的本质是注入,攻击者将恶意脚本注入到网页,并在浏览器中执行。XSS攻击可以分成下面几类:
- 存储型XSS: 存储在服务器上的恶意脚本,如何实现呢,想想论坛的评论区
- 反射型XSS:作为URL参数的一部分的恶意脚本,发送到服务器后立即反射回浏览器执行,常见的是钓鱼链接
- DOM型XSS:修改页面的DOM来执行恶意脚本 可以看到这种攻击方式就是不加判断的执行一些东西,不管是服务器获取的内容还是DOM树上获取的,从这种攻击方式来思考如何防御
- 输入过滤和输出转义:对用户的输入进行严格的验证和过滤,并对输出到页面的内容进行转义
- 内容安全策略CSP :通过http响应头
Content-Security-Policy
限制页面中脚本,样式等资源的加载来源,从根本上防止非法脚本的执行 - 谨慎操作DOM :慎用
innerHTML
,eval()
,document.write()
这种就不要用了,也不好用 - 设置Cookie为httpOnly:防止JavaScript读取隐私信息
跨站请求伪造CSRF
CSRF利用的是每次请求都会默认携带Cookie,当我们登录了一个正常的网站
,并在不知情的情况下有访问了危险的网站
,利用携带Cookie的机制,危险的网站
获得我们的用户的信息,并伪装成我们正常的用户
,对正常的网站
进行攻击 知道了攻击方法,应对方式也就应运而生了
- CSRF Token:我们和正常网站的每一次请求都携带一个约定好的Token,嵌入表单或者请求头,服务器每次请求验证此Token,不合法的拒绝
- SameSite Cookie :设置Cookie的SameSite属性
- Strict:完全禁止第三方的Cookie
- Lax:允许在安全跨站请求中携带Cookie,平衡安全和用户体验的默认推荐方式
- 校验请求来源:检查HTTP请求头中的Origin或Referer字段,判断请求来源合法
点击劫持
使用一个透明的IFrame诱骗用户在不知情的情况下触发目标网站的操作 了解他,防御他
- 设置X-Frame-Options响应头
- DENY:页面不能被任何iframe嵌入
- SAMEORIGIN:页面只能被同源网站嵌入
- 使用CSP的frame-ancestors指令:更精细的控制允许哪些页面嵌套当前页面,可配置多个,更灵活,兼容性更好
图表
