常見的前端漏洞及防護措施

隨着WEB應用愈來愈複雜,用戶對WEB安全也愈來愈重視。再加上前端工程師的工做面已逐漸擴大,開始覆蓋到各類業務邏輯,所以如何應對各類WEB安全問題就顯得十分重要,今天咱們就來探討下前端開發編碼工做中可能形成的WEB安全問題及防護措施javascript

a連接target="_blank"屬性可形成釣魚攻擊

簡介

若是你在頁面上的超連接a標記上添加了target='_blank'屬性,當用戶點擊了該超連接後,瀏覽器會單獨新建一個標籤頁來顯示該連接所指向的內容。可是在這一瞬間,瀏覽器會容許新建的標籤頁經過一個名爲"window.opener"的瀏覽器API來與以前的網頁進行短暫通訊。此時,攻擊者就能夠將惡意代碼嵌入在新打開的網站中,而後檢測用戶是從哪個網站跳轉過來的,最後再利用window.opener接口來迫使原始網頁打開一個新的URL地址。php

攻擊實例

你的正常登錄的網頁html

<!-- 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頁面的地址被更改,例子中改的是百度頁面,在現實中攻擊者可將其改成模擬的該網站的登陸界面,用戶在未發現網頁已被篡改的狀況下將登陸信息填寫提交給了攻擊者java

防護措施

a連接中使用target="_blank"屬性時需添加上 rel="noopener noreferrer",noreferrer是因爲Firefox不支持noopener而添加的算法

XSS攻擊

簡介

跨站腳本攻擊,英文全稱是Cross Site Script,在安全領域叫作「XSS」。XSS攻擊一般指黑客經過「HTML注入」篡改了網頁,插入了惡意腳本,從而在用戶瀏覽網頁時,控制用戶瀏覽器的一種攻擊。
XSS根據效果的不一樣能夠分爲以下幾類:chrome

  • 反射性 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彈窗,攻擊成功。

防護措施

  1. 後端在接收請求數據時,須要作輸入檢查,過濾特殊符號和標籤
  2. 前端在顯示後端數據時,須要作輸出檢查,不只是標籤內容須要過濾、轉義,就連屬性值和樣式也均可能須要。
  3. 在處理富文本時能夠設置標籤白名單
  4. 設置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攻擊方式

相關文章
相關標籤/搜索