前端 web安全面試題總結

時間 2020-08-21

標籤前端 web 安全面試總結欄目 HTML 简体版

原文原文鏈接

關於csrf,什麼是csrf,怎麼防範它?

簡單點說，CSRF 就是利用用戶的登陸態發起惡意請求。javascript

經過一個故事來介紹csrf

這是最近在知乎上看到的一個例子十分形象(因爲是微信內分享,我如今找不到連接了,直接把故事內容補上吧)php

防盜系統啓動
媽媽: 給我看着衣服呀
小孩: 好的html

小偷來了前端

正常工做:
小孩: 你是誰?
小偷: 我是張三
小孩:媽媽,有人偷衣服
媽媽: 誰?
小孩: 張三
小偷被抓java

漏洞:
小孩: 你是誰?
小偷: 我叫逗你玩
小孩: 媽媽有人偷衣服呀
媽媽: 誰?
小孩: 逗你玩
媽媽: ...git

csrf是讓用戶住不知情的狀況下,冒用其身份發起了一個請求
小偷: 你媽媽喊你去買洗衣粉github

如何攻擊

假設網站中有一個經過 Get 請求提交用戶評論的接口，那麼攻擊者就能夠在釣魚網站中加入一個圖片，圖片的地址就是評論接口算法

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
複製代碼

若是接口是 Post 提交的，就相對麻煩點，須要用表單來提交接口segmentfault

<html>
    <head>
        <script type="text/javascript">
            function steal()
                {
                &emsp; iframe = document.frames["steal"];
                iframe.document.Submit("transfer");
            }
        </script>
    </head>

    <body onload="steal()">
        <iframe name="steal" display="none">
            <form method="POST" name="transfer"&emsp;action="http://www.myBank.com/Transfer.php">
                <input type="hidden" name="toBankId" value="11">
                <input type="hidden" name="money" value="1000">
            </form>
        </iframe>
    </body>
</html>
複製代碼

如何防護

防範 CSRF 能夠遵循如下幾種規則：後端

Get 請求不對數據進行修改
不讓第三方網站訪問到用戶 Cookie
阻止第三方網站請求接口
請求時附帶驗證信息，好比驗證碼或者 token

SameSite

能夠對 Cookie 設置 SameSite 屬性。該屬性設置 Cookie 不隨着跨域請求發送，該屬性能夠很大程度減小 CSRF 的攻擊，可是該屬性目前並非全部瀏覽器都兼容。

驗證 Referer

對於須要防範 CSRF 的請求，咱們能夠經過驗證 Referer 來判斷該請求是否爲第三方網站發起的。

在後臺接收到請求的時候,能夠經過請求頭中的Referer請求頭來判斷請求來源

Token

服務器下發一個隨機 Token（算法不能複雜），每次發起請求時將 Token 攜帶上，服務器驗證 Token 是否有效。

跨站腳本攻擊—XSS

SS 介紹

XSS 是跨站腳本攻擊（Cross Site Scripting）的簡寫，可是從首寫字母命名的方式來看，應該取名 CSS，但這樣就和層疊樣式表（Cascading Style Sheets，CSS）重名了，因此取名爲 XSS。

XSS 攻擊，通常是指攻擊者經過在網頁中注入惡意腳本，當用戶瀏覽網頁時，惡意腳本執行，控制用戶瀏覽器行爲的一種攻擊方式。

XSS 危害

竊取用戶Cookie，獲取用戶隱私，盜取用戶帳號。
劫持用戶（瀏覽器）會話，從而執行任意操做，例如進行非法轉帳、強制發表日誌、發送電子郵件等。
強制彈出廣告頁面，刷流量等。
傳播跨站腳本蠕蟲，網頁掛馬等。
結合其餘漏洞，如 CSRF 漏洞，實施進一步的攻擊。
......

XSS 分類

XSS 攻擊按是否把攻擊數據存進服務器端，攻擊行爲是否伴隨着攻擊數據一直存在，可分爲非持久型 XSS 攻擊和持久型 XSS 攻擊。

