【前端面试题】：网络安全篇

1.XSS 攻击是什么？如何防范？

XSS 攻击，全称跨站脚本攻击（Cross Site Scripting），是一种网络安全攻击手段。攻击者通过在目标网站上注入恶意脚本，当其他用户访问这些被篡改的网页时，恶意脚本会在用户的浏览器上执行，从而盗取用户信息如 cookie 等，或者执行其他恶意操作，如破坏页面结构、重定向到其他网站等。

XSS 攻击主要分为三种类型：

1. 反射型 XSS：攻击者将恶意脚本注入到 URL 中，用户通过点击带有恶意脚本的链接触发攻击。

2. 存储型 XSS：攻击者将恶意脚本提交到网站的数据库中，每当用户访问相关页面时，恶意脚本都会执行。

3. DOM 型 XSS：基于网站脚本的漏洞来攻击用户，无需与服务端交互，仅通过操作 DOM 树即可执行恶意脚本。

要防范 XSS 攻击，可以从以下几个方面入手：

1. 输入合法性验证：在服务端对用户输入的数据进行合法性验证，过滤掉不符合规范的字符或代码，确保输入数据的安全性。

2. 转义特殊字符：对用户输入的内容中的特殊字符进行转义处理，如将 < 转换为 <，将 > 转换为 >，防止浏览器将这些字符误解为标签或脚本。

3. 设置 HTTP 头部：使用如 Content-Security-Policy、X-Content-Type-Options、X-XSS-Protection 等 HTTP 头部，来增强浏览器的安全策略，阻止恶意脚本的执行。

4. 使用脚本过滤器：引入第三方库或工具，如 Google 的 Closure Library、jQuery 等，对用户输入的数据进行过滤和检查，进一步减少 XSS 攻击的风险。

5. 限制 cookie 的使用：设置 cookie 的 HttpOnly 属性，确保 JavaScript 无法访问 cookie，降低攻击者利用 cookie 进行攻击的可能性。同时，尽量在 HTTPS 连接下使用 cookie，以增加数据传输的安全性。

6. 安全编码：在编写代码时，使用安全的编码方式，避免直接将用户输入的数据插入到 HTML 或 JavaScript 中，而是使用安全的 API 或函数来处理用户输入。

综上所述，防范 XSS 攻击需要综合考虑多个方面，从输入验证、输出转义、HTTP 头部设置、脚本过滤到安全编码等，都需要进行细致的处理。同时，定期更新和修补网站的安全漏洞也是非常重要的。

2.CSRF 攻击是什么？如何防范？

CSRF 攻击，全称跨站请求伪造（Cross-Site Request Forgery），是一种常见的网络安全威胁。攻击者利用用户已经通过身份验证的身份，在用户不知情的情况下，以用户的名义执行非法操作。这种攻击通常涉及在用户浏览器中加载恶意 URL 或点击恶意链接，从而实现攻击的目的。

CSRF攻击的一般过程如下：

1. 用户登录受信任的网站 A，并在浏览器中保持登录状态。

2. 用户访问恶意网站 B，该网站包含针对网站 A 的恶意请求（例如，提交表单或发送 AJAX 请求）。

3. 由于浏览器会自动添加用户在网站 A 上的身份验证信息，这些请求会被发送到网站 A，并被视为用户的有效请求。

4. 网站 A 执行相应的操作，如更改密码、发表评论等，从而导致用户的账户或数据受到损害。

为了防范 CSRF 攻击，可以采取以下措施：

1. 验证 HTTP Referer 字段：确保请求来源于受信任的网站。服务器可以验证请求头中的 Referer 字段，确认请求是否来自合法的源。

2. 使用 CSRF Token：在每个表单中添加一个唯一的 CSRF Token，该令牌与用户会话相关联。提交表单时，服务器验证该令牌的有效性。攻击者无法获取到有效的令牌，因此无法成功发起 CSRF 攻击。

3. 使用 SameSite Cookie 属性：通过设置 Cookie 的 SameSite 属性为 Strict 或 Lax，限制 Cookie 在跨站点请求中的发送。这有助于减少 CSRF 攻击的风险。

