[深入學習Web安全](3)Web層面的安全威脅

01-25

本文原創作者：萬年死宅
內容來源：i春秋社區
未經許可禁止轉載

0x01 攻擊對象

我們的Web程序是屬於B/S架構的程序。所以，針對與Web的攻擊，只會有兩個對象。一是B，也就是瀏覽器（Browser），二是S，也就是伺服器（Server）。

例如我們很常見的XSS，CSRF這樣一些安全威脅就是針對Brower的攻擊。而想SQL注射，任意文件上傳，解析漏洞這一類的安全威脅則是針對Server的攻擊。

我們可以知道，針對一個互聯網企業來說，S就是企業，B就是用戶。所以針對Server的攻擊更被企業所重視。雖然說有句話說得好「以人為本」，也就是說對於一個企業來說，用戶很重要，是它發展的根本。

但是，對於現在的很多企業來說，只要用戶不知道不就好了嗎？所以，我們也可以看到，很多的互聯網企業不重視針對與Browser 的安全威脅。

但是，牛逼的跨站師們，一次又一次的詮釋了如何把不可能變成可能。曾經，XSS只是能夠盜個Cookie，能夠釣個魚什麼的。但是，如今，XSS Worm、CSRF Worm、XSS內網滲透、瀏覽器跨域……

一個又一個的血案，讓我們看到針對於Browser的Web前端攻擊，並不比SQL Injection的危害小。

好了，我們不繼續扯了，我們來繼續正題。我們現在可以大致把Web層面的安全威脅大致分為兩類：

Web前端安全威脅
Web後端安全威脅

針對於這樣兩個不同的攻擊向量，我們來一一學習。

0x02 Web前端安全威脅

我們接下來，來專門的把前端的安全威脅拿來說一下。這類的安全威脅，是利用Web站點或者瀏覽器本身的缺陷來攻擊瀏覽器。

這類攻擊很神奇，因為這類攻擊的受害者是不確定的，針對於不同的受害者，這類攻擊的為威力就會呈幾何級數的增長。

我們來舉一個簡單的例子，例如某個網站存在XSS。例如，這個XSS是在發表評論處的，那麼，受害者就是這個網站的用戶，那麼，我們能幹什麼呢？

我們可以盜取用戶的Cookie，獲取用戶的UserAgent信息，還可以用來釣魚，還有一些很神奇的利用（當然，這些神奇的利用必須在環境剛好合適的情況下）。

我們獲取到用戶的Cookie的話就相當於控制了用戶的在線賬戶許可權，而UA則可以用於進一步的滲透，例如針對老版瀏覽器的已知的RCE來Hack用戶的機器。

好的，我們就來舉幾個例子，首先，我們來看這樣一個頁面：

這個頁面的功能很簡單，我們在輸入框中輸入點東西，例如：「Hades」，然後點擊OK按鈕，如下：

我們可以看到，頁面輸出了「Hello ,Hades」。So，我們找到了一個輸入點和一個輸出點，於是，我們就可以測試是否存在XSS了：

可以看到，的確存在XSS，接下來就需要驗證是什麼類型的XSS。

首先，驗證是不是Reflected XSS：

1.打開「開發者選項」-到達「Network」選項卡-再次插入XSS語句，觀察HTTP請求：

2.我們看到了一個GET請求，點進去，查看請求參數，如下：

3.然後觀察請求參數中並沒有我們插入的XSS語句，所以我們可以直接判斷出，這是一個不依靠網路請求的DOM-XSS。

接著，我們來看成因：

1.查看網頁源代碼：

2.這個例子十分好理解，我們一點一點來看，首先，我們輸入了XSS語句之後，點擊了OK按鈕，所以，語句可能是從點擊這個按鈕開始被X進DOM的，我們可以看到：

<button>OK</button>

3.額，可能一會發布的時候會被這個代碼高亮的插件搞亂。。我們可以看到，當我們點擊這個button的時候，就觸發了這個button的onclick時間，調用了上下文的一個JS函數，叫test()。

4.然後，我們跟進test函數，如下：

