Web前端攻防，一不小心就中招了

來自：簡書

作者：杜文

隨著各瀏覽器安全功能的提高，前端防禦面臨的問題也沒有之前那麼複雜，但瀏覽器的防禦措施並不能百分百的保證網站的安全。

瀏覽器的XSS Auditor，使得反射型xss幾乎被廢；CSP(Content-Security-Policy)、X-XSS-Protection可以禁止不可信源的腳本執行！無疑，這對xss攻擊是一記重拳。但是道高一尺，魔高一丈，尤其是在安全界，永遠應該記住的一句箴言就是「只有相對的安全，沒有絕對的安全」。

本文重點介紹現代瀏覽器的安全特性以及瀏覽器依然不能防禦的攻擊手段。

01-

XSS

XSS攻擊：跨站腳本攻擊(Cross Site Scripting)，為不和 CSS混淆，故將跨站腳本攻擊縮寫為XSS。

為什麼叫跨站腳本？簡單來說，就是在一個網站上運行了該網站之外的js腳本(當然，開發者自已引用的可信源的js不算，比如使用了cdn的 jQuery )。

02-

一個經典的例子

假設有一個搜索頁面，關鍵字以Get方法傳遞。假設，搜索頁面在輸出結果時會無過濾的將用戶的關鍵字回顯到網頁上，大致邏輯如下：

//xss.php

if(isset($_REQUEST["wd"]))

$wd=$_REQUEST["wd"];

if($wd){

echo "

關鍵字 $wd 搜索的結果如下：

"

}

...

?>

然後搜索請求的鏈接是:

http://localhost/test/haker/xss.php?wd=

或者為了隱蔽編一下碼：

http://localhost/test/haker/xss.php?wd=ddd%3Cscript%3Ealert(%22%22)%3C/script%3E

在es6下，你甚者可以用unicode碼點。

如果是在幾年前，你的瀏覽器大致都會彈出這樣一個窗口：

alert

然而，現在不行了，在chrome和safari下，如果發現響應中包含請求參數中相同的代碼字元串，它們就會拒絕執行這些代碼，你會收到如下的錯誤提示：

The XSS Auditor refused to execute a script in http://localhost/test/haker/xss.php?wd=ddd%3Cscript%3Ealert(%22xss%22)%3C/script%3E because its source code was found within the request. The auditor was enabled as the server sent neither an X-XSS-Protection nor Content-Security-Policy header.

03-

XSS Auditor

xss auditor是Chrome 和 Safari中內建的一個防禦xss攻擊的功能模塊，相當於一個審計器，有預設規則，主要功能就是針對上述這種情況。此功能默認是開啟的，當然也可以關閉，需要在response header中顯式指定：

//關閉 xss auditor

X-XSS-Protection: 0

當然，更強大的是，觸發後還可以將詳情上報，便於分析跟蹤：

X-XSS-Protection: 1; report=http://example.com/your_report_URI

也可以使用block模式：一旦觸發，當前頁面就會終止，並同時展示一個空白頁面給用戶：

X-XSS-Protection: 1; mode=block

如果將請求換成post，xss auditor還會被觸發嗎？答案是：可以！

XSS Auditor的缺點

我們將後台邏輯改一下，給每個">"後加一個分號。

if(isset($_REQUEST["wd"]))

$wd=str_replace(">",">;",$_REQUEST["wd"]);

if($wd){

echo "

關鍵字 $wd 搜索的結果如下：

"

}

?>

然後依然是之前的鏈接，刷新：

alert

成功了，當然本例只是一個說明，通常情況下，我們都會對用戶提交的數據進行一些處理，如果這些處理導致和提交的內容不一樣了，但是仍然可以執行，比如像本例一樣。那麼xss auditor 就無能為力了。不過xss auditor本身的智能度也挺高，像字元編碼，大小寫變化這種變化依然躲不過xss auditor。

04-

存儲型xss

比如網站有個留言板功能，但後台未對用戶輸入進行過濾，攻擊者可以在留言編輯框中輸入：

...

在b頁面中，製造一個表單，然後直接觸發提交，依然可以！

07-

CSRF攻擊防禦

隨機值法

後台對每一次請求都生成一個隨機值，保存在session中，然後再將該值發送給頁面，可以在cookie中，也可以在一個隱藏的表單中（大多數後台框架都是這麼做的，如php的symfony、laraval）,甚至也可以是在驗證碼中。下面以表單為例來說明：

$hash = random(100000);

?>

然後提交時，服務端再對比hash值是不是和session中一樣。 攻擊者網站時無法預估這個hash的。但是請注意，在上面所述的攻擊場景中，把hash存在cookie中時不行的。

檢測refer

後台在進行刪除操作之前先判斷refer，如果不是本域的請求，則直接拒絕，這種做法很有效。但是，想想這樣一個場景：如果博客允許評論裡面插圖，攻擊者完全可以將 img插入到原網站中，這樣refer還是在當下域名，博客依然會被刪除。所有可能引入鏈接的html標籤都是不可信的，如script、link，後台過濾策略一定要考慮到。

07-

總結

其實可以看到，上面的攻擊雖說現場是在前端，但是本質還是服務端驗證不足、過濾不全導致。對於前端來說，防禦所做的事有限，但是站在攻擊者角度來講，又必需精通前端。今天只是web滲透的皮毛，如果大家有興趣，可以在評論中留言，以後也可以多分享一些伺服器滲透、操作系統安全方面的，當然根據期待度以及我的時間而定。

本文編號2270，以後想閱讀這篇文章直接輸入2270即可。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！