常见前端安全问题概述

随着互联网的高速发展，安全问题已成为企业最关注的焦点之一。而前端又是容易引发安全问题的“窗口”，作为开发人员的我们，更需要充分了解如何预防和修复安全漏洞。本文将列举常见的前端安全问题，希望对你有所帮助。

本文将从以下几种安全问题展开介绍:

• XSS攻击
• CSRF攻击
• SQL注入
• XXE漏洞
• JSON劫持
• XST攻击
• 暴力破解
• 信息泄露
• 其他漏洞

1. XSS攻击

XSS攻击全称跨站脚本攻击（Cross-Site Scripting），为区别CSS，在安全领域叫做XSS。攻击者通过在目标网站上注入恶意脚本并运行，获取用户的敏感信息如 Cookie、SessionID等，影响网站与用户数据安全。

开始这种攻击的案例是跨域的，所以叫做“跨站脚本”。但是发展到今天，由于JS的强大以及网站前端应用的复杂化，是否跨域已经不再重要。但由于历史原因，XSS这个名字却一直保留下来。

本质是恶意代码未经过滤，与网站正常的代码混在一起，浏览器无法分辨哪些脚本是可信的，导致恶意脚本执行。

XSS攻击要素

1. 攻击者提交恶意代码
2. 浏览器执行恶意代码

XSS攻击分类

反射型XSS攻击

反射型XSS只是把用户输入的数据“反射”给浏览器，攻击者往往需要诱使用户操作一个恶意链接，才能攻击成功。反射型XSS也叫做“非持久型XSS”（Non-persistent XSS）

存储型XSS攻击

存储型XSS会把用户输入的数据“存储”在服务器端，这种XSS具有很强的稳定性

比较常见的一个场景就是，黑客写下一篇包含有恶意JS代码的博客文章，发表后，所有访问该博客文章的用户都会在他们的浏览器中执行这段恶意的JS代码。黑客把恶意的脚本保存到服务器端，所以这种XSS攻击就叫做“存储型XSS”

存储型XSS通常也叫做“持久型XSS”(Persistent XSS)

DOM型XSS攻击

DOM型XSS从效果上来说也是反射型XSS，通过修改页面的DOM节点形成XSS，称之为DOM型XSS

实际上，这种类型的XSS并非按照“数据是否保存在服务器端”来划分，单独划分出来，是因为DOM型XSS的形成原因比较特别，发现它的安全专家专门提出了这种类型的XSS。出于历史原因，也就把它单独作为一个分类了。

XSS攻击类型区别

1. 存储型XSS的恶意代码存在数据库里，反射型XSS的恶意代码存在URL里

2. DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端JS自身的安全漏洞，而其他两种XSS都属于服务端的安全漏洞

XSS攻击检测

• 使用XSS攻击字符串手动检测XSS漏洞 github.com/0xsobky/Hac…

• 使用扫描 工具 自动检测XSS漏洞 例如Arachni、Mozilla HTTP Observatory、w3af等

XSS攻击防御

1. 输入输出检查
2. 避免内联事件
3. 富文本类使用标签白名单
4. 增加攻击难度，降低攻击后果
   • 增加验证码，防止脚本冒充用户提交危险操作
   • 通过CSP、输入长度配置、接口安全措施等方法
5. 主动检测发现

针对以上总结的XSS攻击的防御方法，我们再来针对CSP与HttpOnly进行进一步的了解与分析：

• CSP (Content Security Policy)

  1. 禁止加载外域代码，防止复杂的攻击逻辑
  2. 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域
  3. 禁止内联脚本执行
  4. 禁止未授权的脚本执行
  5. 合理使用上报可以及时发现XSS，利于尽快修复问题

• HttpOnly Cookie

  禁止JS读取敏感Cookie，攻击者完成XSS注入后也无法窃取Cookie

XSS攻击带来的不光是Cookie劫持问题，还有窃取用户信息、模拟用户身份执行操作 攻击者利用AJAX构造HTTP请求，以用户身份完成的操作，就是在不知道用户Cookie的情况下进行的。

2. CSRF攻击