XSS 攻擊按攻擊方式又可分爲反射型 XSS、DOM 型 XSS、存儲型 XSS，其中反射型 XSS 和 DOM 型 XSS 算是非持久型 XSS 攻擊，而存儲型 XSS 算是持久型 XSS 攻擊。

反射型 XSS（Reflected XSS）

攻擊者誘導用戶訪問一個帶有惡意代碼的 URL 後，服務器端接收數據後處理，而後把帶有惡意代碼的數據發送到瀏覽器端，瀏覽器端解析這段帶有 XSS 代碼的數據後當作腳本執行，最終完成 XSS 攻擊。
由於這個過程就像一次反射，故稱爲反射型 XSS。

攻擊步驟：
一、攻擊構造出特殊的 URL ，其中包含惡意代碼。
二、用戶被誘導打開帶有惡意代碼的 URL，服務器端將惡意代碼從 URL 中取出當作參數處理，而後返回給用戶帶有惡意代碼的數據。
三、用戶瀏覽器接收到響應解析執行，混在其中的惡意代碼也被執行。
四、惡意代碼竊取用戶敏感數據發送給攻擊者，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

舉例

下面是一個正常的搜索流程

一、打開首頁，輸入搜索內容

https://www.kkkk1000.com/xss/Reflected/index.html

二、開始搜索，查看結果

https://www.kkkk1000.com/xss/Reflected/searchResult.html?kw=斗羅大陸

可是若是沒有搜索到結果，後端也會返回用戶輸入的內容，而後顯示在頁面上。

https://www.kkkk1000.com/xss/Reflected/searchResult.html?kw=xxx

由於這裏沒有對用戶輸入的數據作處理，因此咱們構造這樣一個連接：

https://www.kkkk1000.com/xss/Reflected/searchResult.html?kw=<script>alert("xss")</script>

而後誘導他人點擊這個連接，就能夠完成一次反射型 XSS 攻擊。

而對於這麼長的連接，咱們還能夠假裝假裝，轉爲短網址或者二維碼。

短網址：

http://i6q.cn/4TJcII

二維碼：

也許你以爲只是一個彈框而已，問題不大，但若是咱們把攻擊代碼變爲加載一個第三方的 js 文件呢？變爲用document.cookie盜取 cookie 的代碼呢？總之若是是真的攻擊的話，就不會只是一個彈框這麼簡單了。

DOM 型 XSS（DOM-based XSS）

DOM 型 XSS 造成緣由是經過修改頁面的 DOM 節點造成的 XSS。
DOM 型 XSS 攻擊中，取出和執行惡意代碼都由瀏覽器端完成，屬於前端自身的安全漏洞。

攻擊步驟：
一、攻擊者構造出特殊的 URL，其中包含惡意代碼。
二、用戶被誘導打開帶有惡意代碼的 URL。
三、用戶瀏覽器接收到響應後解析執行，前端 JavaScript 取出 URL 中的惡意代碼並執行。
四、惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

舉例

下面是一個物流詳情的頁面，在 URL 上有快遞編號這個參數，經過這個參數來獲取數據。

https://www.kkkk1000.com/xss/dom/index.html?serialNumber=YT40359134268305

由於在源碼中能夠看到，頁面上顯示的快遞編號，是直接取的 URL 上的參數顯示的。因此咱們構造這樣一個網址：

https://www.kkkk1000.com/xss/dom/index.html?serialNumber=<script>alert("xss")</script>

而後誘導他人點擊這個連接，就能夠完成一次 DOM 型 XSS 攻擊。

存儲型 XSS（Stored XSS）

存儲型 XSS 跟反射型 XSS 的區別是：存儲型 XSS 的惡意代碼存在服務器上，反射型 XSS 的惡意代碼存在 URL 裏。