4. 避免使用 GET 请求进行状态更改操作：由于 GET 请求容易被攻击者篡改，因此应避免使用 GET 请求来修改服务器端的数据。改用 POST、PUT 等请求方法进行状态更改操作。

5. 实施二次验证：对于涉及敏感操作的请求，可以要求用户进行二次验证，如输入密码、验证码等，确保用户的操作是合法的。

6. 及时更新和修补安全漏洞：定期更新网站和框架的补丁，确保已知的安全漏洞得到修复。

综上所述，防范 CSRF 攻击需要综合考虑多个方面，从验证请求来源、使用 CSRF Token、限制 Cookie 发送、避免使用 GET 请求进行状态更改、实施二次验证到及时更新和修补安全漏洞等，都需要进行细致的处理。这些措施有助于增强网站的安全性，减少 CSRF 攻击的风险。

3.什么是 HTTPS 中间人攻击？如何防范？

HTTPS 中间人攻击 是一种网络安全威胁，攻击者通过拦截客户端和服务器之间的通信，作为中间人处理双方的数据，从而窃取或篡改信息。这种攻击通常发生在攻击者能够控制或监听客户端和服务器之间的网络连接时，例如公共 Wi-Fi 等不安全网络环境。

在 HTTPS 中间人攻击中，攻击者会拦截服务器向客户端发送的公钥，并用自己的伪造公钥替换它。当客户端使用伪造公钥加密数据并发送给服务器时，攻击者可以拦截并解密这些数据。同时，攻击者还可以用自己的私钥重新加密这些数据，并将其发送给服务器，使得服务器无法察觉异常。通过这种方式，攻击者可以窃取敏感信息，如用户密码、银行账户信息等。

为了防范 HTTPS 中间人攻击，可以采取以下措施：

1. 使用 HTTPS：确保只访问那些使用 HTTPS 的网站。HTTPS 提供了额外的安全保护层，通过 TLS/SSL 协议来加密数据的传输，确保数据的完整性和保密性。

2. 注意警告信息：如果浏览器提示正在访问的网站存在安全问题，应引起足够的重视。这通常是浏览器检测到 SSL 证书无效或被篡改，提示用户存在中间人攻击的风险。

3. 避免使用公共 Wi-Fi：如果无法避免使用公共 Wi-Fi，应下载并安装安全防护软件，增加连接的安全性。同时，留意浏览器的安全警告，如果警告数量突然增加，可能表明存在中间人攻击。

4. 验证 SSL 证书：HTTPS 证书通过可信任的第三方机构颁发，用于验证网站的身份。浏览器会检查证书的有效性和完整性，确保用户与真实的网站进行通信。对 SSL 证书的证书链进行校验，也是防范中间人攻击的重要手段。

综上所述，防范 HTTPS 中间人攻击需要综合采取多种措施，从使用 HTTPS、注意警告信息、避免使用公共 Wi-Fi 到验证 SSL 证书等，都需要用户和网络管理员的共同努力。

4.什么是 CORS 跨域资源共享？如何防范?

CORS（跨域资源共享，Cross-Origin Resource Sharing） 是一种 W3C 标准，它允许浏览器向跨源服务器发出 XMLHttpRequest 请求，从而克服了 AJAX 只能同源使用的限制。当一个资源从与该资源本身所在的服务器不同的域、协议或端口请求时，就会发生跨域 HTTP 请求。出于安全原因，浏览器限制从脚本内发起的跨源 HTTP 请求。CORS 机制通过使用额外的 HTTP 头部字段来告诉浏览器，是否允许运行在一个 origin（domain）上的 Web 应用访问来自不同源服务器上的指定资源。

在 CORS 的实现中，涉及到服务器和浏览器两个方面。浏览器发起一个跨域请求时，先进行一次预请求（Preflight Request），以获取服务器对跨域请求的授权。预请求中携带了一些关键信息，如请求方法、请求头等，服务器根据这些信息来决定是否允许跨域请求。当服务器认可请求后，会在响应头中添加相应的字段，如 Access-Control-Allow-Origin、Access-Control-Allow-Methods 等，以告知浏览器允许跨域访问。

