WHAT – 前端安全性测试和常见攻击手段

目录

• 一、安全性测试
• 二、前端安全性测试
• 三、跨站脚本（XSS）攻击
• • 1. 介绍
  • 2. 三大类型
  • • 反射型 XSS（Reflected XSS）
    • 存储型 XSS（Stored XSS）
    • DOM 型 XSS（DOM-based XSS）
  • 3. xss 盲打
  • 4. xss 水坑攻击：XSS Watering Hole Attack
  • 5. 防范措施
• 四、跨站请求伪造（CSRF）
• • 1. 介绍
  • 2. 防范措施
• 五、身份认证机制现状
• 六、任意文件上传
• • 1. 介绍
  • 2. 防范措施

一、安全性测试

安全性测试，指有关验证应用程序的安全等级和识别潜在安全性缺陷的过程。

比如对于应用程序，安全测试的主要目的是：查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力。

常规测试方法：

• 基于风险的安全测试：信息搜集->威胁建模->可用性分析
• 白盒测试（找出潜在安全性缺陷的最有效的方法）：内部攻击，测试人员可以访问源代码、设计文档，可以进行威胁建模或逐行代码检查
• 黑盒测试：以局外人的身份对系统进行攻击，使用工具检查系统的攻击面，并探查系统的内部信息
• 灰盒测试：组合使用白盒测和黑盒测试。程序开发中的调试运行是典型的灰盒测试方法

二、前端安全性测试

前端项目的安全性测试需要关注以下几个方面：

1. 跨站脚本（XSS）攻击防范：确保输入验证和输出编码以防止恶意用户注入脚本。

2. 跨站请求伪造（CSRF）保护：使用随机生成的令牌验证请求的来源，以防止未经授权的请求。

3. 内容安全策略（CSP）：配置浏览器只加载信任的资源，防止恶意脚本的执行。

4. 跨域资源共享（CORS）设置：限制跨域请求，确保仅受信任的域可以访问资源。

5. 敏感数据保护：在传输和存储敏感数据时使用加密，避免敏感信息泄露。

6. 认证和授权：实现安全的用户身份验证和授权机制，确保用户只能访问其有权限的资源。

7. 安全的第三方库和依赖管理：定期更新和审查使用的第三方库，以确保不受已知漏洞的影响。

8. 安全的前端框架和组件：选择安全可靠的前端框架和组件，避免使用存在漏洞或不安全的工具。

通过这些方面的测试和实施安全措施，可以提高前端项目的安全性，保护用户和数据免受恶意攻击。

三、跨站脚本（XSS）攻击

1. 介绍

XSS，Cross Site Scripting，跨站脚本攻击。

XSS 攻击通常指利用网页开发留下的漏洞，将恶意代码注入网页中，使用户加载并执行攻击者的程序。

具体来说，攻击者利用网页提供的输入能力，将攻击脚本构造 HTML 输出，并提交给后台服务。当后台服务在某些场景下将该内容返回其他正常用户时，由于给动态页面中插入的内容含有特殊字符（如 < ）时，用户浏览器会将其误认为是插入了 HTML 标签，尤其当引入了一段 JavaScript 脚本 "


用户收到这条信息后，可能会因为担心账户安全而被吸引点击链接。当用户点击链接时，浏览器会向目标网站发送一个带有恶意脚本的请求，其中包含在 URL 参数中的 JavaScript 代码。

目标网站可能会验证用户的登录信息，然后将恶意脚本反射到返回给用户的页面中。用户的浏览器会执行这个恶意脚本，导致弹出一个对话框，显示 “XSS Attack!”。

这种方式下交互的内容一般不会存在数据库里，一次性的。

存储型 XSS（Stored XSS）

在存储型 XSS 攻击中，恶意脚本被用户无意中将其存储在网站的数据库或文件系统中，然后在其他用户访问页面时请求从存储位置检索到包含这些恶意脚本的数据，并在浏览器被执行。这种攻击通常需要攻击者能够向网站提交恶意内容，比如在评论框或表单中注入恶意脚本。

举个例子，假设一个网站有一个留言板功能，允许用户发布评论。攻击者利用这个功能，发布了一个包含恶意脚本的评论，比如：

该评论被存储在网站的数据库中。当其他用户加载包含该评论的页面时，恶意脚本将从数据库中检索并在其浏览器中执行，导致弹出一个对话框，显示 “XSS Attack!”。

这种方式下交互的内容会被存储在数据库里，并永久性存储。

DOM 型 XSS（DOM-based XSS）

在 DOM 型 XSS 攻击中，恶意脚本通过修改页面的 DOM 结构来执行，而不是通过服务器返回的响应或存储在数据库中的数据。这种攻击通常涉及恶意脚本被存储在 URL 中，并由客户端的 JavaScript 动态解析执行的攻击形式。

举个例子，假设一个网站有一个搜索功能，会通过 JavaScript 获取 URL 参数进行自动填充搜索，并将其动态插入到页面中的某个元素中。攻击者可以构造一个恶意 URL，比如：

