网站攻击手段---XSS & CSRF

gmx_white
225 阅读8分钟

XSS（Cross-Site Scripting）

跨站点脚本攻击是一种常见的网页攻击方式，指攻击者向目标网站注入HTML标签或脚本。
如果网页的内容是动态生成的，比如根据用户提交的数据生成内容，却没有对数据‘消毒’（删除嵌入的HTML标签），那就可能成为跨站点脚本的攻击目标。

示例：

使用JavaScript根据用户输入的名字给出问候

<script>
let name = new URL(document.url).searchParams.get("name")
document.querySelector('h1').innerHTML = "hello " + name
</script>

对于URL: http//www.example.com/greet.html?name=gmx ，网页会显示'hello gmx'，如果将查询参数改为
name=%3Cimg%20src=%22x.png%22%20onload=%22alert(%27hacked%27)%22/%3E
把这个经过URL转义的参数解码后，就会导致img标签被注入文档:
hello <img src="x.png" onload="alert('heacked')"/>
于是图片加载后，onload属性的javascript字符串就会执行，以上演示了未经处理的HTML标签会导致任意代码执行的可能性。

之所以称之为跨站点脚本攻击，是因为涉及不止一个网站。网站B包含一个特殊编制的链接（类似于前面示例的URL），指向网站A。如果网站B说服用户点击链接，用户就会导航到网站A，但此时网站A就会运行来自网站B的代码。该代码可能会破坏网站A的页面，或者导致它功能失效。更严重的，恶意代码可能会读取网站A存储的cookie（包含个人账号或用户身份信息）并将数据发送回网站B。这种注入的代码甚至可以跟踪用户的键盘输入，并将数据返回网站B。

XSS攻击类型

根据脚本注入的地方，分为：

  • 持久型XSS：将脚本植入到服务器上，从而导致每个访问的用户都会执行
  • 非持久型XSS：对个体用户某url的参数进行攻击

根据攻击来源，分为：

  • 存储型 XSS
  • 反射型 XSS
  • DOM型 XSS

存储型 XSS---持久型，服务器端

攻击步骤：

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

这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。

反射型 XSS---非持久型，服务器端

攻击步骤：

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

反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。

反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。

由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。

POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。

DOM型 XSS--浏览器端

攻击步骤：

  1. 攻击者构造出特殊的 URL，其中包含恶意代码。
  2. 用户打开带有恶意代码的 URL。
  3. 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

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

XSS的防范措施

XSS 攻击有两大要素： 1. 攻击者提交恶意代码。 2. 浏览器执行恶意代码。

针对攻击者提交恶意代码，我们是否能够在用户输入的过程，过滤掉用户输入的恶意代码呢？

输入过滤
如果由前端过滤输入，然后提交到后端的话。一旦攻击者绕过前端过滤，直接构造请求，就可以提交恶意代码了。

那么，换一个过滤时机：后端在写入数据库前，对输入进行过滤，然后把“安全的”内容，返回给前端。一个正常的用户输入了 5 < 7 这个内容，在写入数据库前，被转义，变成了 5 $lt; 7。

那么问题又来了：在提交阶段，我们并不确定内容要输出到哪里。

  1. 用户的输入内容可能同时提供给前端和客户端，而一旦经过了 escapeHTML()（并不存在的API，需要自己手动实现HTML转义），客户端显示的内容就变成了乱码( 5 $lt;7 )。
  2. 在前端中，不同的位置所需的编码也不同。 当 5 $lt;7 作为 HTML 拼接页面时，可以正常显示：5 < 7

所以输入过滤非完全可靠，我们就要通过“防止浏览器执行恶意代码”来防范 XSS，可采用下面的两种方法

前端渲染把代码和数据分隔开
在前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式 （.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。

  • Javascript：可以使用textContent或者innerText的地方，尽量不使用innerHTML；
  • query：可以使用text()得地方，尽量不使用html()；

拼接HTML时对其进行转义
如果拼接 HTML 是必要的，就需要采用合适的转义库，对 HTML 模板各处插入点进行充分的转义。

常用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有一个规则，就是把 & < > " ' / 这几个字符转义掉，确实能起到一定的 XSS 防护作用，但并不完善。

其他 XSS 防范措施

虽然在渲染页面和执行 JavaScript 时，通过谨慎的转义可以防止 XSS 的发生，但完全依靠开发的谨慎仍然是不够的。以下介绍一些通用的方案，可以降低 XSS 带来的风险和后果。

Content Security Policy

严格的 CSP 在 XSS 的防范中可以起到以下的作用：

  • 禁止加载外域代码，防止复杂的攻击逻辑。
  • 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。
  • 禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。
  • 禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。
  • 合理使用上报可以及时发现 XSS，利于尽快修复问题。

输入内容长度控制

对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。

其他安全措施

  • HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
  • 验证码：防止脚本冒充用户提交危险操作。

CSRF

(Cross Site Request Frogy)指的是跨站请求伪造。与XSS不同的是，XSS是攻击者直接对网站A进行注入攻击，CSRF是通过网站B对我们的网站A进行伪造请求。
利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

攻击流程举例

  1. 受害者登录 a.com，并保留了登录凭证（Cookie）
  2. 攻击者引诱受害者访问了b.com
  3. b.com 向 a.com 发送了一个请求：a.com/act=xx，浏览器会默认携带a.com的Cookie
  4. a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求
  5. a.com以受害者的名义执行了act=xx
  6. 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作

攻击类型

i） GET型：如在页面的某个 img 中发起一个 get 请求
ii）POST型：通过自动提交表单到恶意网站
iii）链接型：需要诱导用户点击链接

预防方案

CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。

  • 同源检测：通过Header中的Origin Header 、Referer Header 确定，但不同浏览器可能会有不一样的实现，不能完全保证

  • CSRF Token 校验：将CSRF Token输出到页面中（通常保存在Session中），页面提交的请求携带这个Token，服务器验证Token是否
    正确

  • 双重cookie验证： 双提交，请求时自动携带Cookie，此外，Cookie内容还在post请求中携带或者URL中。

    • 流程：

      • 步骤1：在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）
      • 步骤2：在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST www.a.com/comment?csr…
      • 步骤3：后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。

    • 优点：

      • 无需使用Session，适用面更广，易于实施。
      • Token储存于客户端中，不会给服务器带来压力。
      • 相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。

    • 缺点：
      -Cookie中增加了额外的字段。
      -如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。
      -难以做到子域名的隔离。
      -为了确保Cookie传输安全，采用这种防御方式的最好确保用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。

  • Samesite Cookie属性：Google起草了一份草案来改进HTTP协议，那就是为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，Strict 为任何情况下都不可以作为第三方 Cookie ，Lax 为可以作为第三方 Cookie , 但必须是Get请求

avatar
文章
阅读
粉丝