为了防范 CORS 相关的安全风险，可以采取以下措施：

1. 限制请求来源：通过配置 CORS 策略，限制只允许特定的域名或 IP 地址进行跨域请求。

2. 验证请求头：服务器可以验证请求头中的特定字段，如 Origin、Access-Control-Request-Method 等，以确保请求来自合法的源，并且使用正确的请求方法。

3. 使用 HTTPS：通过 HTTPS 协议加密跨域请求的数据传输，防止数据在传输过程中被窃取或篡改。

4. 定期更新和审查 CORS 配置：随着业务的发展和安全需求的变化，定期更新和审查 CORS 配置，确保其与当前的安全策略保持一致。

需要注意的是，虽然 CORS 机制提供了一定的安全保护，但它并不能完全消除跨域请求的安全隐患。因此，在实际应用中，还需要结合其他安全措施，如身份验证、访问控制等，来确保跨域资源共享的安全性。

5.什么是点击劫持？如何防范？

点击劫持（ClickJacking） 是一种视觉上的欺骗手段。攻击者使用一个透明的 iframe 页面，覆盖在一个正常网页上，然后诱使用户点击该网页，这时用户就会在不知情的情况下点击那个透明的 iframe。例如：攻击者开发一个网站内容为两层，底层是某种让人想要有点击欲望的图或者布局，上层是通过 iframe 嵌套某社交网站的主页，并且设置透明度为完全透明，同时通过定位让 iframe 上的某些操作按钮与底层引导点击区域重叠，这样用户在点击底层引导点击区域时，实际点击的是上层透明的 iframe 上的操作按钮。

防范点击劫持的有效措施如下：

1. 使用 HTTPS 协议

2. 强化 DNS 安全

3. 部署网络防火墙和入侵检测系统

4. 定期更新和审查浏览器扩展

5. 提醒用户注意不信任的链接，避免点击可疑的广告，以及定期更新密码等

6.什么是文件上传漏洞？如何防范？

文件上传漏洞 是 web 安全中一种常见的漏洞形式，攻击者通过利用这种漏洞上传恶意文件（如木马、病毒、WebShell 等）到服务器并执行，从而获取对网站的控制权限。这种漏洞的产生往往是因为文件上传功能在实现时没有对上传的文件进行严格的格式、类型和内容检查。

防范文件上传漏洞的常用方法包括：

1. 设置文件上传目录为不可执行：确保 web 容器无法解析该目录下的文件，即使攻击者上传了恶意脚本，服务器本身也不会执行。

2. 严格检查文件类型：在服务器端实现文件类型检查机制，结合使用 MIME Type、文件后缀等方式。推荐使用白名单方式，明确允许上传的文件类型，而不是使用黑名单方式，因为黑名单方式已被证明容易被绕过。

3. 对上传的文件进行内容检查：对于允许上传的图片文件，可以使用图像处理库重新生成图片，从而破坏可能包含的恶意代码。对于其他类型的文件，也可以实施相应的内容检查策略。

4. 使用随机数改写文件名和路径：这样可以增加攻击者猜测或访问上传文件的难度，从而有效防御恶意文件的执行。

5. 单独设置文件服务器的域名：通过浏览器同源策略的限制，可以防御一些客户端攻击，例如利用上传的 crossdomain.xml 文件或包含 JavaScript 的 XSS 攻击。

6. 限制上传文件的大小：设置合理的文件大小限制，防止攻击者上传过大的恶意文件。

7. 实施用户权限控制：对于文件上传功能，应实施严格的用户权限控制，确保只有经过授权的用户才能上传文件。

8. 使用 Web 应用防火墙（WAF）：WAF 可以监控和拦截恶意文件上传行为，提供实时的安全防护。

综上所述，防范文件上传漏洞需要综合考虑多个方面，包括设置不可执行的上传目录、严格检查文件类型和内容、使用随机数改写文件名和路径、单独设置文件服务器域名、限制文件大小、实施用户权限控制以及使用 Web 应用防火墙等。通过采取这些措施，可以有效降低文件上传漏洞的风险。

