前端的安全問題與防護策略

在前端的開發中，安全是咱們必需要了解的一環，即便前端很難說有真正的安全，可是瞭解這些攻擊有助於咱們如何去規避問題，畢竟安全問題都是須要提早預防，而不能等到真正發生的時候纔來解決。

ClickJacking（點擊劫持）

1.什麼是ClickJacking？

ClickJacking（點擊劫持）是一種視覺上的欺騙手段。大概有兩種方式，一是攻擊者使用一個透明的iframe，覆蓋在一個網頁上，而後誘使用戶在該頁面上進行操做，此時用戶將在不知情的狀況下點擊透明的iframe頁面；二是攻擊者使用一張圖片覆蓋在網頁，遮擋網頁原有位置的含義。

2.如何防護ClickJacking

對於第一種狀況咱們能夠經過設置http響應頭標記X-Frame-Option來防止點擊劫持。

X-Frame-Options：X-Frame-Options HTTP 響應頭是用來給瀏覽器指示容許一個頁面能否在<frame>,<iframe>或者<object>中展示的標記。網站可使用此功能，來確保本身網站的內容沒有被嵌到別人的網站中去，也從而避免了點擊劫持 (clickjacking) 的攻擊。

標記值	說明
DENY	表示該頁面不容許在 frame 中展現，即使是在相同域名的頁面中嵌套也不容許。
SAMEORIGIN	表示該頁面能夠在相同域名頁面的 frame 中展現。
ALLOW-FROM uri	表示該頁面能夠在指定來源的 frame 中展現。

除此以外咱們還可使用CSP（Content-Security-Policy）裏的frame-ancestors或frame-src來指定頁面容許嵌入哪些頁面。

對於不使用X-Frame—Options或CSP，參考網上的解決方法，在打開頁面的時候檢查一下window.top和window.self是否相等來決定是否重定向。

if (window.self != window.top) {
    top.location.href = self.location.href
}
複製代碼

至於第二種狀況使用圖片遮擋網頁原有位置的含義，這種站點自己就是一個惡意站點，而不是來自第三方的攻擊，這裏不作討論。

CSRF（跨站僞造請求）

1.什麼是CSRF？

CSRF（跨站僞造請求）全稱爲 Cross-site request forgery，CSRF是經過假裝成受信任用戶的請求來利用受信任的網站。例如：一位用戶在站點A登陸了，而且站點A把信息存儲在用戶本地，以後當用戶打開站點B，站點B的惡意代碼竊取了這位用戶在站點A的我的用戶信息，就能夠僞裝成這位用戶去請求站點A。

2.如何防護CSRF

• cookie不存儲重要信息
• cookie設置httpOnly，secure，此外path和domain儘可能不使用默認值
• cookie設置SameSite（這個屬性還不是一個規範，不肯定是否有用）
• 服務端增長多重安全校驗
• 使用https協議或其餘安全協議發送請求

XSS（跨站腳本攻擊）

1.什麼是XSS？

XSS（跨站腳本攻擊）全稱爲Cross Site Scripting，爲了和CSS文件（Cascading Style Sheets）區分，故稱爲XSS。XSS經過往Web頁面插入惡意代碼，當用戶訪問該頁面時，執行嵌入的惡意代碼，以此來達到惡意攻擊用戶的目的。

XSS攻擊又分爲存儲型和反射型。

存儲型：通常是指咱們頁面中表單提交的數據存在惡意代碼被存儲到數據庫中。

反射型：須要欺騙用戶本身去點擊連接才能觸發XSS代碼

2.如何防護XSS

• CSP（Content-Security-Policy）

CSP（Content-Security-Policy）容許站點管理者在指定的頁面控制用戶代理的資源。

設置CSP能夠極大程度上提升頁面安全，CSP容許咱們設置一套很是完善的資源容許請求規則，在此只大概羅列幾個。

標記值	說明
script-src	限制javascript 源。
style-src	限制層疊樣式表文件源。
img-src	限制圖片和圖標源。
media-src	限制經過<audio> 或<video> 標籤加載的媒體文件源。

• SRI（Subresource Integrity）

在項目中咱們可能會引入一些第三方的文件，由於文件在第三方的服務器裏，理論上第三方是有可能篡改文件對使用第三方的文件的站點進行攻擊。在這種狀況下咱們可使用SRI來保證咱們引入的文件不被篡改。

SRI（子資源完整性 Subresource Integrity ）用於讓瀏覽器檢查所下載的來自第三方的資源（例如 CDN）未被惡意篡改。它使用哈希值檢查確保第三方資源的完整性。只要開發者提供了被需下載資源的哈希值，瀏覽器就能夠檢查實際下載的文件是否與預期的哈希值匹配。

如何使用SRI？只需給 script 或 style 標籤添加integrity屬性便可。

<script crossorigin="anonymous" integrity="shaxxx-xxxxxx" src="xxx.com/xxx.js"></script>
複製代碼

要注意的是由於瀏覽器須要下載資源內容進行計算，因此若是引用第三方的文件須要第三方服務器支持跨域請求（CORS），客戶端則須要加上crossorigin="anonymous"屬性。

另外，咱們還可使用CSP設置require-sri-for強制頁面請求js或css文件使用SRI。

• X-XSS-Protection

X-XSS-Protection響應頭是瀏覽器檢測到頁面存在XSS攻擊時，設置瀏覽器的行爲。一般默認值爲1，檢測到XSS攻擊瀏覽器將會刪除不安全的部分。

標記值	說明
0	禁止XSS過濾。
1	啓用XSS過濾（一般瀏覽器是默認的）。 若是檢測到跨站腳本攻擊，瀏覽器將清除頁面（刪除不安全的部分）。
1; mode=block	啓用XSS過濾。 若是檢測到攻擊，瀏覽器將不會清除頁面，而是阻止頁面加載。
1; report=<reporting-uri>	啓用XSS過濾。 若是檢測到跨站腳本攻擊，瀏覽器將清除頁面並使用CSP report-uri指令的功能發送違規報告。

• 對提交的數據encode或過濾

在頁面裏提交的數據須要存儲到數據庫的場景下，咱們須要對提交的數據進行encode或者某些特殊字符進行過濾，特別是某些數據咱們須要用在src或href裏使用的狀況。

除此以外，富文本也是XSS常常發生的重災區，對於富文本提交的數據是必定要進行過濾的。

總結

上文所述基本上是咱們前端裏常見的安全問題，其實對於前端來講很難有真正的安全所言，畢竟咱們的代碼都是明文跑在瀏覽器上。

而如今基本上不使用https協議的請求所有都是不安全的，對於頁面上數據提交進行過濾校驗也是常規操做，大部分場景咱們都是使用瀏覽器的機制來幫助咱們防護攻擊，增長第三方攻擊的成本。