前端安全系列:如何防止XSS攻击?
自以前次变乱之后,小明会警惕的把插入到页面中的数据举办转义。并且他还发明白大部门模板都带有的转义设置,让全部插入到页面中的数据都默认举办转义。这样就不怕不警惕遗漏未转义的变量啦,于是小明的事变又徐徐变得轻松起来。 可是,作为导演的我,不行能让小明这么简朴、开心地改 Bug 。 不久,小明又收到安详组的隐秘链接:http://xxx/?redirect_to=javascript:alert('XSS')。小明不敢大意,赶快点开页面。然而,页面并没有自滚动出万恶的“XSS”。 小明打开对应页面的源码,发明有以下内容:
这段代码,当进攻 URL 为 http://xxx/?redirect_to=javascript:alert('XSS'),处事端相应就成了:
固然代码不会当即执行,但一旦用户点击 a 标签时,赏识器会就会弹出“XSS”。 可恶,又失察了... 在这里,用户的数据并没有在位置上打破我们的限定,如故是正确的 href 属性。但其内容并不是我们所预期的范例。 原本不只仅黑白凡字符,连 javascript: 这样的字符串假如呈此刻特定的位置也会激发 XSS 进攻。 小明眉头一皱,想到了办理步伐:
只要 URL 的开头不是 javascript:,就安详了吧? 安详组顺手又扔了一个毗连:http://xxx/?redirect_to=jAvascRipt:alert('XSS') 这也能执行?.....好吧,赏识器就是这么强盛。 小明欲哭无泪,在判定 URL 开头是否为 javascript: 时,先把用户输入转成了小写,然后再举办比对。 不外,所谓“道高一尺,魔高一丈”。面临小明的防护计策,安详组就结构了这样一个毗连: http://xxx/?redirect_to=%20javascript:alert('XSS') %20javascript:alert('XSS') 颠末 URL 理会后酿成 javascript:alert('XSS'),这个字符串以空格开头。这样进攻者可以绕事后端的要害词法则,又乐成的完成了注入。 最终,小明选择了白名单的要领,彻底办理了这个裂痕:
通过这个变乱,小明进修到了如下常识:
按照上下文回收差异的转义法则 某天,小明为了加速网页的加载速率,把一个数据通过 JSON 的方法内联到 HTML 中:
插入 JSON 的处所不能行使 escapeHTML(),由于转义 " 后,JSON 名目会被粉碎。 但安详组又发明有裂痕,原本这样内联 JSON 也是不安详的:
于是我们又要实现一个 escapeEmbedJSON() 函数,对内联 JSON 举办转义。 转义法则如下: (编辑:湖南网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |