隨着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攻擊方式