http://www.example.com/search?q=

当用户访问这个 URL 时，页面中的 JavaScript 将获取并解析 URL 中的参数，并将其插入到页面中的某个元素内。由于参数中包含恶意脚本，因此该脚本将被动态执行，导致弹出一个对话框，显示 “XSS Attack!”。

这种方式不与后台服务器产生内容的交互，而是一种通过一次性 DOM 操作进行攻击。

3. xss 盲打

简单来说，盲打就是在一切可能的地方（留言区、feedback等）尽可能多的提交 xss 攻击语句，然后看哪一条会被管理员执行，就能获取管理员的 cooike。比如在输入框输入提前准备的 xss 代码，通常是使用 标签引入远程的 JavaScript 代码，当有管理人员审核提交数据时候，并且点击了提交的数据，就很可能触发获取到有价值的敏感信息。

4. xss 水坑攻击：XSS Watering Hole Attack

来源于鳄鱼埋伏攻击来水边喝水的动物。

水坑攻击，其针对的目标多为特定的团体（组织、行业、地区等），攻击者首先通过猜测（或观察或分析）确定这组目标经常访问的网站，并入侵其中一个或多个，植入恶意软件，最后，达到感染该组目标中部分成员的目的，由于此种攻击借助了目标团体所信任的网站，攻击成功率很高。

XSS 水坑攻击是一种利用受害者经常访问的合法网站或网络服务来进行攻击的策略。攻击者会将恶意代码植入到一个受害者经常访问的网站中，通常是通过对网站的漏洞进行利用或注入恶意脚本来实现。

以下是一个可能的场景：

假设某个组织的员工经常访问一个特定的在线论坛，攻击者意识到这一点，并利用论坛的漏洞或弱点，在论坛的页面中植入了恶意代码，比如一个恶意的 JavaScript。这个 JavaScript 代码可能会窃取用户的登录凭据、会话令牌或其他敏感信息，然后将其发送给攻击者的服务器。

当员工继续访问论坛时，他们的浏览器会加载论坛页面并执行其中的恶意 JavaScript 代码。攻击者因此能够获取受害者的敏感信息，从而导致严重的安全问题。

XSS 水坑攻击的特点是攻击者利用受害者的习惯性行为来实施攻击，并通过植入恶意代码到受害者经常访问的合法网站中，从而使攻击更具隐蔽性和成功率。

5. 防范措施

防御 XSS 攻击是网站开发中至关重要的一环，以下是一些常见的防御措施：

1. 输入过滤和转义： 对用户输入的数据进行过滤和转义是防御 XSS 攻击的基本手段。网站开发者应该在接收用户输入数据之后，对其进行严格的过滤和转义，以确保用户输入的内容不包含恶意脚本。常见的转义方法包括将特殊字符转换为对应的 HTML 实体，比如将 < 转义为 <。

2. 严格的输入验证： 在接收用户输入数据之前，进行严格的输入验证，确保输入的数据符合预期的格式和类型。这可以有效地防止攻击者通过构造特殊的输入数据来绕过过滤和转义的防御措施。比如一个文本框接受的是一个标准的邮政编码，那唯一有效的输入即 0-9 数字类型，并且长度应该是 6.

3. 内容安全策略（CSP）： CSP 是一种通过定义允许加载的资源策略来防御多种类型的攻击，包括 XSS 攻击。开发者可以通过在 HTTP 响应头中设置 CSP 来限制页面可以加载的资源来源，从而阻止恶意脚本的注入和执行。

Content-Security-Policy: default-src 'self' https://trusted-domain.com; script-src 'self' https://trusted-scripts.com; style-src 'self' https://trusted-styles.com;

在这个示例中，default-src 指令指定了默认的资源加载策略，script-src 指令指定了可以加载 JavaScript 的来源，style-src 指令指定了可以加载样式表的来源。每个指令后面的值指定了允许加载资源的域名或 URL。

4. 设置 HttpOnly 标志： 将 Cookie 的 HttpOnly 标志设置为 true 可以防止 JavaScript 代码访问该 Cookie，从而有效地防止了 XSS 攻击中的 Cookie 窃取行为。这样，即使攻击者成功注入了恶意脚本，也无法通过 JavaScript 代码来读取或修改用户的 Cookie。

5. 安全的开发实践： 开发者应该采用安全的编程实践，避免在页面中直接使用用户输入的数据作为 JavaScript 代码的一部分，尤其是不应该使用 eval() 函数或 innerHTML 属性来执行动态生成的 HTML、JavaScript 代码。

综上所述，通过结合以上多种防御措施，网站开发者可以有效地保护其网站免受 XSS 攻击的危害。

四、跨站请求伪造（CSRF）

1. 介绍

CSRF，Cross-Site Request Forgery，是一种常见的网络安全攻击，攻击者通过伪造用户的身份，向网站发送恶意请求，以执行未经授权的操作。

