文艺复兴，什么是XSS，常见形式（一）

什么是XSS

跨站脚本攻击(Cross-Site Scripting, 简称 XSS) 是一种经典的客户端代码注入漏洞。

它的本质是：攻击者利用Web站点页面中对于用户输入缺乏严格的验证和过滤缺陷，将带有恶意信息的浏览器脚本（通常是JavaScript，也可以是HTML、VBScript等）注入到正常的网页中，当其他受害者浏览这个被污染的页面时，它们的浏览器会触发这些恶意代码，并执行恶意的逻辑。

核心信任错位：XSS之所以可以成功执行，是受害者的浏览器会完全信任为其提供内容的Web服务器，因为浏览器无法区分哪些脚本是服务器开发者写好的，哪些是恶意代码，在大部分情况下，请求的HTML代码只要是在请求中正常得到的，浏览器就回照单全收并且执行。

XSS的背景

• 为什么叫"Cross-Site"（跨站）
  在 20 世纪 90 年代末到 21 世纪初，XSS 漏洞刚被发现时，它最典型的攻击场景是：攻击者诱导受害者点击一个链接，这个链接会利用网站 A 的漏洞，弹出一个窗口或加载一个框架，从而跨越域名的边界（Cross-Site），去窃取受害者在网站 B 的敏感信息。虽然现代的 XSS 攻击往往只发生在单一网站内部（不再严格"跨站"），但这个历史名称被沿用至今。
• 为什么缩写是"X"SS而不是"C"SS
  为了和CSS层叠样式表，避险。

XSS的分类

XSS可以简单分为三种类型：存储型、反射型、DOM型。

1. 存储型XSS(Stored XSS)

   这是危害最广、影响最深远的一种，可以说是及其恶劣。
   存储位置： 目标服务器后端，通常是数据库、文件系统或者内存中
   触发机制： "被动触发"。受害者不需要点击任何可疑链接，只要像平常一样访问了包含该恶意数据的页面（如浏览包含恶意评论的帖子、查看篡改过的个人主页），代码就会随 HTML 一起下发并执行。
   受害者范围： 无法别攻击：任何访问该页面的用户都会中招。

   存储型是影响最大的一种XSS，它一般是通过类似评论区，留言板绕过了前端的限制，放置了恶意代码，如果顺利被注入了目标服务器的数据库，那么只要访问该页面的每一个用户，都会被执行这些恶意逻辑，并且是以访客的用户执行，当然也包括任何身份，也包括管理员，所以它影响最大也最广。

2. 反射型XSS(Reflected XSS)

   这是最经典，最常见的一种，也是依赖于社会工程学 的一种类型。
   存储位置： 恶意代码不存储在目标的服务器上，而是编码在目标的的URL的参数中。
   触发机制 "主动诱骗"。攻击者必须通过钓鱼邮件、聊天软件等方式，诱导受害者点击这个带有恶意参数的链接。服务器接收请求后，将恶意参数原封不动地拼接在 HTML 响应中"反射"回受害者的浏览器。
   受害者范围： 精准打击。只有点击了该特定链接的特定用户才会中招。触发是一次性的。

   这类虽然是最常见的，但是不太能让人理解，其实本质上是利用前端的缺陷，在很多时候，URL的参数会被反映到具体的HTML代码上，如果你把恶意参数置于URL的参数中，而受害者访问这个URL时，这些参数就会被浏览器执行。

3. DOM型XSS(DOM-based XSS)

   这是现代 Web 架构（前后端分离、单页应用 SPA）中最危险、最难防御的类型，因为它打破了传统的攻防边界。
   存储位置： 即不在服务区后端，也不一定在URL参数里（可能在 URL 的 # 后面，即 Hash 甚至本地的 localStorage 中）。它的执行完全发生在前端受害者的浏览器中。
   触发机制： "前端自嗨"。目标网站合法的前端 JavaScript 代码读取了用户可控的输入源（Source，如 URL 参数），并在没有进行严格安全处理的情况下，将其传递给了危险的执行函数（Sink，如 eval() 或 innerHTML）。
   受害者范围： 取决于恶意输入源的分发方式（可以通过链接诱骗，也可能结合其他漏洞）。

   这种类型时当前最难防守，最危险的一种类型，因为在前端实际编译运行之前，是很难找到缺陷位置的，往往也不会有实际的测试脚本。

XSS实践

portswigger提供大量的XSS Lab，几乎覆盖了大部分情景，我们可以借助它来展示这些情况：