CSRF（Cross-site request forgery）跨站请求伪造，攻击者盗用受害人身份，以受害人的名义发送恶意请求。 其本质是重要操作的所有参数都是可以被攻击者猜测到的，攻击者只有预测出URL的所有参数与参数值，才能成功地构造一个伪造的请求；反之，攻击者将无法攻击成功。

CSRF攻击要素

1. 攻击一般发起在第三方网站，被攻击的网站无法防止攻击发生
2. 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作，而不是直接窃取数据
3. 整个过程攻击者并不能获取受害者登录凭证，只是冒用
4. 跨站请求可以是图片URL、超链接、CORS、Form提交等

CSRF攻击防御

1. 阻止不明外域的访问

   • 同源检测
     • 如何判断请求是否来自外域？HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：Origin Header、Referer Header，这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。服务器可以通过解析这两个Header中的域名，确定请求的来源域。
   • Samesite Cookie
     • SameSite-cookies 是Google起草的一份草案来改进HTTP协议，就是为Set-Cookie响应头新增Samesite属性，用来标明这个Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，分别是Strict和Lax：
       • Samesite=Strict：严格模式，表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie，绝无例外
       • Samesite=Lax：宽松模式

2. 提交时要求附加本域才能获取的信息

   • CSRF Token
     1. 将CSRF Token输出到页面中
     2. 页面提交的请求携带这个Token
     3. 服务器验证Token是否正确
   • 双重Cookie验证
     • 用户访问网站页面时，向请求域名注入一个Cookie，前端向后端发起请求时，取出Cookie，添加到URL的参数中，后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。
     • 优点：无需使用Session，适用面更广，易于实施。Token储存于客户端中，不会给服务器带来压力。相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。
     • 缺点：Cookie中增加了额外的字段；如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。难以做到子域名的隔离。为了确保Cookie传输安全，采用这种防御方式的最好确保用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。

CSRF测试

1. 设置浏览器代理
2. 使用合法账户访问网站开始测试
3. 通过CSRF修改并伪造请求
4. 拿到结果如有漏洞进行修复

3. SQL注入

通过Web应用接口注入 SQL 语法，破坏原有SQL结构，达到攻击行为。 如果网站存在注入漏洞，相当于将数据库直接暴露在攻击者面前 根据注入位置及方式不同分分为POST注入、GET注入、cookie注入、盲注、延时注入、搜索注入、base64注入等

SQL注入要素

1. 跳过账户权限验证达到越权
2. 获取数据库关键信息从而进行脱库
3. 特别情况下还可以修改数据库内容，如果数据库权限分配存在问题，攻击者可以通过SQL注入漏洞直接获取webshell或者服务器系统权限

SQL注入防御

1. 数据校验
   • 检查数据格式
   • 使用数据库特定的敏感字符转义函数把用户提交数据进行转义
2. 权限限制
3. 日志处理
   • 数据库操作失败的时，尽量不将原始错误日志返回，如类型错误、字段不匹配等，把代码里的SQL语句暴露出来，以防止攻击者利用错误信息进行SQL注入

4. XXE漏洞

XXE （XML External Entity）外部实体漏洞，当应用程序解析XML输入时，如果没有禁止外部实体的加载，导致可加载恶意外部文件和代码，造成任意文件读取、命令执行、内网端口扫描等攻击。只在能够接收XML格式参数的接口才会出现

XXE漏洞防御

1. 禁用外部实体
2. 过滤用户提交的XML数据

5. JSON劫持

JSON劫持（JSON Hijacking）是用于获取敏感数据的一种攻击方式，属于CSRF攻击的范畴

JSON劫持防御

1. X-Requested-With标识
2. 浏览器JSON数据识别
3. 禁止JS执行JSON数据

6. XST攻击

XST攻击（cross-site tracing）当Web服务器启用TRACE时，提交的请求头会在服务器响应Body中完整返回，其中HTTP头很可能包括Session Token、Cookies或其它认证信息，攻击者可以利用漏洞获取用户信息

XST攻击防御

禁用HTTP TRACE方法

7. 暴力破解

弱密码（Weak Password）被他人猜到或被破解工具暴力破解

暴力破解防御

1. 增加密码复杂度
2. 限制尝试次数