[深刻學習Web安全](2)安全雜談

時間 2019-11-26

標籤深刻學習 web 安全雜談欄目 HTML 简体版

原文原文鏈接

做者：萬年死宅
首發：i春秋社區
註明：轉載請務必註明i春秋社區（bbs.ichunqiu.com）

0x00 目錄

目錄
0x01 安全本質
0x02 信任域與信任邊界
0x03 如何判斷安全問題
0x04 道哥的白帽子兵法

0x01 安全本質
在真正進入Web安全的學習中以前，咱們最好來了解一些安全方面的知識。首先，咱們來看安全的本質。
根據道哥在《白帽子講Web安全》中所說：「安全問題的本質是信任的問題」，咱們舉個例子：
有一天，蛋總去上班，其餘人，好比「七百斤的猴子」，認識蛋總，因此，認爲蛋總不是ISIS的恐怖分子，不會炸掉i春秋的大樓，因此就容許蛋總進去了。（這就是「信任」，咱們試想，若是在「信任」的前提下，蛋總去炸i春秋的大樓，成功率有多高？這就是安全問題。。。）
上面的例子說的是現實生活的例子，可是在真正的「戰場」上也是如此，咱們只因此認爲一個東西、一個機制安全，僅僅是由於「信任」。也就是說，咱們創建的一切針對與安全問題的解決方案都是基於信任的。
就像咱們經過驗證Refer來防護CSRF，就是由於咱們相信JavaScript沒法控制Refer，可是僅僅由於JavaScript沒法控制Refer，咱們就能徹底放心了嗎？雖然「JavaScript沒法控制Refer」爲咱們的解決方案提供了「信任」這個解決方案的前提。
可是，咱們試想，雖然「JavaScript沒法控制Refer」，因此咱們獲得的Refer必定是正確的，可是在這個解決方案上出現問題呢？
我就來舉兩個我曾經遇到過的這種問題（雖然驗證了Refer，可是依然能夠CSRF）：
1.百度的一個CSRF：

這個CSRF就是這種問題，他的驗證機制存在問題，咱們若是正常操做他什麼也不返回，可是咱們若是修改了Refer他就會返回Error。可是，即便他返回Error咱們的操做也成功了，由於他的驗證機制以下（本身YY的，比必定說就必定是這樣）：

咱們能夠看到，在最後的這裏：

[Python] 純文本查看 複製代碼php

?linux

1程序員

2shell

3安全

if Retn!=True:服務器

print 'Attack!!!!!!'ide

SetName(1)函數

這就是形成這樣一個CSRF的緣由，是的，這個解決方案確實是可行的，可是在實現的過程當中卻出現了問題，例如，咱們本來要求的Refer是http://www.baidu.com/set/nickname，可是其實是以下狀況：

咱們能夠看到，當咱們的Refer爲I am P0werZh4i的時候，確實，程序返回了Attack!!!!!也就是說他確實判斷了這樣一次攻擊，可是咱們能夠看到此時VerficRefer函數返回了False，而後咱們的if語句進行判斷，確實也發現這是不能操做的，可是問題就在這裏了：

[Python] 純文本查看 複製代碼學習

?url

if Retn!=True:[/size][/font]

[font=微軟雅黑][size=4]print 'Attack!!!!!!'[/size][/font]

[font=微軟雅黑][size=4]SetName(1)[/size][/font]

[font=微軟雅黑][size=4]

咱們雖然if了，而且輸出了Attack!!!!,可是，咱們要知道，這個語句繼續執行下去仍是會修改咱們的數據，咱們也能夠看到最後，name的值已經被改成了0。
也就是說針對與這個解決方案，咱們就找到了一個bug。這樣一個bug，是邏輯上的問題，程序員覺得只要判斷了就不會操做數據了，可是事實上卻不是。
那麼咱們應該怎麼修復這個問題呢？，固然是這樣，只須要增長一行代碼：

在哪裏呢？嘿嘿，既然你沒看到我就在說一下吧：

[Python] 純文本查看 複製代碼

if Retn!=True:

print 'Attack!!!!!!'

exit()

SetName(1)

嘿嘿，其實就是判斷到攻擊以後，不止要返回數據，還要當即終止操做。不信咱們來看：

能夠看到，確實成功了，可是這個解覺方案都還能夠突破，以下：