存儲型 XSS 攻擊時惡意腳本會存儲在目標服務器上。當瀏覽器請求數據時，腳本從服務器傳回並執行。它是最危險的一種跨站腳本，比反射性 XSS 和 DOM 型 XSS 都更有隱蔽性，由於它不須要用戶手動觸發。任何容許用戶存儲數據的 Web 程序均可能存在存儲型 XSS 漏洞。若某個頁面遭受存儲型 XSS 攻擊，全部訪問該頁面的用戶都會被 XSS 攻擊。

攻擊步驟：
一、攻擊者把惡意代碼提交到目標網站的服務器中。
二、用戶打開目標網站，網站服務器端把帶有惡意代碼的數據取出，當作正常數據返回給用戶。
三、用戶瀏覽器接收到響應解析執行，混在其中的惡意代碼也被執行。
四、惡意代碼竊取用戶敏感數據發送給攻擊者，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

舉例

這是一個能夠評論的文章的頁面

https://www.kkkk1000.com/xss/Stored/index.html

可是，評論的內容是沒有處理過的，因此咱們若是輸入這樣的內容：
<script>alert("xss")</script>
一樣是能夠做爲評論的。

咱們用這樣的內容做爲評論後，全部打開這篇文章的用戶都會遭到存儲型 XSS 攻擊。

防護方法

瀏覽器自帶防護（X-XSS-Protection）

HTTPX-XSS-Protection響應頭是 Internet Explorer，Chrome 和 Safari 的一個功能，當檢測到跨站腳本攻擊(XSS)時，瀏覽器將中止加載頁面。

他能夠設置4個值：

X-XSS-Protection: 0     
禁止XSS過濾。     

X-XSS-Protection: 1       
啓用XSS過濾（一般瀏覽器是默認的）。 若是檢測到跨站腳本攻擊，瀏覽器將清除頁面（刪除不安全的部分）。  

X-XSS-Protection: 1; mode=block  
啓用XSS過濾。 若是檢測到攻擊，瀏覽器將不會清除頁面，而是阻止頁面加載。  

X-XSS-Protection: 1; report=<reporting-uri>    
啓用XSS過濾。 若是檢測到跨站腳本攻擊，瀏覽器將清除頁面並使用CSP report-uri指令的功能發送違規報告。

這種瀏覽器自帶的防護功能只對反射型 XSS 有必定的防護力，其原理是檢查 URL 和 DOM 中元素的相關性，但這並不能徹底防止反射型 XSS，並且也並非全部瀏覽器都支持X-XSS-Protection。

轉義

在 XSS 攻擊中，攻擊者主要是經過構造特殊字符來注入腳本，因此對用戶的輸入進行檢測就頗有必要，而且須要在客戶端與服務端都進行輸入檢測，而後對用戶輸入的數據進行轉義。

主要就是對輸入所包含的特殊字符進行轉義，如<，>，&，"，'，來防止 XSS 攻擊。

下面是一個用於轉義的方法：

function escapeHTML(str) {
    if (!str) return '';
    str = str.replace(/&/g, "&amp;");
    str = str.replace(/</g, "&lt;");
    str = str.replace(/>/g, "&gt;");
    str = str.replace(/"/g, "&quot;");
    str = str.replace(/'/g, "&#39;");
    return str;
};

過濾

在富文本中由於須要保留 HTML ，因此咱們不能使用轉義的方法防護 XSS 攻擊，這裏使用過濾的方式防護 XSS 攻擊，也就是經過只使用白名單容許的 HTML 標記及其屬性，來防護攻擊。

這裏推薦一個名爲XSS的組件，這就是一個根據白名單過濾 HTML，防止 XSS 攻擊的組件。

內容安全策略（CSP）

內容安全策略（Content Security Policy，CSP），實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源能夠加載和執行，大大加強了網頁的安全性。

兩種方法能夠啓用 CSP。一種是經過 HTTP 頭信息的 Content-Security-Policy 的字段。

Content-Security-Policy: script-src 'self'; 
                         object-src 'none';
                         style-src cdn.example.org third-party.org; 
                         child-src https:

另外一種是經過網頁的<meta>標籤。

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">

上面代碼中，CSP 作了以下配置。