WEB安全雜談

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] 純文本查看 複製代碼
?
1
2
3
if Retn!=True:
        print 'Attack!!!!!!'
SetName(1)

這就是造成這樣一個CSRF的原因,是的,這個解決方案確實是可行的,但是在實現的過程中卻出現了問題,例如,我們原本要求的Refer是http://www.baidu.com/set/nickname,但是實際上是如下情況:
 
我們可以看到,當我們的Refer爲I am P0werZh4i的時候,確實,程序返回了Attack!!!!!也就是說他確實判斷了這樣一次攻擊,但是我們可以看到此時VerficRefer函數返回了False,然後我們的if語句進行判斷,確實也發現這是不能操作的,但是問題就在這裏了:
[Python] 純文本查看 複製代碼
?
1
2
3
4
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] 純文本查看 複製代碼
?
1
2
3
4
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] 純文本查看 複製代碼
?
1
2
3
4
5
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的方式就是使用的這種原則。



相關鏈接 :http://bbs.ichunqiu.com/thread-8945-1-1.html?from=csdnJG

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章