XSS (Cross-Site Scripting,跨站脚本攻击) 是一种代码注入攻击。攻击者通过在目标网站注入恶意脚本,使其在用户浏览器中执行,从而窃取用户敏感信息如 Cookie 和 SessionID。
CSS 在前端已经被用了,为了避免歧义用了 XSS 作为缩写。
XSS 的本质是恶意代码与网站正常代码混在一起,浏览器无法分辨它们的可信度,终极导致恶意代码被执行。
XSS的危害
浏览器无法区分恶意代码和正常代码,它们拥有雷同的权限。恶意代码可以读取用户的敏感数据,比如 cookie 和 sessionID 等等。
可能的危害如下:
- 由于恶意代码可以获取cookie和sessionID等数据,它可以获取用户的隐私数据并发送到攻击者的服务器举行网络;
- 恶意代码以用户(被攻击者)的名义,构造带有恶意代码的 URL 举行传播。
XSS的分类
根据攻击者注入恶意脚本的方式的差别,XSS 可以被分为三类:
存储型 XSS
- 存储区:后端数据库
- 插入点:HTML
- 攻击步调:
- 攻击者将恶意代码提交到目标网站的数据库。
- 用户打开目标网站时,恶意代码从数据库取出并嵌入 HTML。
- 用户浏览器执行恶意代码,导致用户数据被窃取或伪造操作被执行。
- 特点:恒久性长,危害性大。
以 POST 评论和 GET 评论为例,攻击者只要发布一条带有恶意脚本的评论,这个攻击就可能影响到全部浏览到这一条评论的别的用户。并且这条评论是存储在数据库里的,假如没有对用户提交的评论做过滤,那么这个恶意的攻击会一直存储在数据库里直到有用户浏览到它,因此说它是恒久的。
下图中的步调 1 和步调 2 之间可能隔断很久。
案例
假如用户发布了一条带有恶意代码的评论,这条评论被存储到了数据库里。如果网站利用服务端渲染,那么在服务端会发生模板的数据填充:终极前端拿到的 HTML 是:恶意脚本将被执行。
客户端渲染在利用innerHTML的时候也要十分注意。
反射型 XSS
- 插入点:HTML
- 攻击步调:
- 攻击者构造一个带有恶意代码的 URL。
- 用户打开该 URL 时,网站从 URL 中提取恶意代码并插入 HTML。
- 用户浏览器执行恶意代码,导致数据走漏或伪造操作。
- 特点:反射型的特点是必须用户点击这个经过恶意构造的URL才会被攻击,并且脚本显现在URL上,相对来说比较容易被发现。反射型XSS有经过后端。
案例
一个搜刮页面,搜刮的 query 通过 url 带参。
- php代码:
- <!DOCTYPE html>
- <html lang="en">
- <head>
- <meta charset="UTF-8">
- <title>搜索结果</title>
- </head>
- <body>
- <h1>搜索结果</h1>
-
- 你搜索了: <?php echo $_GET['q']; ?>
-
- </body>
- </html>
复制代码 - 攻击示例:
攻击者可以构造一个携带恶意脚本的URL:- http://example.com/search.html?q=
复制代码 用户点击该链接后,服务器会直接将 q 参数的值插入到页面中,天生的页面 HTML 如下:浏览器解析并执行了 script 标签内的内容,从而触发了 XSS 攻击。
DOM 型 XSS
- 插入点:前端 JavaScript
- 攻击步调
- 攻击者构造一个特别的 URL。
- 用户打开该 URL 后,前端 JavaScript 处理时会执行恶意代码。
- 恶意代码在浏览器中运行,可能导致数据走漏或伪造操作。
- 特点:DOM 型 XSS 仅发生在前端。
案例:- <!DOCTYPE html>
- <html lang="en">
- <head>
- <meta charset="UTF-8">
- <title>搜索结果</title>
- </head>
- <body>
- <h1>搜索结果</h1>
-
- 正在搜索:
-
-
- </body>
- </html>
复制代码 攻击者可以构造一个包罗恶意代码的链接:- http://example.com/search.html?q=
复制代码 当链接被访问时,恶意脚本就会被插入到界面中并执行:- document.getElementById('search-query').innerHTML = "";
复制代码 XSS的预防
XSS 有两大要素,一是攻击者提交恶意代码,二是浏览器执行恶意代码。
转义用户输入(不实用)
为了预防攻击者提交恶意代码,可以考虑对用户的输入举行过滤。
利用合适的转义函数,例如 escapeHTML(),将用户输入的特别字符转换为安全的 HTML 实体。- function escapeHTML(str) {
- return str.replace(/&/g, "&")
- .replace(/</g, "<")
- .replace(/>/g, ">")
- .replace(/"/g, """)
- .replace(/'/g, "'")
- .replace(/\//g, "/");
- }
复制代码 这种方法只能用于一些简单的场景。它的缺点在于:
- 如果这个转义仅发生在前端提交请求之前,攻击者仍可以手动构造请求。
- 如果这个转义发生在后端将数据写入数据库之前,也是不合理的,因为我们不知道这个数据将来应用的环境是哪里。上面这段代码的转义只能应用于浏览器环境的HTML里,转义后的数据无法在桌面客户端、安卓端等等别的环境上正常显示。
总结:
- 转义用户输入只能应用于简单的场景;
- 转义最好应用在Web前端渲染数据时,而不是用户提交数据时;
- 对于明确的类型,比如数字、电话、URL、邮箱等数据,做一下数据过滤还是很有必要的。
用户输入环节并不能很好地预防 XSS,预防 XSS 的主要工作集中在预防浏览器执行恶意代码上。
关于这一点又有两类操作:
- 防止 HTML 被注入;
- 防止 JavaScript 执行恶意代码。
预防反射型和存储型
这两种类型都是在后端服务器上完成模板拼接的过程中,将恶意代码嵌入到了 HTML 中。
两种解决方法分别是:客户端渲染、转义HTML。
纯客户端渲染
纯客户端渲染:客户端访问页面,服务端返回的页面不带有任何业务数据,由前端的 JavaScript 通过 AJAX 异步请求数据后举行填充。
纯客户端渲染可以通过 .innerText,.setAttribute,.style等 API 来插入后端返回的业务内容(这些内容可能存在恶意代码),通过这种方式插入的内容不会被浏览器当成代码执行。
局限:
- 纯客户端渲染仍要注意 DOM型 XSS 攻击。
- 部门页面临于性能有较高需求,或者需要考虑SEO,仍需要服务端渲染。
转义 HTML
对于服务端渲染,在拼接带有业务数据的 HTML 时,要对 HTML 的各个插入点举行充分的转义。
一些模板引擎可能仅对 & < > " ' / 举行转义,这实在是远远不够的,插入点有很多种,包罗但不限于:
<ul>在 HTML 内嵌的文本中,以 script 标签的情势注入;
在内联的 javascript 中,拼接的数据突破了原本的限定(字符串、方法名等等);
例如,a 标签的 href 可能理想状态下是插入一个路径链接,如果这个 href 插入的字符串是一个 javascript:恶意代码的情势,当 a 标签被点击时,恶意代码就会被执行。
对于标签的属性,如果注入的值包罗双引号,就会导致这个属性的值提前结束,从而可以注入别的属性或者标签;
例如:
注入别的属性示例- // src 是用用户数据拼接的
- <img src="https://www.cnblogs.com/<%= imgSrc %>" />
- // 如果用户数据如下
- $imgSrc = 'https://www.cnblogs.com/./not-exist-img.png" onerror="javascript:恶意代码'
- // 那么拼接后的 img 标签就是
- <img src="https://www.cnblogs.com/./not-exist-img.png" onerror="javascript:恶意代码" />
复制代码 图片加载不到,会触发 onerror 中的恶意代码。
注入别的标签示例- <img src="https://www.cnblogs.com/<%= imgSrc %>" />
复制代码 如果 imgSrc 插入的内容是 " /> |