Web安全

前端的攻击方式都有哪些？

XSS攻击

XSS(Cross-Site Scripting ，跨站脚本攻击)是一种代码注入攻击 攻击者在目标网站上注入恶意代码 当被攻击者登录网站就会执行这些恶意代码 这些脚本可以读取被攻击者的cookie session tokens 或者其他的敏感信息 对用户进行钓鱼欺诈甚至发起蠕虫攻击

XSS攻击实现的本质是 恶意代码没有经过过滤就和网站的正常代码混在一起 浏览器无法分辨哪些脚本可信 就导致了恶意脚本被执行， 因为恶意脚本是在用户的终端执行 所以恶意代码能够直接获取用户的信息， 利用这些信息可以冒充用户向网站发送攻击者自定义的请求

XSS攻击的分类
1.反射型XSS

当用户点击一个恶意链接或者提交一个表单 或者进入一个恶意网站 注入脚本进入被攻击者的网站 web服务器注入脚本 比如错误信息等 这些恶意信息没有进行过滤直接返回到用户的浏览器上

反射型XSS的攻击步骤：

  • 攻击者构造出特殊的URL 其中包含恶意代码
  • 用户打开带有恶意代码的URL时 网站服务端将恶意代码从URL中取出 拼接在HTML返回给浏览器
  • 浏览器接收到响应后解析执行 这个时候恶意代码也会执行
  • 恶意代码将用户数据窃取到 并发送到攻击者的网站或者冒充用户的行为 调用目标网站接口执行攻击者指定的操作

反射型 XSS 漏洞常见于通过 URL 传递参数的功能 因为需要用户主动点击恶意URL 所以攻击者会结合各种手段来诱惑用户进行点击

​ 如何防范反射型XSS攻击呢？

可以对通过对字符串进行编码的方式即把URL的查询参数进行转义后再输出到页面

2.存储型XSS攻击

恶意脚本永久存储在目标服务器上。当浏览器请求数据时，脚本从服务器传回并执行，影响范围比反射型和DOM型XSS更大。存储型XSS攻击的原因仍然是没有做好数据过滤：前端提交数据至服务端时，没有做好过滤；服务端在接受到数据时，在存储之前，没有做过滤；前端从服务端请求到数据，没有过滤输出。

存储型XSS攻击方式

  1. 攻击者将恶意代码提交到目标网站的数据库中。
  2. 用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
  3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作

防范存储型XSS攻击

  1. 前端数据传递给服务器之前，先转义/过滤(防范不了抓包修改数据的情况)
  2. 服务器接收到数据，在存储到数据库之前，进行转义/过滤
  3. 前端接收到服务器传递过来的数据，在展示到页面前，先进行转义/过滤
3.DOM型XSS攻击

DOM 型 XSS 攻击，实际上就是前端 JavaScript 代码不够严谨，把不可信的内容插入到了页面。

DOM型XSS攻击的步骤

  • 攻击者构造出特殊的URL 其中包含恶意代码
  • 用户打开带有恶意代码的URL
  • 用户浏览器接收到响应后解析执行， 前端 JavaScript 取出 URL 中的恶意代码并执行。

DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

​ 如何防范？

防范 DOM 型 XSS 攻击的核心就是对输入内容进行转义(DOM 中的内联事件监听器和链接跳转都能把字符串作为代码运行，需要对其内容进行检查)。

CSRF攻击

CSRF(Cross-site request forgery ) 跨站请求伪造： 攻击者诱导受害者进入第三方的网站 在第三方网站向被攻击网站发送跨站请求， 利用受害者在被攻击网站已经获取的注册凭证 绕过后台的用户验证 达到冒充用户对被攻击的网站执行某项操作的目的

CSRF攻击的流程

  • 受害者登录a.com 保留登录凭证(如cookie)
  • 攻击者引诱受害者访问b.com
  • b.com向a.com发送一个请求，比如a.com/act=xx 浏览器会默认携带a.com的cookie
  • a.com收到请求后 对请求进行验证 发现是受害者的凭证 会误以为是受害者自己发送的请求
  • a.com以受害者的名义执行 act = xx
  • 攻击完成 攻击者在受害者不知情的情况下 冒充受害者 让a.com执行了自己定义的操作

CSRF的特点

1.攻击通常在第三方网站发起，如图上的站点B，站点A无法防止攻击发生。

2.攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；并不会去获取cookie信息(cookie有同源策略)

3.跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等(来源不明的链接，不要点击)

CSRF 攻击防御

  • 添加验证码的方式 （体验不好）
    • 验证码能够防御CSRF攻击，但是我们不可能每一次交互都需要验证码，否则用户的体验会非常差，但是我们可以在转账，交易等操作时，增加验证码，确保我们的账户安全。
  • 使用Token(主流)
    • CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开。跟验证码类似，只是用户无感知。

参考 https://tech.meituan.com/2018/10/11/fe-security-csrf.html

点击劫持

点击劫持是指在一个Web页面中隐藏了一个透明的iframe，用外层假页面诱导用户点击，实际上是在隐藏的frame上触发了点击事件进行一些用户不知情的操作。

攻击流程

  • 攻击者构建一个很有吸引力的网页
  • 将攻击的页面放置在当前页面的iframe中
  • 使用样式将iframe叠加到有吸引力的内容上方
  • 将iframe设置为百分之百透明度
  • 用户被诱导后被攻击

防御攻击

  1. frame busting
1
2
3
if ( top.location != window.location ){
    top.location = window.location
}

2.X-Frame-Options

X-FRAME-OPTIONS是微软提出的一个http头，专门用来防御利用iframe嵌套的点击劫持攻击

可以设置为以下值:

  • DENY: 拒绝任何域加载
  • SAMEORIGIN: 允许同源域下加载
  • ALLOW-FROM: 可以定义允许frame加载的页面地址

URL跳转漏洞

URL 跳转漏洞是指后台服务器在告知浏览器跳转时，未对客户端传入的重定向地址进行合法性校验，导致用户浏览器跳转到钓鱼页面的一种漏洞。

URL跳转一般有以下几种实现方式

  1. Header头跳转
  2. Javascript跳转
  3. META标签跳转

防御

会出现跳转 URL 漏洞，就是因为服务端没有对客户端传递的跳转地址进行合法性校验，所以，预防这种攻击的方式，就是对客户端传递过来的跳转 URL 进行校验。

1.referer的限制

如果确定传递URL参数进入的来源，我们可以通过该方式实现安全限制，保证该URL的有效性，避免恶意用户自己生成跳转链接

2.加入有效性验证Token

保证所有生成的链接都是来自于可信域，通过在生成的链接里加入用户不可控的token对生成的链接进行校验，可以避免用户生成自己的恶意链接从而被利用。

参考链接 https://github.com/YvetteLau/Blog/issues/29