能夠看到，咱們又攻擊成功了，只要將Refer改成「http://www.test.com/index?url=http://www.baidu.com/set/nickname」,就能成功的將name改成0,此次又是爲何呢？
這是由於咱們判斷Refer的方式有錯，咱們來看VerficRefer函數的定義：

[Python] 純文本查看 複製代碼

def VerficRefer(Refer):

CorrectURL='http://www.baidu.com/set/nickname'

if Refer.find(CorrectURL)!=-1:

return True

return False

能夠看到，它是這樣判斷的：
if Refer.find(CorrectURL)!=-1
這樣的話，咱們只須要知足在咱們的Refer中含有http://www.baidu.com/set/nickname就能成功操做數據。。。
好了，不能再扯下去了，咱們進入第二個主題「信任域與信任邊界」。

0x02 信任域與信任邊界
關於信任域與信任邊界，其實就是兩個概念，可以讓你更好的思考安全問題。
咱們仍是經過舉例子來解決問題，此次咱們來講霸總吧，話說啊，有一天啊，這個霸總來到洗手間啊，忽然發現了傳說中的母廁所（你懂得23333333），因而霸總堅決果斷的回家換了套女裝，準備混進去看看，嘿嘿。
可是，根據安全原則，被分紅了以下這樣的區域：
_________________________________
|                                                          |
|                   非信任域                   |
|             （霸總所在區域）             |
|                ___________                   |
|                |                   |                  |
|                |    信任域 |                  |
|                |  (mu廁所) |                   |
|                |___________|                   |
|                                                          |
|                                                          |
|_________________________________|

linux畫圖軟件很差用，因此就畫字符畫了，233333333333333333
咱們看到，mu廁所屬於信任域是高級區域，霸總所在的非信任域屬於低級區域。
根據安全原則來講，低級區域流向高級區域的流量應該通過過濾，去掉惡意的流量。
因此，咱們可憐的霸總，就被「過濾了」
（你TM裝也裝好點嘛，MD帶個把還想進去，哼～～哈哈哈哈哈哈哈）
而信任與與非信任域之間的界線就是信任邊界，嘿嘿。

0x03 如何判斷安全問題
咱們怎麼知道一個問題到底算不算漏洞呢？也就是說咱們怎麼知道一個問題是安全問題呢？
其實很簡單，道哥曾提到過的「安全三要素」就能解決這種問題，嘿嘿，辣麼，所謂的「安全三要素」是哪三要素呢？

機密性（Confidentiality)
完整性（Integrity）
可用性（Availability）

就是這三「賤」客。。。。

只要一個問題威脅到這三要素，則算是一個漏洞，即安全問題。
例如：

SQL注射，能夠提取用戶數據，即破壞了機密性（Confidentiality）
在例如DDOS，可使目標服務器拒絕服務，即破壞了可用性（Availability）
例如越權刪除漏洞，能夠隨意刪除其餘用戶信息，級破壞了用戶數據的完整性（Integrity）

0x04 道哥的白帽子兵法
_>Secure By Default原則
1.白名單與黑名單
   這個我就舉個很常見的例子，好比文件上傳時，使用黑名單策略，不容許上傳php的文件，則咱們可使用php4來繞過。

   而若是使用白名單，則只容許jpg,png等文件上傳則不會出現此類問題。
2.最小權限原則
   意思是給予管理員和全部用戶更少的權限，這樣的話即便咱們拿到shell，危害也不大。
_>Defense in Depth原則
   這個咱們就簡單說下吧，由於這個要理解會設計比較多的問題，咱們就以「木桶原理」來舉例，一個木桶能裝多少水是取決與他最短的木板有多長而不是最長的木板有多長。這也就是說安全是一個總體。。。
_>數據與代碼分離原則
   這個其實很清晰吧，例如防護SQL注射，防護XSS，就是利用這種原則，幾乎全部的代碼注入問題，都是這樣防護。也就是說因爲程序把數據看成代碼執行而形成的問題，都該使用這個方案。
_>不可預測性原則
   防護CSRF就是利用的這個原則，防護CSRF的一種叫驗證Token的方式就是使用的這種原則。

做者：萬年死宅
首發：i春秋社區
註明：轉載請務必註明i春秋社區（bbs.ichunqiu.com）