function test(){ var code = document.getElementById("code").value; var box = document.getElementById("box"); box.innerHTML="Hello ,"+code; }

我們來看這個函數幹了什麼，首先是第一行：

var code = document.getElementById("code").value;

我們可以看到，這一行從document中通過id得到了一個id為code的元素，然後取得了這個元素的value並把value賦值給code變數。

我們到document中去找找一個id為code的元素，如下圖：

我們可以看到我們頁面上的那個輸入框，就是這個id為code的元素，所以這個value其實就是我們輸入的值。

接著，我們來看第二行：

var box = document.getElementById("box");

這裡獲取了一個id為box的元素，我們來找找看：

可以看到，在OK按鈕的下面就是一個h3元素，它的id就是box，接著，我們看第三行：

box.innerHTML="Hello ,"+code;

我們可以看到我們修改了box對象的innerHTML屬性，將其改成了"Hello,"+code。也就是我們剛才第一次測試時的Hello,Hades。

然而在修改innerHTML屬性之前，並未對用戶輸入的內容進行過濾。

按我們上篇paper的話說，就是DOM是信任域，而一切外來數據都是處在非信任域的，根據這個安全原則來說，當非信任域的數據流向信任域的時候，我們應當進行過濾。

正如道哥所說「安全的本質是信任問題」，所以，對於非信任域的數據，無論如何，我們都應該在檢測之前對其抱著懷疑的態度。

0x03 Web後端安全威脅

接著，我們就來說下Web後端的一些問題。我們要說的是大家都很熟悉的SQL注射了，由於在kali上不好打馬，所以就不用實際例子了，於是本地搭建一下,OK，我們來訪問下http://localhost/test.php?id=1,這就是一個注射點，我們可以測試看看：

http://127.0.0.1/test.php?id=1%20and%20sleep(5)

我們可以看到響應時間確實超過了5秒,為了證明確實存在SQL注射，我們通過order by來獲得了查詢語句所查詢的欄位數為1,於是如下構造：

http://127.0.0.1/test.php?id=-1%20union%20select%20%27www.ichunqiu.com%27

成功的通過union改變了查詢結果：

OK，接著，我們就將注入點交給自動化工具sqlmap來檢測：

證明注射點，接著，我們來見證Web後端安全威脅的危害：

如上圖，我們通過--dbs指令獲取了該Web服務的mysql資料庫的資料庫，我們看到除了sqliDemo資料庫以為，全是默認的mysql資料庫，所以，我們獲取sqliDemo庫里的表：

OK，我們看到了一個含有關鍵字的表「user」，我們看看其中的列：

OK，兩個敏感的columns出現了，我們dump其中的數據來看：

我們看到，通過一個SQL注射漏洞，直接獲取了數據。其實，無論是前端的安全問題還是後端的，他們都有著共同的目的，那就是數據，前端的漏洞只能間接的獲取到數據，而後端的漏洞大多數都能直接獲取數據，就是因為這個導致了一些企業對於前端安全威脅的不重視。

0x04 總結

我們通過前面的學習，可以得知，無論是那一種類型的安全威脅，都是有目的性的，而且他們的目的就是各種各樣的對於攻擊者有利的數據。

所以，我們建立安全模型，也需要從根源上考慮，這個根源也就是數據。對於數據，我們知道存在增刪查改這樣一些基本操作.

所以，從根源考慮就是說對於有對數據操作的地方進行著重防禦。

例如一旦「刪」的操作沒有保護好，則會嚴重影響網站的數據安全，例如一個刪操作的平行越權漏洞，就可以直接遍歷id號，直接清掉整個資料庫，其實，這也算是一種SQL注射，因為最後，我們的數據也注入到了SQL語句中，但是他卻不能控制SQL操作。

OK，具體的各種防禦策略，我們下節課來繼續學習！

最後送大家一個表情包套圖！

[深入學習Web安全](3)Web層面的安全威脅

目錄

0x01 攻擊對象

0x02 Web前端安全威脅

0x03 Web後端安全威脅

0x04 總結