7.介绍下前端加密的常见场景和方法？

前端加密在网络安全中起着至关重要的作用，它可以在数据传输和存储过程中保护敏感信息，防止未经授权的访问和篡改。以下是前端加密的一些常见场景和方法：

常见场景

1. 密码传输：在用户登录或注册时，前端需要传输用户的密码。如果不对密码进行加密，攻击者可能在传输过程中截获明文密码，导致用户账户被盗。因此，前端需要对密码进行加密处理后再发送给服务器。
2. 数据包加密：在网页浏览过程中，用户与服务器之间会频繁交换数据。如果这些数据未加密，攻击者可能通过中间人攻击等手段窃取或篡改数据。因此，使用 HTTPS 协议对数据进行加密是前端加密的常见场景之一。
3. 敏感信息展示：在某些应用中，前端需要展示用户的敏感信息，如银行卡号、身份证号等。为了避免这些信息被恶意爬虫抓取或泄露，前端需要对这些信息进行加密处理。

加密方法

1. 对称加密：使用相同的密钥进行加密和解密。常见的对称加密算法有 AES、DES 等。这种方法加密速度快，但密钥管理较为困难，需要在安全的环境中共享和存储密钥。
2. 非对称加密：使用公钥进行加密，私钥进行解密。常见的非对称加密算法有 RSA、ECC 等。这种方法安全性高，但加密速度相对较慢。通常用于数字签名和密钥交换等场景。
3. 哈希算法：将任意长度的数据映射为固定长度的哈希值。常见的哈希算法有 MD5、SHA-256 等。哈希算法主要用于验证数据的完整性，而不是直接加密数据。
4. 混合加密：结合对称加密和非对称加密的优点，先使用非对称加密交换密钥，然后使用对称加密对实际数据进行加密。这种方法既保证了加密速度，又提高了安全性。

前端加密的实现方式

1. 浏览器端加密：使用 JavaScript 等前端技术实现加密功能。这种方式可以实时加密用户输入的数据，但需要注意防止 JavaScript 代码被篡改或泄露。
2. 与后端协同加密：前端将数据加密后发送给后端，后端再进行二次加密或验证。这种方式可以提高整体的安全性，但需要确保前后端之间的通信安全。

总之，前端加密是保护用户数据安全的重要手段之一。在实际应用中，需要根据具体场景和需求选择合适的加密方法和实现方式。同时，还需要关注加密算法的安全性、密钥管理以及与其他安全措施的协同配合等问题。

8.简述 cookie 和 token 都存放在 header 中，为什么不会劫持 token？

虽然 Cookie 和 Token 都存放在 HTTP 请求的 Header 中进行传输，但它们具有不同的安全机制，这也是 Token 不易被劫持的原因。

首先，Cookie 是一种服务器在客户端保存状态信息的机制，它会在每次 HTTP 请求头中自动发送给服务器。Cookie 通常用于存储用户身份验证、会话管理等敏感信息。然而，由于 Cookie 的特点是每次请求都会自动携带，因此存在一定的安全风险，容易被攻击者利用进行劫持。

相比之下，Token 的设计更注重安全性。Token 是无状态的，服务器不记录哪些用户登录了或者哪些 Token 被发布了，只判断 Token 是否有效。通常会给 Token 设置有效时间，来确保不被劫持。这种机制使得 Token 在传输过程中更难以被攻击者捕获和利用。

另外，Token 的验证方式也与 Cookie 不同。在 Token 的验证过程中，服务器会验证 Token 的有效性，包括检查其签名和过期时间等。这种验证方式增加了攻击者伪造或篡改 Token 的难度。

因此，虽然 Cookie 和 Token 都存放在 Header 中，但由于它们的安全机制不同，Token 相对于 Cookie 具有更高的安全性，不易被劫持。在实际应用中，为了增强系统的安全性，通常会结合使用多种安全措施，如 HTTPS 协议、安全的加密算法等，来确保用户数据的安全传输和存储。