前端开发必须了解的浏览器安全知识

330 阅读9分钟

前言

确保你的 Web 站点或 Web 应用安全是十分重要的,即使是代码中很小的 bug 也可能导致隐私信息被泄露,黑客会尝试偷窃数据。确保你的 Web 站点或 Web 应用安全是十分重要的,即使是代码中很小的 bug 也可能导致隐私信息被泄露,黑客会尝试偷窃数据。浏览器安全主要包括了web页面安全、浏览器网络安全、浏览器系统安全。

一、XSS攻击

XSS (Cross-Site Scripting)攻击指的是跨站脚本攻击,是一种代码注入攻击。攻击者通过在网站注入恶意脚本,使之在用户的浏览器上运行,从而盗取用户的信息如 cookie 等。早期常⻅于论坛, 一些⽹站没有对用户的输⼊进⾏严格的限制, 使得攻击者可以将脚本上传到帖⼦让其他⼈浏览到有恶意脚本的⻚⾯。

攻击过程:

  • 获取页面的数据,如DOM、cookie、localStorage;
  • 发送合理请求,占用服务器资源,使用户无法访问到服务器
  • 破坏页面结构
  • 流量劫持(将链接指向某网站)

攻击类型:

XSS攻击可分为存储型、反射型和DOM型:

1. 存储型XSS攻击

  • 攻击者将恶意代码提交到目标网站的数据库中。
  • 当用户打开目标网站时,服务端将恶意代码拼接在 HTML 中返回给浏览器。
  • 用户浏览器解析执行恶意代码。
  • 恶意代码窃取用户数据,或者冒充用户执行指定操作。

2.反射型XSS攻击

  • 攻击者构造特殊 URL,将恶意代码包含在其中。
  • 用户打开该 URL 时,服务端将恶意代码从URL取出,拼接在 HTML 中返回给浏览器。
  • 浏览器解析并执行恶意代码。
  • 恶意代码窃取用户数据,或者冒充用户执行指定操作。

3.DOM型XSS攻击

  • 攻击者构造特殊的URL,将恶意代码包含在其中。
  • 用户打开该URL。
  • 浏览器解析并执行,JavaScript取出恶意代码并执行。
  • 恶意代码窃取用户数据,或者冒充用户执行指定操作。

三者区别:

  • 存储型XSS:恶意代码存储在数据库里。
  • 反射型XSS:恶意代码存在 URL 里,需要用户打开 URL 才能生效。
  • DOM型XSS:恶意代码用浏览器取出并由 JavaScript 执行,而其它二者属于服务端的安全漏洞。

二、如何防御XSS攻击

  • 从浏览器执行进行防御。
  1. 不使用服务端返回的 HTML 渲染,使用纯前端的方式。
  2. 将插入到 HTML 中的代码进行充分转译,对于DOM型XSS,在数据获取和字符串拼接的时候做好判断。
  • 使用 CSP(内容安全策略):建立白名单,告诉浏览器哪些外部资源可以被执行。它的实现和执行全都由浏览器完成,开发者只需要提供配置。

开启CSP配置:

  1. 在 HTTP 首部设置 Content-Security-Policy
  2. 在 meta 标签设置 http-equiv 属性为 Content-Security-Policy
  • 使用 HttpOnly 属性

在服务端将某些 cookie 设置为 HttpOnly,使 cookie 只能使用在 Http 请求中,无法被脚本所使用。

三、CSRF攻击

CSRF攻击指的是跨站请求伪造攻击,攻击者引诱用户进入第三方网站,在该网站中利用用户的登录状态绕过后台的用户验证,冒充用户执行操作。

攻击过程:

  • 用户登录信任网站A
  • 登录验证通过产生 cookie
  • 用户在没有登出A的状态访问第三方网站
  • 第三方网站向A发送请求,要求访问A
  • 根据第三方的请求,浏览器携带 cookie 访问A
  • A不知道请求由谁发出,由于浏览器带上了用户的 cookie ,A通过用户的权限处理,这样攻击者就达到冒充用户进行操作的目的

csrf.png

攻击类型:

  • GET 类型的 CSRF 攻击,如在网站中的一个 img 标签里构建一个请求,当用户打开这个网站的时候就会自动发起提交。
  • POST 类型的 CSRF 攻击,如构建一个表单并隐藏,当用户进入页面时,自动提交这个表单。
  • 链接类型的 CSRF 攻击,如在 a 标签的 href 属性里构建一个请求,然后诱导用户去点击。

四、如何防御CSRF攻击

  • 利用 cookie 的 SameSite 属性

在 set-cookie 中设置 SameSite 属性,可以限制第三方 cookie,从而减少风险。

Samesite 一共有两种模式,一种是严格模式(Strict),在严格模式下 cookie 在任何情况下都不可能作为第三方 Cookie 使用,一种是宽松模式(Lax),cookie 可以被 GET 请求所请求,但大多数不发送第三方的cookie。

  • 同源检测

服务器根据 http 请求头中 origin 或者 referer 信息来判断请求是否为允许访问的站点,从而对请求进行过滤。当 origin 或者 referer 信息都不存在的时候,阻止该请求。

