web攻防勇者成名錄-XSS&CSRF

前言

一切的原由都源於一次他人的試探，在一千二百四十四天前，我用Angular1.x寫了一個「樹洞」，發佈在公衆號上。一段時間後，意想不到的是我與一個奇怪評論不期而遇了，沒錯就是它<sctipt>sendTokenToServer()<script>。在以後一分鐘的時間裏，默然發覺，web安全威脅是離咱們這麼的近。若是不是用了angular框架，若是angular沒有作相關的防範，後果是未知的，不過我知道的是，這即是後來的故事的開始，不管如何都值得擁有。

知己知彼，先來看看危害性最強的XSS攻擊

XSS（跨域腳本攻擊）

攻擊描述

當訪問有XSS漏洞的頁面時，可以使攻擊代碼運行在他人的瀏覽器中。這就意味着網站前端的掌控權已經在他人手中了，這樣的結果就可能就會致使用戶身份認證被盜取，用戶行爲被記錄等等狀況的出現。XSS攻擊看似複雜，但其實原理很簡單，通常來自於對輸入的拼接。XSS又分爲好幾種類型。

反射型XSS攻擊

攻擊代碼會植入到url相關的參數中，通常通過假裝與混淆以後，用戶很容易中招。

發動條件

• 頁面有與用戶相關的交互（例如搜索框）
• 先後端都沒對輸入內容過濾或被繞過
• Js從url位置獲取相關參數，而且頁面中有相關回顯
• 用戶主動點擊帶有攻擊代碼的連接

攻擊例子

【親朋好友幫忙砍一刀，點擊得到紅包】
http://localhost:8080/?name=%3Cimg%20src=1%20onerror=alert(document.cookie)%3E%3C/div%3E 
【發送連接砍一刀即有機會得到筆記本電腦，百分百中獎快來參與！】
複製代碼

點擊連接以後token就被獲取了，omg！

有漏洞的代碼【示例】

function getParams(key) {
    const reg = new RegExp(`(&|^)${key}=([^&]*)($|&)`);
    const res = window.location.search.substr(1).match(reg);
    if (res != null) {
        return unescape(res[2]);
    }
    return null;
}
document.getElementById('xss').innerHtml=getParams('name')
複製代碼

那我不點擊可疑連接不就行咯？很惋惜，那也是不行的。

儲存型XSS攻擊

目的是將攻擊代碼持久化到服務器，這樣用戶即便不點擊可疑連接，只訪問相關頁面就能夠被攻擊，更嚴重的是，儲存型的XSS漏洞可被編寫成蠕蟲腳本，具有社交傳播屬性。

必要攻擊條件

• 頁面有與用戶相關交互（富文本，評論框），或一切能持久化的行爲
• 頁面有對相關數據進行回顯
• 先後端都沒對輸入內容過濾或被繞過
• 用戶訪問了儲存攻擊代碼的頁面連接

攻擊例子

http://localhost:8080/article?id=58
複製代碼

點擊連接以後，token又又被獲取了，org。

這個連接中的評論功能有一個儲存型XSS漏洞，用戶一旦點擊進入了這個頁面，那麼存儲在評論區中的攻擊代碼就會執行。只要將攻擊載荷換成可發表文章的腳本，那麼這段攻擊代碼就具有傳播性了。

有漏洞的代碼【示例】

async getCommentById=(id)=>{
    ...
}
getCommentById(123).then(res=>{
    document.getElemtById('comment').innerHtml=res
})
複製代碼

Dom型XSS攻擊

利用交互回顯，破壞正常dom結構，獲得開發者預期以外的結果。跟sql注入相似，都是拼接用戶輸入惹的鍋。

必要攻擊條件

• 頁面有與用戶相關交互（利用dom拼接破壞本來的dom結構）
• 先後端都沒對輸入內容過濾或被繞過
• 用戶主動點擊帶有攻擊代碼的連接or主動點擊儲存了攻擊代碼的頁面連接

攻擊例子&有漏洞的代碼【示例】

若是有漏洞代碼存在，那麼又可經過某種方式插入如下例子的話，就構成了DOM型XSS攻擊了
payload="><sctipt>/*惡意腳本*/getCookie();sendCookie()</sctipt"
...
有漏洞的代碼
document.getElementById('demo').innerHtml='<option data='+ getInput() +'>2333hhhh</option>'
複製代碼

防護手段

http only

經過設置cookie的httpOnly字段，防止經過腳本獲取cookie中的信息。

嚴格控制輸入輸出

關鍵字過濾（好消息是像如今流行的前端框架都幫開發者作了這一層過濾）

七個控制輸入輸出原則

接下來繼續來挑戰另外一種漏洞

CSRF（跨域請求僞造）

攻擊描述

跨域請求僞造的原理也很簡單，因爲網站在發送請求時，會自動地將儲存在本地的cookie帶上，發送給後臺驗證。利用這個特性，就能夠在不知道用戶身份憑證的狀況下，模擬用戶的正常請求。並且在後臺的角度來看，這一切都是正常的，一切都是用戶本身在操做。

攻擊例子

這是brandf網站正常的發表文章接口，以前特地設置的一個CSRF漏洞，看看就好。
http://www.brandf.cn:8010/articles/csrfdemo

經過iframe僞造一下這個請求，再進行一些小小的假裝。

【親朋好友幫忙砍一刀，點擊得到紅包】 http://localhost:8080 
【發送連接砍一刀即有機會得到筆記本電腦，百分百中獎快來參與！】
複製代碼

用戶在網站http://www.brandf.cn登陸以後，又點擊進入隱藏了攻擊代碼的網站（http://localhost:8080）。這時，就會在用戶不知情的狀況下，在用戶的帳號裏發表一篇文章。細思恐極，若是這是一個更加危險的操做呢？好比轉帳等等。

若是存在漏洞的地方擁有社交屬性，例如一個發送消息的接口是能夠僞造的，那麼這個CSRF漏洞就擁有了傳播性，也就是CSRF蠕蟲了。

必要攻擊條件

• 用戶在已登陸的狀態下，點擊了惡意連接
• 網站的用戶憑證經過cookie傳遞

防護手段

後臺校驗referer字段

但請求頭中的referer字段能被僞造，存在被繞過的風險。既然CSRF利用了瀏覽器請求默認帶上cookie的機制，那麼能不能從源頭去杜絕呢？

JWT

JWT即web身份令牌技術，最重要的一點是它將用戶憑證放在請求body中，杜絕了瀏覽器默認行爲自動帶上cookie所帶來的風險。

最後

XSS,CSRF這兩種能夠講是前端最多見也是危害最大的漏洞，固然有不少時候漏洞是由人爲主觀形成的，例如弱密碼等等。同時在過去的十分鐘時間裏，很感謝你閱讀了這篇文章，若是能對你有幫助，不妨點個贊哈哈，以上的全部例子和方法都是爲了你們能更好地去認識到這些漏洞的危害，更好的去作好防範，同時也提升安全意識。例子均在本地實現，有興趣的朋友可有在本地寫寫，但別去其餘網站亂試。推薦幾個web漏洞練習平臺，Pikachu漏洞平臺，DVWA。

CSP瀏覽器安全策略

CSP（Content-Security-Policy）爲何要最後單獨拿出來說呢，由於CSP須要後端的配合，在響應頭中加入相關字段合規則。CSP至關於在瀏覽器中設置一個資源白名單，在白名單中的資源才能加載，能很大程度上提高網站的安全性。這裏就不展開了，以後有會一篇詳細的使用配置介紹嘿嘿。