[Lab: Reflected XSS into HTML context with nothing encoded] ：

这是最简单的一种，前端没有任何输入限制，也是XSS的最基本的实现方式，具体是：进入实验场景，在输入框中输入

<script>alert(1)</script>

点击搜索即可，那么原理是什么呢，这个原理其实就是XSS的本质：假如我们不对搜索的参数做任何的限制，那么当我们的脚本置入输入框执行后，在我们的结果页面，浏览器在渲染时，看到了这些脚本语言，就会执行它，这就是XSS的本质，那么为什么是alert呢？这是常说的PoC，你可以理解既然这里允许执行alert这个脚本，那么就可以允许执行恶意脚本，我们只是通过alert这个弹窗看本质即可。

Lab: Stored XSS into HTML context with nothing encoded ：

这是一个没有任何限制的存储型XSS，你可以很直观的看到存储型的危害，具体的是：在Lab环境的下任何一个文章的评论区，加入

<script>alert(1)</script>

顺利发表评论后，返回这个文章你会发现，出现弹窗了，事实上任何一个访客访问这篇文章，只要浏览器渲染了这条评论，都会触发对应脚本，所以存储型是危害最大的一种，主要还是体现在影响太深远了。
Lab: DOM XSS in document.write sink using source location.search：

这是一个没有任何限制的DOM型的XSS，这是一个将URL的输入参数拼接到具体的HTML标签的类型，你会发现在这个Lab中，你会发现这样的javascript，具体的是将URL的参数中的search中的值，镶嵌到

'<img src="/resources/images/tracker.gif?searchTerms='+镶嵌位置+'">'

你如果将这个search的值置为:

	"><svg onload=alert(1) >

那么它会提前结束img标签，并且加入一个svg标签，这个标签中的onload就是在页面加载时，运行脚本alert(1)

Lab: DOM XSS in innerHTML sink using source location.search：

这也是一个DOM型的XSS，不同的是它通过将URL中的参数通过，innerHTML的方式写入，其实本质是相同的，

只需要在这个Lab环境中输入：

	<img src=1 onerror=alert(1)>

其实道理一样，都是把带有恶意的HTML标签写入了HTML代码中，被浏览器编译执行了。

Lab: DOM XSS in jQuery anchor href attribute sink using location.search source：

这是一个针对标签href元素的DOM XSS，通过核心代码可以发现，脚本会将URL参数returnPath的值，写入到Back这个 a 标签的href元素中，href不仅仅是支持链接，它还支持javascript代码，可以通过提交

javascript:alert(document.cookie)

的方式来触发这个脚本，实现写入。

Lab: Reflected XSS into attribute with angle brackets HTML-encoded：

这是一个XSS反射型，它将输入参数反射到一个input标签的value这个元素中，而且没有做任何过滤，这时候你只需要将输入的参数改为"οnmοuseοver="alert(1)，就可以提前讲value的"闭合，这样就构造出了，当光标移动到输入框，就执行脚本alert(1)。

Lab: Stored XSS into anchor href attribute with double quotes HTML-encoded

这是一个存储型的XSS，它例如一些输入框的特性，将恶意代码注入对方后端，让任何访客只需要点击这个a标签都会触发恶意代码。

可以看到，这个带有alert(1)的href元素的a标签，是来自一个评论区的网站元素，具体的是，评论区填写个人信息时，网站一栏往往会被直接被渲染为a标签，输入框中的内容往往就回被置于href中，实现了XSS。

可以看到上述这些XSS非常简单，因为它们是没有经过任何过滤的XSS，这些只是让大家理解这些XSS在数据层面会被注入到位置，在实际操作中，当我们注意到这些数据可能会被注入到一些敏感的位置，例如href元素中，或者被直接拼接到一个具体的HTML标签中，这时候我们就要开始尝试注入XSS恶意脚本代码，往往大部分情况我们都会被拦截，有时候字符会被转义或者被屏蔽掉一些字符，例如简单的替换、黑名单机制等等，面对这些情况我们要使用各种绕过方法，去尝试绕过这些限制，文章将会在下一篇来稍微进阶一下，事实上带有绕过的注入，才算是完整的XSS。

总结

本文简单介绍了一下XSS的背景和几种类型以及它们的危害，以及通过portswigger提供的Lab环境演示了最基本的XSS注入，文章会在后续继续更新带有绕过、组合等等环境下的XSS绕过。