前端常见安全漏洞解析与防范

最新推荐文章于 2024-06-20 00:15:00 发布

Yuki-^_^

最新推荐文章于 2024-06-20 00:15:00 发布

阅读量1.1k

点赞数 17

分类专栏：前端文章标签：前端

本文链接：https://blog.csdn.net/weixin_49376454/article/details/139032306

版权

前端专栏收录该内容

5 篇文章 0 订阅

订阅专栏

1. XSS攻击：当你的网站成了表演舞台

XSS攻击：攻击者通过在前端代码中插入恶意脚本，当其他用户加载页面时执行恶意代码。防御措施：对输出进行HTML转义，对动态生成的URL使用URL编码，对表单输入进行验证。
CSRF攻击：攻击者通过用户已认证的请求进行非法操作。防御措施：使用CSRF token，要求用户进行二次验证，限制请求来源。
点击劫持：攻击者通过iframe或重定向技术，将用户的点击行为引导至其他页面。防御措施：明确提示用户正在访问的网站信息，使用内容安全策略（CSP）限制可加载资源。

具体到知乎平台，应当在前端代码中加入相应的安全措施来防范上述提到的安全缺陷。例如，对于XSS攻击，前端代码中可以加入以下的防护措施：

javascriptfunction escapeHTML(text) {
var map = {
'&': '&amp;',
'<': '&lt;',
'>': '&gt;',
'"': '&quot;',
"'": '&#039;'
};
return text.replace(/[&<>"']/g, function(m) { return map[m]; });
}

// 使用escapeHTML函数来转义输出内容
var safeContent = escapeHTML(userInput);
document.getElementById('content').innerText = safeContent;

对于CSRF防护，可以在表单中添加一次性的token：

html<form action="/transfer" method="POST">
<input type="hidden" name="csrf_token" value="{{ csrf_token }}">
<!-- 其他表单字段 -->
</form>

对于点击劫持，可以通过提示用户正在访问的网站信息，或者设置内容安全策略来限制可加载资源：

html<meta http-equiv="Content-Security-Policy" content="default-src 'self';">

以上代码只是示例，实际应用时需要根据具体的前端框架和应用场景来实现相应的安全措施。

XSS（跨站脚本攻击）就是攻击者往Web页面里插入恶意的脚本代码，当用户浏览这些页面时，嵌入其中的脚本代码会被执行，从而达到攻击的目的。

演示代码：

<input type="text" name="search" value=""><script>alert('XSS Attack!');</script>

这段代码如果被嵌入到了网页中，当用户打开这个页面时，就会弹出一个警告框。想象一下，如果这个警告框里的内容是“你的账户已被盗”，那感觉是不是很刺激？

防范措施：

对用户输入进行检验，转义HTML标签。
使用CSP（内容安全策略）。

2. CSRF攻击：当你的网站成了操纵者的傀儡

CSRF（跨站请求伪造）攻击是指攻击者诱使用户在不知情的情况下，以用户的身份向网站发出恶意请求。

举个栗子：

你登录了银行网站，然后未退出直接访问了一个小广告。这个小广告页面里有一个看不见的表单，自动提交了一个转账请求。结果，你的账户就悄悄地给别人转账了。

防范措施：

使用Token验证用户请求。
检查Referer字段。

3. 点击劫持：当你的网站被人“画”中画

点击劫持是一种视觉上的欺骗，攻击者通过一个透明的iframe覆盖在网站上，诱使用户在不知不觉中点击了iframe页面上的按钮或链接。

演示代码：

想象一下，你的网站上突然多了一个透明的iframe层，而这个iframe层里是一个“删除所有文件”的按钮。

防范措施：

设置X-Frame-Options响应头，控制网页是否允许被iframe嵌套。

4. 密码安全：当你的密码成了别人的口袋书

许多人喜欢使用简单密码，甚至在多个网站上重复使用相同的密码。这就像是在网络世界中，把自己的口袋翻了出来，让别人随便翻阅。

防范措施：

强制用户使用复杂密码。
定期更换密码。
使用双因素认证。

5. 接口安全：当你的数据成了免费自助餐

在前后端分离的架构下，前端通过API与后端通信。如果API没有做好权限验证，那么恶意用户就可以直接调用这些API，获取敏感数据。

防范措施：

对API进行权限校验。
使用HTTPS加密数据传输。

在这个全民皆兵的网络安全战场上，前端开发者应时刻保持警惕，运用正确的知识和工具来防御可能的攻击。记住，只有深入了解敌人，才能百战不殆。所以，让我们一起学习、防范，保卫我们的网络安全！

结束语：

希望通过今天的分享，你对前端安全有了更深的认识。虽然我们无法做到万无一失，但至少可以做到有备无患。在这个充满未知和挑战的网络世界，让我们做一个谨慎的前端开发者，保护好每一寸网络阵地！

背景

前端技术栈架构师在写业务框架的时候必须关注这个 web-app 的安全策略配置是否都考虑到了，是否给到业务开发者一些安全设置的配置。本着需要理解这些背后本质的心态，补充一期前端相关安全知识的整理。实际大家可能在公司就是看到 config 里有些安全配置开关。

几类和前端息息相关的安全问题

前端开发者在开发过程中可能会遇到许多安全问题，主要包括以下几类：

网络协议攻击：这块主要包括 HTTP，HTTPS（证书过期，中间人劫持），DNS劫持等问题
跨站脚本攻击（XSS）：这是最常见的前端安全问题之一。攻击者通过注入恶意的 JavaScript 脚本，企图破坏网站的功能或者窃取用户的数据。
跨站请求伪造（CSRF）：在这种攻击中，攻击者诱使用户去请求一个他们并不期望的网站，以此来执行一些恶意的操作。
点击劫持：攻击者通过透明的元素或者弹窗，诱使用户在不知情的情况下点击一些链接或者按钮，以此来执行一些恶意的操作。
混合内容问题：如果一个使用 HTTPS 协议的网站中，包含了使用 HTTP 协议的资源（如图片、脚本等），可能会导致用户的数据被窃取。这是因为 HTTP 协议的数据传输不是加密的，攻击者可以通过监听网络传输，来窃取这些数据。
第三方库的安全问题：许多前端开发者在开发过程中，会使用一些第三方的库或者框架。如果这些库或者框架存在安全问题，或者被恶意修改，可能会引入一些安全风险。
不安全的数据存储：在前端开发中，有时需要在用户的浏览器中存储一些数据。如果这些数据包含敏感信息，如密码、Token等，并且存储方式不安全（如直接保存在localStorage等），可能会被攻击者窃取。

接下来我们分别介绍这几类的攻防策略

网络协议攻击
HTTP

HTTP 是一种无状态的明文协议，数据在传输过程中并不加密，容易被中间人攻击。攻击者可以轻易地监听、捕获和篡改传输中的数据，包括敏感信息如用户名、密码、session ID 等。信道安全是最大问题

HTTPS

HTTPS 是基于 SSL/TLS 的 HTTP 加密版本，提供了数据的机密性、完整性和身份认证。然而，如果实施不当，HTTPS 也可能有安全隐患。例如，如果服务器的 SSL/TLS 版本过旧或配置不当，可能会遭受“中间人攻击”。此外，如果网站的 HTTPS 证书不合法或过期，也可能导致安全问题。

中间人攻击

中间人攻击（Man-in-the-Middle Attack，简称 MITM）是一种网络攻击手段，攻击者插入到通信的两端之间，截取和可能篡改他们的通信。

在这种攻击中，攻击者让通信的双方认为他们正在直接和对方通信，但实际上，所有的通信都通过了攻击者。这样，攻击者就可以监听和捕获所有传输的信息，包括敏感信息，如登录凭证、信用卡号等。如果攻击者愿意，他们甚至可以更改通信的内容。

以下是几种常见的中间人攻击：

ARP Spoofing：攻击者发送伪造的 ARP 消息到局域网，将其他设备的流量引导到自己的设备上。
DNS Spoofing：攻击者通过篡改 DNS 查询的响应，将用户导向错误的 IP 地址。
HTTPS Spoofing：攻击者创建一个伪造的 HTTPS 网站，将用户的流量引导到这个网站，从而窃取用户的信息。

为了防止中间人攻击，可以使用以下几种方法：

使用加密的连接，如 HTTPS、VPN。这可以确保数据在传输过程中的安全，即使被攻击者截获也无法直接读取。
检查 SSL 证书。如果浏览器提示 SSL 证书有问题，那可能是正在遭受中间人攻击。不要忽视这些警告。
使用安全的 DNS 解析，如 DNSSEC，防止 DNS Spoofing。
使用网络安全工具，如防火墙，IDS 等，监控异常的网络行为。

DNS 劫持

DNS 劫持是一种攻击方式，攻击者通过劫持 DNS 服务器，将用户的网络请求引导到一个错误或恶意的网站。这可能会导致用户的个人信息泄露，或者下载到恶意软件。虽然 DNSSEC (DNS 安全扩展) 能够避免 DNS 劫持，但并不是所有的网站和 ISP 都启用了 DNSSEC

总结

为了防止这些网络安全问题，开发者和网站管理员应该采取一些措施，如使用 HTTPS 来加密网站的所有传输，确保服务器的 SSL/TLS 配置正确且版本更新，选择启用 DNSSEC 的 DNS 服务器，定期对网站进行安全审查等。

XSS 安全

概念

XSS（跨站脚本攻击）是一种常见的网络攻击手段。在这种攻击中，攻击者通过注入恶意的 JavaScript 脚本来攻击网站的用户

攻击

XSS 攻击主要有以下几种类型：

存储型 XSS 攻击：攻击者将恶意的 JavaScript 脚本存储在网站的服务器上（例如，在一个评论区中发布含有恶意脚本的评论）。当其他用户浏览到包含这些脚本的页面时，就会执行这些脚本。
反射型 XSS 攻击：在这种攻击中，攻击者会将恶意脚本包含在 URL 中。当用户点击这个 URL 时，恶意脚本会被网站的页面反射（即，直接在页面中输出），然后在用户的浏览器中执行。
DOM 型 XSS 攻击：这种攻击是通过修改页面的 DOM 结构，使得恶意脚本得以执行。

防御

对抗 XSS 攻击的防御方法有多种，以下是一些常见的方法：

数据输出时进行转义：对所有的用户输入进行 HTML 转义，可以有效防止 XSS 攻击。例如，将 "<" 转义为 "<"、将 ">" 转义为 ">"等。这样做的目的是防止浏览器将用户输入的数据误认为是 HTML 代码或者 JavaScript 脚本。
使用内容安全策略（CSP）：内容安全策略是一种浏览器技术，可以用来限制网站页面中脚本的来源。这样，即使攻击者能够注入恶意脚本，这些脚本也无法执行。
使用 HTTP-only cookies：将 cookies 设置为 HTTP-only 可以防止 JavaScript 读取这些 cookies。这样，即使攻击者注入了恶意脚本，也无法窃取用户的 cookies。
使用最新的 JavaScript 框架：许多现代的 JavaScript 框架（如 React、Vue.js 等）内置了 XSS 防御机制。

前端框架集成等防范措施

现代 JavaScript 框架。如 React、Vue.js 等，都有一些内置的防御机制，来帮助开发者避免 XSS 攻击。下面是一些具体的防御机制：

默认的数据绑定是安全的：在这些框架中，数据绑定到视图的方式通常是安全的。例如，在 Vue 和 React 中，使用双大括号 ({{ }}) 或 JSX 的 {} 来插入数据时，框架会自动对其进行转义，以防止数据被解析为 HTML 或 JavaScript。这样，即使数据中包含有潜在的 XSS 攻击代码，也不会被执行。
提供安全的编码函数：当需要在视图中插入未转义的 HTML 时，这些框架通常会提供安全的方法。例如，React 的 dangerouslySetInnerHTML，Vue 的 v-html 指令。虽然这些方法允许插入未转义的 HTML，但它们的名称都强调了这种操作的危险性，提醒开发者需要谨慎使用。
Content Security Policy (CSP) 支持：许多现代框架也支持内容安全策略 (CSP)，这是一种防止 XSS 攻击的安全措施。CSP 可以限制网页中能执行的脚本的来源，有效地阻止 XSS 攻击。

虽然这些框架提供了一些内置的防御机制，但仍然需要开发者了解 XSS 攻击的原理，并在编写代码时遵循一些最佳实践，如对用户输入进行校验，使用 HTTP-only cookies 等，才能更有效地防止 XSS 攻击。

CSRF
攻击

CSRF（跨站请求伪造）是一种网络攻击手段，主要是攻击者利用用户已登录的身份，伪造用户去请求服务器。这种攻击方式可以诱导用户执行攻击者预设的操作，如修改密码、购买商品等。

假设一个场景：用户在一家银行的网站上登录了自己的账户。如果该网站存在 CSRF 漏洞，攻击者可以设置一个陷阱，比如在论坛中发帖附带一个链接，这个链接是银行网站的一个转账接口，而且指定了收款人和转账金额。如果用户点击了这个链接，那么银行网站可能会认为是用户自己发起的转账请求，从而进行转账。
这种攻击方法的关键在于，用户并不知道自己发起了这个请求，而服务器也无法分辨这个请求是不是用户本人意愿发起的，这就给攻击者留下了可乘之机。

CSRF 攻击有一定的局限性，它必须基于用户已经登录了目标网站，并且该网站有 CSRF 漏洞存在。此外，攻击者也不能预知 CSRF 攻击的具体结果，因为这取决于被攻击的网站的业务逻辑。

防御

为了防御 CSRF 攻击，我们可以使用一些方法，例如使用 CSRF token，验证 HTTP Referer 字段，或者使用 SameSite Cookie 等。

一种常见的CSRF防御机制是使用CSRF token。以下是一个简单的JavaScript的CSRF token生成和验证的例子。

首先，我们需要一个函数来生成CSRF token：

function generateCSRFToken() {
  // 这里只是一个简单的实现，实际使用时可能需要更复杂的方式生成token
  return Math.random().toString(36).slice(2);
}

在实际应用中，服务器在响应客户端的请求时，会生成一个CSRF token，并在响应中将其发送给客户端。客户端在发送请求时，会将这个token作为一部分请求数据发送给服务器。

服务器在收到请求时，会验证请求中的token是否和服务器发送的token一致。以下是一个简单的验证函数：

function verifyCSRFToken(serverToken, clientToken) {
  // 比较两个token是否一致
  return serverToken === clientToken;
}

于是在现代前端框架中csrf的开启往往也是个 config 选项透出

点击劫持问题（Clickjacking）

概念

点击劫持（Clickjacking）是一种常见的网络攻击手段，也被称为“UI 覆盖攻击”。在这种攻击中，攻击者将一个透明的、恶意的网页覆盖在一个用户期望看到的网页上面。当用户在页面上进行操作（如点击按钮）时，他们实际上是在点击攻击者的透明页面，从而触发了攻击者预设的行为。这个行为在实际业务开发中会被忽视，但是基建团队一般也都会在构建 config 里给我们配置上类似 X-Frame-Options 和csp 的选项为了防止这些问题。

防御策略

1使用 X-Frame-Options HTTP 响应头：这是一种 HTTP 响应头，可以防止你的网页被嵌入到其他网页的 iframe 中。你可以将这个响应头设置为 DENY（禁止所有的域嵌入你的网页），或者 SAMEORIGIN（只允许相同域名的网页嵌入你的网页）。

2使用 Content Security Policy (CSP)：CSP 是一种控制网页内容的安全策略，你可以使用 frame-ancestors 指令，来限制哪些网页可以嵌入你的网页。

3使用 JavaScript 检测：你可以在你的网页中添加 JavaScript 代码，检测你的网页是否被嵌入到 iframe 中。如果是，那么可以让网页跳出 iframe，显示在顶层窗口。

需要注意的是，虽然上述方法可以有效防止点击劫持，但没有任何一种方法是绝对安全的。因此，作为开发者，我们应该尽量使用多种防御策略，以增加攻击者的攻击成本。

基本防御case

if (top !== self) {
    top.location = self.location;
}

这段代码的作用是，如果当前页面不是顶层窗口（被嵌入到了其他页面的 iframe 中），那么就将顶层窗口的地址设置为当前页面的地址，使得当前页面显示在顶层窗口，从而跳出 iframe。

混合内容问题

是指一个使用 HTTPS 协议的网页，包含了使用 HTTP 协议的资源。因为 HTTP 是明文传输，所以这种情况下，即使主页面是 HTTPS，但包含的 HTTP 资源在传输过程中仍然可能被窃取或篡改。这就是混合内容的问题，它可能导致用户的信息泄露或者被欺骗。这个问题尤其在一个framework 页面里需要潜逃一些其他人丢进来的内容的时候特容易出问题。需要在主框架上做好一些设置，我们应该时刻注意自己的网站是否存在混合内容问题，并及时进行修复。

防御

使用 HTTPS 来加载所有资源：这是最直接、最有效的解决方法。无论是图片、脚本、样式表，还是其他任何类型的资源，都应该使用 HTTPS 来加载。
使用相对 URL：如果你的网站同时支持 HTTP 和 HTTPS，那么可以使用相对 URL 来引用资源，如 "/path/to/my/script.js"，而不是 "http://example.com/path/to/my/script.js"。这样，浏览器会使用和主页面相同的协议来加载资源。
使用 Content Security Policy (CSP)：CSP 是一种用来控制网页可以加载哪些资源的安全策略。你可以设置 CSP 的 "upgrade-insecure-requests" 指令，来自动将所有的 HTTP 请求升级到 HTTPS。
使用 HTTP Strict Transport Security (HSTS) 头：HSTS 是一种安全策略，它告诉浏览器，这个网站只能通过 HTTPS 访问。开启 HSTS 后，浏览器会自动将所有的 HTTP 请求升级到 HTTPS。

第三方库的安全问题

问题

我想许多公司的业务代码架构治理都在解决这个问题。当我们一个迭代项目中依赖的包存在安全问题，或者这个包已经不推荐无人维护，或者这个包直接被恶意篡改（投毒），都会引入安全风险。

防御

在我们实际的业务治理过程中，架构师们往往会制定精品库，有专门的团队维护其更新，默认集成到团队业务框架里。例如标准 xx 业务线的 stdlib。并且提供代码扫描工具在ci等时机不断扫描项目发现老旧库或者不推荐的库就告警。

不安全的数据存储

问题

在web开发中，不安全的数据存储可以引起许多安全问题。如果攻击者能够访问或者修改存储的数据，可能会泄露敏感信息，或者造成其他的安全问题。

防御

使用安全的cookie设置：对于存储在 cookie 中的数据，应该使用 secure 和 HttpOnly 标志来保护它们。secure 标志可以确保 cookie 只通过 HTTPS 发送，HttpOnly 标志可以防止 JavaScript 访问 cookie。
敏感信息加密存储：对于敏感信息，如密码，应该进行哈希和加盐存储，而不是明文存储。哈希可以确保即使数据库被泄露，攻击者也无法直接获取到原始的密码。加盐可以进一步增加破解的难度。
避免在localStorage中存储敏感信息：localStorage 是持久性的，并且在同源的所有页面中都可访问。因此，如果你在 localStorage 中存储敏感信息，可能会有被 XSS 攻击窃取的风险。你应该避免在 localStorage 中存储敏感信息，或者至少对它们进行加密。
限制并监控数据的访问：应该限制谁可以访问存储的数据，以及他们可以进行的操作。对于敏感操作，如数据的修改和删除，应该进行记录和监控。

安全的数据存储需要多方面的考虑和措施，包括传输的安全，存储的安全，以及访问的安全。

总结

作为前端技术栈架构师，需要思考安全这个纬度。把握好所在域的业务框架的整体是安全的，能抵御上述的各种攻击。从框架层本身就做了基本的防御措施，让业务同学能更关注业务需求本身

```python
class BertPooler(nn.Module):
    def __init__(self, config):
        super().__init__()
        self.dense = nn.Linear(config.hidden_size, config.hidden_size)
        self.activation = nn.Tanh()

    def forward(self, hidden_states):
        # We "pool" the model by simply taking the hidden state corresponding
        # to the first token.
        first_token_tensor = hidden_states[:, 0]
        pooled_output = self.dense(first_token_tensor)
        pooled_output = self.activation(pooled_output)
        return pooled_output
from transformers.models.bert.configuration_bert import *
import torch
config = BertConfig.from_pretrained("bert-base-uncased")
bert_pooler = BertPooler(config=config)
print("input to bert pooler size: {}".format(config.hidden_size))
batch_size = 1
seq_len = 2
hidden_size = 768
x = torch.rand(batch_size, seq_len, hidden_size)
y = bert_pooler(x)
print(y.size())
```