你的网站被攻击了吗——前端XSS
一名合格的前端工程师除了能够写出兼容性良好且符合需求的具有可读性的代码，还应有意识的关注前端网站安全问题。虽然现在有的浏览器（如chrome）会主动拦截或提示存在跨站攻击，还有很多平台提供跨站攻击监测，但是这个问题依然值得开发人员注意。本文总结几个最近遇到的跨站漏洞，和大家共享~
百度百科中将跨站攻击定义为：即Cross Site Script Execution(通常简写为XSS)是指攻击者利用网站程序对用户输入过滤不足，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。
下面举例说明几个常见的跨站攻击（不方便贴出真实案例，原因你懂的）：
（1）URL的XSS
假设页面中有如下代码：
<a href=”http://xxx/a?b=c”></a>，即页面正常访问的url为http://xxx/a?b=c
XSS：
如果在页面地址输入http://xxx/a?b=c”><iframe onload%3Dalert()>，回车，则会在打开的页面中弹出一个只有确定按钮的弹窗。(%3d解析为=)
分析：
通过查看页面源码，可以发现原来的<a href=”http://xxx/a?b=c”></a>被拆分成了如下代码
<a href=”http://xxx/a?b=c”>
<iframe onload=”alert()”>
<html>
<head>
</head>
<body>
</body>
</html>
</iframe>
</a>
注意红字部分代码，实际的url链接已经被一段代码截断了。
同理，可以衍生出的XSS攻击有http://xxx/a?b=”/><script>alert()</script>等等，而<script></script>之间可以做的事就更多了，想想都可怕
解决：
知道了XSS的原因和可能造成的危害，那么该如何解决这个漏洞呢？
其实ECMA还是提供有补救方法的，你可以使用escape()、encodeURI()或者encodeURIComponent()三者中的其中一个方法对整个url或者某个（些）参数进行转码，三者的简单区别可以查看我的上上篇笔记《这些不能混淆的前端知识》，在JS类第6条中有提及，详细区别请左转百度
。
点击查看更多URL编码
（2）表单的XSS
假如你的网站有可供用户输入的表单元素的，并且表单内容需要在当前或其他页面中展示的（例如评论），那就要注意了，输入内容就可能成为XSS的攻击途径。
XSS：
假如用户在输入框中输入<h1>XSS</h1>，然后提交，此时如果前后台均不对提交内容进行处理，那么在提交内容输出的页面就会显示具有标题1效果的XSS。
关于表单，还有一类XSS，后端人员或许会更为熟悉，叫做sql注入，它通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。（由于没有深入体会，在此就不做详谈了，请感兴趣的童鞋左转百度）
分析：
这个攻击和上一个攻击的原理有点相似，都是利用浏览器对HTML标签的解析在页面中注入了非原页面中需要的代码，因为在输出页面直接输出的还是<h1>XSS</h1>，而浏览器会对这段HTML代码进行解析，试想如果输入的是更具破坏性的代码，例如盗取用户信息的js、死循环等等，那么造成的后果也就可想而知了。
解决：
方法1：转换成URL Encoding格式，在输入页面使用escape()、encodeURI()或者encodeURIComponent()三者中的其中一个方法对输入内容进行转码，在输出页面使用相应的unescape()（不推荐使用）， decodeURI()或者decodeURIComponent()进行解码。
方法2：转换成HTML Entity Encoding格式，利用正则表达式，自定义转码和解码方法，如：
//输入页面转码
var htmlEncode = function (str) {
return str.replace(/[<>&”]/g, function (c) {
return {‘<‘: ‘<’, ‘>’: ‘>’, ‘&’: ‘&’, ‘”‘: ‘"’}[c];
});
};
//输出页面解码
var htmlDecode = function (str) {
var arrEntities = {‘lt’: ‘<‘, ‘gt’: ‘>’, ‘nbsp’: ‘ ‘, ‘amp’: ‘&’, ‘quot’: ‘”‘};
return str.replace(/&(lt|gt|nbsp|amp|quot);/ig, function (all, t) {
return arrEntities[t];
});
};
常见的可能造成XSS跨站脚本攻击的字符及其HTML编码如下：
“ " ‘ ' & & < < > >
除了常用的编码外，任何字符都可以使用其ASCII码进行HTML编码，如
% % * *
点击查看更多HTML编码
方法3：还有个治标不治本的方法，在输出页面使用innerText（对应JQ->text()）而不用innerHTML（对应JQ->html()）输出，当然如果你使用的是模板输出（例如<%=xxx%>、${xxx}等），这个方法就显得不那么适用了。
（3）a链接中的target=”_blank”属性产生的钓鱼漏洞风险
XSS：
网站中使用target=”_blank”属性，攻击者就可以将恶意代码嵌入在新打开的网站中，然后检测用户是从哪一个网站跳转过来的，最后再利用window.opener接口来迫使原始网页打开一个新的URL地址。（引自《链接地址中的target=”_blank”属性，为钓鱼攻击打开了大门》）
解决：
添加新特性：rel=”noopener”（火狐不完全支持该属性，使用rel=”noopenernoreferrer”）
在chrome 49+，Opera 36+，打开添加了rel=”noopener”的链接， window.opener 会为null。在老的浏览器中，可以使用 rel=noreferrer 禁用HTTP头部的Referer属性，使用下面JavaScript代替target=”_blank”的解决此问题：
var newWnd = window.open(“http://xxx”);
newWnd.opener = null;
（4）其他
当然除了以上提到的XSS，还有些安全问题是前端人员需要注意和尽量避免的，比如涉及数据库的更改操作（insert、update和delete），表单最好使用post请求。
XSS测试用例（引自RSnake的个人主页http://ha.ckers.org/xss.html，但我使用蓝灯也没打开这个网站
，以下是源自《XSS跨站脚本攻击剖析与防御 》一书中的截图XSS Cheat Sheet）：
XSS还可以盗取账户cookie信息来免账号名密码登录，可以篡改数据，一旦被不法分子利用漏洞，造成的后果还是相当严重的。
暂时整理几个，想到再更新，最后安利自己收藏的有关前端网站的收藏夹 -> 前端站点收藏http://www.36zhen.com/my?id=12496
（转载或直接复制发表请注明原文作者controlling，原文地址http://www.w3cfuns.com/notes/34250/868b4f382fc9a6c5625f18f0b87668e4.html）