缺点是有些情况下 referer 可以被伪造,同时还会把搜索引擎的链接也给屏蔽了。所以一般网站会允许搜索引擎的页面请求,但是相应的页面请求这种请求方式也可能被攻击者给利用。

referer字段记录了该HTTP请求的来源地址,一般通过Referer Policy来控制(Referer Policy 首部监管访问的来源信息--在Referer中发送--包含在生成请求中)

  • 使用CSRF Token验证
  1. 浏览器发起请求时,服务器会生成一个随机数Token并返回
  2. 在下一次浏览器发起请求时,需要带上页面的Token,服务器将验证该Token是否合法

因为第三方站点无法获取该Token,可以避免CSRF攻击。

缺点是需要给网站中的所有请求都添加上这个 token,操作比较繁琐。并且请求一般不会只有一台服务器,如果请求经过负载平衡转移到了其他的服务器,但是这个服务器的 session 中没有保留这个 token 的话,就没有办法进行验证。

五、中间人攻击

中间人攻击(Man-in-the-Middle Attack,简称MITM),是一种会话劫持攻击。攻击者作为中间人,劫持通信双方会话并操纵通信过程,而通信双方并不知情,从而达到窃取信息或冒充访问的目的。常见的攻击方式有 Wi-Fi 仿冒、邮件劫持、DNS 欺骗、SSL 劫持等

攻击过程:

  • 客户端发送请求到服务端,请求被中间⼈截获
  • 服务器向客户端发送公钥
  • 中间⼈截获公钥,保留在⾃⼰⼿上。然后⾃⼰⽣成⼀个伪造的公钥,发给客户端
  • 客户端收到伪造的公钥后,⽣成加密 hash 值发给服务器
  • 中间⼈获得加密 hash 值,⽤⾃⼰的私钥解密获得真密钥,同时⽣成假的加密hash值,发给服务器
  • 服务器⽤私钥解密获得假密钥,然后加密数据传输给客户端

屏幕截图 2024-07-17 155725.png

六、如何防范中间人攻击

  • 不随意连接公共Wi-Fi,仅连接已知可信的Wi-Fi,避免流量被恶意劫持。自有Wi-Fi不要使用路由器默认密码,设置高强度加密保护,避免被破解。
  • 确保访问HTTPS网站,可以安装开源HTTPS Everywhere浏览器插件,使浏览器自动连接HTTPS网站。
  • 不随意忽略证书不安全告警,如果产生告警说明浏览的网站可能不安全。
  • 远程访问使用VPN,保护通信流量。
  • 不要打开钓鱼邮件,钓鱼邮件一般会伪装成合法来源,并要求用户点击链接。注意识别钓鱼邮件,尤其不能点击邮件中的链接,否则可能会下载恶意软件或被重定向到恶意网站。
  • 安装并及时更新杀毒软件。

七、网络劫持

网络劫持分为两种:

(1)DNS劫持: (打开某网站却被强制跳转到其它网站这就属于 DNS 劫持)

  • DNS强制解析: 通过修改运营商的本地 DNS 记录,来引导⽤户流量到缓存服务器
  • 302跳转的⽅式: 通过监控⽹络出⼝的流量,分析判断哪些内容是可以进⾏劫持处理的,再对劫持的内存发起302跳转的回复,引导⽤户获取内容。

(2)HTTP劫持: (访问某网站但是⼀直有其它网站的⼴告),由于http明⽂传输,运营商会修改你的http响应内容(即加⼴告)。

八、HTTPS

由于HTTP通信使用明文、不验证通信方身份、无法证明报文的完整性等可能导致通信内容被监听、通信方被伪装,所以HTTPS诞生了。HTTPS在HTTP和TCP之间插入了一个安全层(对请求的数据进行加密,对接收的内容进行解密)。

HTTPS过程:

  1. 客户端发起HTTP请求
  2. 服务端响应并下发证书(公开密钥证书)
  3. 客户端查验证书,生成随机值并用证书对该随机值加密
  4. 将加密过的随机值发送给服务端,后面通信都采用该随机值
  5. 服务端解密后,得到随机值,然后产生对称加密的密钥
  6. 后面的数据传输都是基于该密钥进行加密解密

对称加密: 加密数据的密钥与解密的密钥一样,虽然加密解密过程效率高但是对于多个有数据交换需求的个体,两两之间维护一把密钥,成本过高。

非对称加密: 加密数据的密钥与解密的密钥不一样,虽然能保证浏览器发送给服务端的数据是安全的,但是加密解密的效率,影响用户打开页面的速度,并且无法保证服务端发送给浏览器的数据安全。

所以HTTPS在传输数据时采用对称加密,对称加密的密钥采用非对称加密传输。

数字证书: 服务端通过数字证书向浏览器证明身份。

获取过程:

  1. 准备一套公钥和私钥(私钥留给自己)
  2. 向CA(证书颁发机构)提交信息
  3. CA验证信息真实性
  4. 审核通过,CA签发数字证书

浏览器如何获取CA公钥?

在建立HTTPS时,服务器将服务器的数字证书和给该服务器签名的数字证书一起发送给浏览器,浏览器就能获取公钥了。如果服务器没有部署CA的数字证书,浏览器可以通过网络下载(回拖慢打开速度)。