web渗透中常见的一种攻击方式：XSS攻击。

祝，大家新年快乐！

XSS攻击

1. XSS攻击就是页面被注入了恶意的代码。
   • 通常页面中包含的用户输入内容都在固定的容器或者属性内，以文本的形式展示。
   • 攻击者利用这些页面的用户输入片段，拼接特殊格式的字符串，突破原有位置的限制，形成了代码片段。
   • 攻击者通过在目标网站上注入脚本，使之在用户的浏览器上运行，从而引发潜在风险。
   • 通过 HTML 转义，可以防止 XSS 攻击。
2. 注意特殊的 HTML 属性、JavaScript API
   • 做了 HTML 转义，并不等于高枕无忧。
   • 对于链接跳转，如 <a href=”xxx” 或 location.href=”xxx”，要检验其内容，禁止以 javascript: 开头的链接，和其他非法的 scheme。
3. 根据上下文采用不同的转义规则
   • HTML 转义是非常复杂的，在不同的情况下要采用不同的转义规则。如果采用了错误的转义规则，很有可能会埋下 XSS 隐患。
   • 应当尽量避免自己写转义库，而应当采用成熟的、业界通用的转义库。

   • 在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。
   • 在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。
   • 在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。
   • 在标签的 href、src 等属性中，包含 javascript: 等可执行代码。
   • 在 onload、onerror、onclick 等事件中，注入不受控制代码。
   • 在 style 属性和标签中，包含类似 background-image:url(“javascript:…”); 的代码（新版本浏览器已经可以防范）。
   • 在 style 属性和标签中，包含类似 expression(…) 的 CSS 表达式代码（新版本浏览器已经可以防范）。

XSS攻击分类

1. XSS是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行，攻击者可以获取敏感信息，cookie等，进而危害数据安全。
2. 本质是：恶意代码未经过过滤，与正常的代码混合在一起；浏览器无法分辨出哪些脚本是可信的，导致脚本被恶意执行。 | 类型 | 攻击方向 | 攻击 | | ——— | ———————– | —— | | 存储型XSS | 后端数据库 | HTML | | 反射型XSS | URL | HTML | | DOM型XSS | 后端数据库/URL/前端存储 | 前端JS |

• 存储型 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攻击的预防 输入过滤

1 XSS攻击的两大要素：攻击者提交的恶意代码，浏览器执行的恶意代码

2 预防存储型XSS和反射型XSS攻击 * 改完纯前端渲染，把代码和数据分隔开 * 对HTML做转义

3 预防 DOM 型 XSS 攻击 DOM 型 XSS 攻击，实际上就是网站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了。 在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。 如果用 Vue/React 技术栈，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。 DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，<a> 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。

  <!-- 内联事件监听器中包含恶意代码 -->
  <img onclick="UNTRUSTED" onerror="UNTRUSTED" src="data:image/png,">/

^_^

  <!-- 链接内包含恶意代码 -->
  <a href="UNTRUSTED">1</a>
  
  <script>
  	// setTimeout()/setInterval() 中调用恶意代码
  	setTimeout("UNTRUSTED")
  	setInterval("UNTRUSTED")
  
  	// location 调用恶意代码
  	location.href = 'UNTRUSTED'
  
  	// eval() 中调用恶意代码
  	eval("UNTRUSTED")
  </script>

4 其他 XSS 防范措施 虽然在渲染页面和执行 JavaScript 时，通过谨慎的转义可以防止 XSS 的发生，但完全依靠开发的谨慎仍然是不够的。以下介绍一些通用的方案，可以降低 XSS 带来的风险和后果。 Content Security Policy 严格的 CSP 在 XSS 的防范中可以起到以下的作用： * 禁止加载外域代码，防止复杂的攻击逻辑。 * 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。 * 禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。 * 禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。 * 合理使用上报可以及时发现 XSS，利于尽快修复问题。 关于 CSP 的详情，请关注前端安全系列后续的文章。 输入内容长度控制 对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。 其他安全措施 * HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。 * 验证码：防止脚本冒充用户提交危险操作。

XSS检测

使用通用 XSS 攻击字符串手动检测 XSS 漏洞。 使用扫描工具自动检测 XSS 漏洞。

减少XSS的攻击

• 利用模板引擎
• 避免内联事件
• 避免拼接字符
• 时刻保持警惕
• 增加攻击难度，降低攻击后果
• 主动检测和发现

游戏

xss-game

答案

完

本文首次发布于 Azr的博客, 作者 @azrrrrr ,转载请保留原文链接.

原文链接： http://amor9.cn/2019/02/05/xss/

• Previous
  七。Angular — 小Demo
• Next
  了解MVVM