攻击者通常会利用用户已经登录的状态，通过欺骗用户访问包含恶意请求的页面，或者在用户浏览器中执行恶意脚本，使得用户在不知情的情况下发起了对受害者账户的请求操作。这些操作可能包括修改个人信息、发起资金转账、更改密码等。

由于浏览器曾经认证过，所以被访问的后台会认为是真正的用户操作发起的请求，这利用了web中用户身份认证的一个漏洞：简单的cookie身份验证只能保证用户发自某个用户的浏览器，并不能保证请求本身是用户自愿发出的。

下面是一个详细的例子，说明了 CSRF 攻击的过程和如何利用用户登录状态来伪造请求：

1. 假设用户已经登录到其银行账户，并在该银行的网站上保持了登录状态。

2. 攻击者在另一个网站上发布了一个帖子，帖子内容包含一个图片标签 。这个图片标签的 src 属性指向了攻击者模仿的银行网站上的一个转账请求，将1000美元转账到攻击者的账户。

3. 当用户被某些手段吸引到这个网站时，浏览器会自动加载这个帖子中的图片，并向银行网站发送一个转账请求。

4. 由于用户仍然保持在银行网站上的登录状态，浏览器会自动发送用户的登录凭证（比如 Cookie）给银行网站。银行网站会认为这个请求是合法的用户操作，并执行转账操作。

5. 如此，攻击者成功地利用了用户的登录状态，伪造了一个转账请求，将1000美元转入了攻击者的账户，而用户在不知情的情况下完成了这次转账操作。

通过这个例子，我们可以看到，攻击者利用用户已经登录的状态，在用户不知情的情况下发送了恶意请求，从而实现了对用户账户的非法操作。这就是 CSRF 攻击的基本原理。通俗来讲，这就利用了 web 场景中用户身份认证的一个漏洞：简单的 cookie 身份验证仅仅能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

利用条件：

• 已知目标网站的请求格式
• 发起的 http 请求可事先构造

2. 防范措施

主要是使得请求不可伪造：

• 利用 SameSite Cookie。如设置为 lax，允许服务器要求某个 cookie 在跨站 post 请求时不会被发送
• Token 机制验证。即以 token 来进行身份信息验证，一般是设置在请求头 Authorization: Bearer ${accessToken}
• HTTP Refer 验证。即验证请求来源。如果是非正常页面过来的请求，则极有可能是 CSRF 攻击
• 验证码。在表单中添加一个验证码功能，通过强制真实用户和应用进行交互，来有效地遏制 CSRF 攻击
• …

五、身份认证机制现状

通过上面的学习，我们知道常见攻击手段目标都是涉及 Cookie 的获取。

在早期，开发者会使用 Cookie 进行登录验证，这存在一些安全问题，主要包括以下几点：

1. 会话劫持：恶意攻击者可以窃取用户的 cookie，包括用于身份验证的会话 cookie。一旦攻击者获取了有效的会话 cookie，他们就可以冒充用户，访问用户的账户，并执行各种操作，比如修改用户资料、发送消息等。
2. XSS 攻击：如果网站存在 XSS 漏洞，攻击者可以注入恶意脚本来窃取用户的 cookie。一旦攻击者成功注入了恶意脚本，他们就可以获取用户的 cookie，并进一步进行会话劫持等攻击。
3. 跨站请求伪造（CSRF）：攻击者可以利用 CSRF 攻击来伪造用户的请求，以用户的身份执行某些操作，而不需要知道用户的凭证。如果网站使用基于 cookie 的身份验证，那么攻击者可以利用用户的活动会话来发送恶意请求，从而执行未经授权的操作。

虽然很多网站在登录验证上已经转向了更安全的方法，比如使用基于令牌（token）的认证机制，但这并不意味着 XSS 攻击等攻击手段不再构成威胁，他们仍可以获取其他类型的敏感信息。因此，即使网站采用了更安全的登录验证方式，也不应忽视对 XSS 等攻击的防范。继续实施安全的编码实践、定期审查和更新代码、以及使用安全框架和工具来防止 XSS 等攻击仍然是至关重要的。

六、任意文件上传

1. 介绍

上传漏洞这个顾名思义，就是攻击者通过上传木马文件，直接得到WEBSHELL，危害等级超级高，现在的入侵中上传漏洞也是常见的漏洞。

导致该漏洞的原因在于代码作者没有对访客提交的数据进行检验或者过滤不严，可以直接提交修改过的数据绕过扩展名的检验。

上传的文件包括：

1. 木马
2. 病毒
3. 恶意脚本
4. WebShell
5. …

2. 防范措施

1. 系统开发阶段的防御

a. 校验文件后缀名，使用白名单方式只允许图片、文档等类型
b. 不可直接使⽤参数中的原文件名，要随机生成文件名，并限定后缀
c. 对文件路径配置，只允许读写权限

2. 使用存放资源服务器进行单独存储
3. 不可预测的ID对应文件名进行映射