浏览器的网络安全

最新推荐文章于 2024-05-12 14:23:18 发布

Shirley_Song_1

最新推荐文章于 2024-05-12 14:23:18 发布

阅读量128

点赞数

分类专栏：浏览器文章标签：前端 web安全网络安全

本文链接：https://blog.csdn.net/shirley_song_1/article/details/124269911

版权

浏览器专栏收录该内容

5 篇文章 0 订阅

订阅专栏

浏览器的网络安全

1、同源策略

1.1、什么是

一个 URL 有三部分组成：协议、域名(指向主机)、端口，只有这三个完全相同的 URL 才能称之为同源。同源策略控制不同源之间的交互，例如在使用XMLHttpRequest 时则会受到同源策略的约束。

1.2、如何跨域访问

script标签嵌入跨域脚本 <script src="..."></script>。
link标签嵌入跨域CSS <link rel="stylesheet" href="...">。
通过<img>标签展示的图片。
通过 video 和 audio播放的多媒体资源。
通过 @font-face 引入的字体。
通过 iframe 载入的任何资源。
可以通过设置 document.domain，让子域名和父域名通过同源策略的检测。

// 例如：子域名下面的页面 http://store.company.com/dir/other.html

document.domain = "company.com"; // 脚本代码中修改
fetch("http://company.com/dir/page.html") // 再去访问父域名下面的页面，可以不被跨域拦截

跨域访问的解决方案：

CORS：跨域资源共享，是HTTP的一部分，它允许服务端来指定哪些主机可以从这个服务端加载资源。
JSONP
Nginx代理

1.3、跨源数据存储访问

访问存储在浏览器中的数据，如 localStorage 和 IndexedDB，是以源进行分割。每个源都拥有自己单独的存储空间，一个源中的 JavaScript 脚本不能对属于其它源的数据进行读写操作。

Cookies 使用不同的源定义方式。一个页面可以为本域和其父域设置 cookie，只要是父域不是公共后缀（public suffix）即可。

// 服务端返回的 Access-Control-Allow-Origin 响应头字段进行控制
Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: https://foo.example

2、XSS攻击

2.1、什么是

XSS：跨站脚本，但重点不在于跨站点，而是在于脚本的执行。

XSS是一种经常出现在Web应用程序中的计算机安全漏洞，是由于Web应用程序对用户的输入过滤不足而产生的，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。

常见的XSS攻击有三种：

反射型XSS攻击：
- 通过特定手法，诱使用户去访问一个包含恶意代码的URL，当受害者点击这些专门设计的链接的时候，恶意代码会直接在受害者主机上的浏览器执行。
- 此类XSS攻击通常出现在网站的搜索栏、用户登录口等地方，常用来窃取客户端Cookies或进行钓鱼欺骗。
DOM-based型XSS攻击：
- 客户端的脚本程序可以动态地检查和修改页面内容，而不依赖于服务器端的数据。例如客户端如从URL中提取数据并在本地执行，如果用户在客户端输入的数据包含了恶意的JavaScript脚本，而这些脚本没有经过适当的过滤或者消毒，那么应用程序就可能受到DOM-based型XSS攻击。
- 需要特别注意以下的用户输入源document.URL、location.hash、location.search、document.referrer等。
存储型XSS攻击：
- 攻击者事先将恶意代码上传或者储存到漏洞服务器中，只要受害者浏览包含此恶意代码的页面就会执行恶意代码。
- 这意味着只要访问了这个页面的访客，都有可能会执行这段恶意脚本，因此存储型XSS攻击的危害会更大。
- 此类攻击一般出现在网站留言、评论、博客日志等交互处，恶意脚本存储到客户端或者服务端的数据库中。

2.2、防御

服务器对输入脚本进行过滤或转码
充分利用 CSP；
- 启用：通过 HTTP 头信息的 Content-Security-Policy字段，或通过meta标签；
- 限制加载其他域下的资源文件，禁止向第三方域提交数据，禁止执行内联脚本和未授权的脚本；
使用 HttpOnly 属性；
通过使用 HttpOnly 属性来保护 Cookie 的安全，无法通过 JavaScript 来读取这段 Cookie。

3、CSRF攻击

3.1、什么是

Cross-site request forgery，跨站点请求伪造，攻击者通过伪造用户的浏览器的请求，向访问一个用户自己曾经认证访问过的网站发送出去，使目标网站接收并误以为是用户的真实操作而去执行命令。常用于盗取账号、转账、发送虚假消息等。

CSRF攻击攻击原理及过程如下：

用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

3.2、如何检测

最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。

3.3、防御CSRF攻击：

目前防御 CSRF 攻击主要有三种策略：

验证 HTTP Referer 字段；
- 在浏览器发起请求时，Referer记录了该 HTTP 请求的来源地址。
- 但有些API服务本身不需要在浏览器发起，且有些浏览器可被篡改，或支持用户设置请求时不发送referer。
在请求地址中添加 token 并验证；
- 在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token。
- 缺点是难以保证 token 本身的安全。
在 HTTP 头中自定义属性并验证；
- 这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。
- 这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起。

4、安全沙箱

安全沙箱如何影响到各个模块功能的呢？

持久存储
网络访问
用户交互

站点隔离（Site Isolation)

所谓站点隔离是指 Chrome 将同一站点（包含了相同根域名和相同协议的地址）中相互关联的页面放到同一个渲染进程中执行。

由于最初都是按照标签页来划分渲染进程的，所以如果一个标签页里面有多个不同源的 iframe，那么这些 iframe 也会被分配到同一个渲染进程中，这样就很容易让黑客通过 iframe 来攻击当前渲染进程。而站点隔离会将不同源的 iframe 分配到不同的渲染进程中，这样即使黑客攻击恶意 iframe 的渲染进程，也不会影响到其他渲染进程的。