随着WEB应用越来越复杂，用户对WEB安全也越来越重视。再加上前端工程师的工作面已逐渐扩大，开始覆盖到各种业务逻辑，因此如何应对各种WEB安全问题就显得十分重要，今天我们就来探讨下前端开发编码工作中可能造成的WEB安全问题及防御措施
a链接target="_blank"属性可造成钓鱼攻击
简介
如果你在页面上的超链接a标记上添加了target='_blank'属性，当用户点击了该超链接后，浏览器会单独新建一个标签页来显示该链接所指向的内容。但是在这一瞬间，浏览器会允许新建的标签页通过一个名为"window.opener"的浏览器API来与之前的网页进行短暂通信。此时，攻击者就可以将恶意代码嵌入在新打开的网站中，然后检测用户是从哪一个网站跳转过来的，最后再利用window.opener接口来迫使原始网页打开一个新的URL地址。
攻击实例
你的正常登陆的网页
<!-- test1.html -->
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<a href="./test2.html" target="_blank">你想去的地方</a>
</body>
</html>
点击超链接，打开test2.html
<!-- test2.html -->
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<script>
window.opener.location = "http://www.baidu.com/";
</script>
</body>
</html>
test2页面打开后通过js修改window.opener.location使得之前的test1页面的地址被更改，例子中改的是百度页面，在现实中攻击者可将其改为模拟的该网站的登录界面，用户在未发现网页已被篡改的情况下将登录信息填写提交给了攻击者
防御措施
a链接中使用target="_blank"属性时需添加上 rel="noopener noreferrer"，noreferrer是由于Firefox不支持noopener而添加的
XSS攻击
简介
跨站脚本攻击，英文全称是Cross Site Script，在安全领域叫做“XSS”。XSS攻击通常指黑客通过“HTML注入”篡改了网页，插入了恶意脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。
XSS根据效果的不同可以分为如下几类：
- 反射性 XSS
发出请求时，XSS代码出现在URL中，作为输入提交到服务器端，服务器端解析后响应，XSS代码随响应内容一起传回给浏览器，最后浏览器解析执行XSS代码，这个过程像一次反射，因此叫做反射型XSS - 存储型XSS
存储型XSS会把用户输入的数据存储到服务器，这种攻击具有很强的稳定性,也叫“持久型XSS” - DOM Based XSS
通过修改页面的DOM节点形成的XSS
反射性 XSS
有一个xss.php页面用于接收并显示传递过来的参数
$input = $_GET["test"];
echo "<div>".$input."</div>";
在其他网页上有如下一个链接
<a href="xss.php?test=<script>alert('XSS')</script>">诱你点击</a>
测试得知：
IE8和firfox都弹窗显示XSS，攻击成功。chrome则被浏览器的xss保护策略阻止
存储型XSS
发表的文章中含有恶意脚本例如：你可以试试看<script>alert('xss')</script>，后端没有对文章进行过滤就将内容存到数据库，当其他用户再次看这篇文章时，包含的恶意脚本被执行
DOM Based XSS
<script type="text/javascript">
function test() {
var str = document.getElementById("test").value;
document.getElementById("t").innerHTML = "<a href='" + str + "'>test</a>";
}
</script>
<div id="t"></div>
<input type="text" id="test" value="">
<input type="submit" value="submit" onclick="test()">
如果在输入框中填写'><img src=# onerror=alert('xss') /><'，点击按钮提交后浏览器会产生XSS弹窗，攻击成功。
防御措施
- 后端在接收请求数据时，需要做输入检查，过滤特殊符号和标签
- 前端在显示后端数据时，需要做输出检查，不仅是标签内容需要过滤、转义，就连属性值和样式也都可能需要。
- 在处理富文本时可以设置标签白名单
- 设置HttpOnlly防止cookie劫持
CSRF攻击
简介
CSRF（Cross Site Request Forgery），中文是跨站点请求伪造。CSRF攻击者在用户已经登录目标网站之后，诱使用户访问一个攻击页面，利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击目的。
攻击实例
// submit.php 通过get请求获取数据
$username = $_COOKIE['username'];
$productId = $_GET['pid'];
// 这里进行购买操作
store_into_database($username, $productId);
echo $username . '买入商品：' . $productId;
黑客攻击页面
<!DOCYTPE HTML>
<html>
<head>
<meta charset="utf-8" />
</head>
<body>
<img src="http://localhost:8080/csrf/submit.php?pid=1" />
</body>
</html>
当你正常浏览网页的时候会生成认证信息，此时黑客诱使你点击攻击页面，该页面会利用你当前的认证信息，从而对数据进行操作
防御措施
1.合理使用POST和GET
GET方法提交数据很容易被拿来做CSRF攻击，使用POST只能降低攻击风险，并不能杜绝，攻击者在第三方页面构造一个form就可以用POST提交数据构成CSRF攻击。
2.使用验证码
在通常情况下，验证码能很好遏制CSRF攻击。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段，不能作为主要解决方案。
3.Referer信息检查
通过检查referer信息是否合法来判断用户是否被CSRF攻击，仅仅是满足防御的充分条件，Referer Check的缺陷在于服务器并非什么时候都收到Referer，并且Referer信息可以伪造
4.使用 Token
Token需要足够随机，必须使用足够安全的随机数生成算法
Token可以放在用户的Session中或Cookie中，在提交请求时，服务器只需要验证表单中Token与用户Session（或Cookie）中的Token是否一致，一致则认为合法
在使用Token时尽量把Token放在表单中，使用POST提交，以避免Token泄露
如果该网站还存在XSS漏洞，那么使用Token方法防御CSRF攻击也就无效了（XSRF攻击）
参考文献：
1.《白帽子讲WEB安全》
2.浅谈CSRF攻击方式