Web安全學習系列（3）

《白帽子講Web安全》筆記11-17章

從頭學起=》Web安全學習系列（1）

一步一步=》Web安全學習系列（2）

轉載請注明出處：http://blog.csdn.net/cym492224103

• • 第11章 加密算法與随機數
    • 針對加密攻擊
    • Stream Cipher Attack
    • ECB模式的缺陷
    • 密鑰管理
    • 建議
  • 第12章 Web架構安全
  • 第13章 應用層拒絕服務攻擊
    • 本質
    • 防禦措施
    • Slowloris攻擊
  • 第14章 PHP安全
    • 檔案包含漏洞
    • 變量覆寫漏洞
    • 代碼執行漏洞
    • 定制安全的PHP環境
  • 第15章 WebServer配置安全
    • WebServer的安全
    • Apache安全
    • Nginx安全
    • JBoss遠端指令執行
    • Tomcat遠端指令執行
  • 第16章 網際網路業務安全
    • 安全是一個産品的特性
    • 賬号被盜途徑
  • 第17章 安全開發流程SDL
    • 微軟的安全開發流程
    • SDL實戰經驗

第11章 加密算法與随機數

針對加密攻擊

唯密文攻擊

攻擊者有一些密文，他們是使用同一加密算法和同一密鑰加密的。這種攻擊是最難的。

已知明文攻擊

知道對應密文的明文。

選擇明文攻擊

不僅知道一些密文和明文，還能選擇用于加密的明文。

選擇密文攻擊

攻擊者選擇不同的密文來解密。

Stream Cipher Attack

流密碼的加密基于異或（XOR）操作進行的，每次都隻操作一個位元組。性能非常好。

常見的流加密算法：RC4\ORYX\SEAL等。

破解攻擊：Reused Key Attack

假設密鑰C，明文A，明文B，那麼XOR加密可表示

E（A）= A xor C

E（B）= B xor C

密文是公之于衆，是以很容易可計算：

E（A）xor E（B）

是以兩個相同的數進行XOR運算結果為0，有此可得：

E（A）xor E（B）=（A xor C）xor（B xor C）=A xor B xor C xor C = A xor B

進而得到

E（A）xor E（B） = A xor B

通過規則破解加密

ECB模式的缺陷

對于ECB模式來說，改變分組密文的順序，将改變解密後的明文順序，替換某個分組密文，解密後該對應分組的明文也會被替換，而其他分組不收影響。

當需要加密的明文多于一個分組長度時，應該避免使用ECB模式。

密鑰管理

在密碼學裡有個基本的原則：密碼系統的安全性應該依賴于秘鑰的複雜性，而不應該依賴于算法保密性。

密鑰管理中最常見的錯誤，就是将密鑰碼在代碼裡。

寫死的密鑰存在的問題

1.代碼被傳播，可能被逆向。

2.軟體開發人員都能檢視代碼，可能會由人員洩露代碼。

常見做法将密鑰儲存在配置檔案或者資料庫。（定時更換密鑰）

順序增長有可能被預測，可以使用随機數。

在重要和敏感的系統中我們要使用安全的随機數生成算法。在java中，我們可以使用

java.security.SecureRandom

建議

在加密算法的選擇和使用上：

1.不要使用ECB模式

2.不要使用流密碼（比如：RC4）

3.使用HMAC-SHA1代替MD5（甚至代替SHA1）

4.不要使用相同的key做不同的事情

5.salts與IV需要随機生成

6.不要自己實作加密算法，盡量使用安全專家已經實作好的庫

7.不要依賴系統的保密性

當你不知道如何選擇時有一下建議：

1.使用CBC模式的AES256用于加密

2.使用HMAC-SHA512用于完整性檢查

3.使用帶salt的SHA-256或SHA-512用于Hashing

第12章 Web架構安全

優秀的安全方案：在正确的地方，做正常的事。

XSS：過濾文本。

CSRF：所有寫操作所要使用POST，每次操作請求都需要插入token的HTTP頭。

HTTP Response：web架構設定跳轉函數的白名單。

Cookie劫持：添加HttpOnly

SQL注入：預編譯函數。

第13章 應用層拒絕服務攻擊

DDOS又稱分布式拒絕服務，全稱Distributed Denial of Service.

DDOS本是利用合理的請求造成資源過載，導緻服務不可用。

本質

分布式拒絕服務攻擊，将正常請求放大若幹倍，通過若過個網絡節點同時發起攻擊，以達成規模效應。這些網絡節點往往是黑客們所控制的“殭屍電腦”，數量達到一定規模後，就形成了一個“僵屍網絡”。大型的僵屍網絡，甚至達到了數萬、數十萬台的規模。如此規模的僵屍網絡發起的DDOS攻擊，幾乎是不可阻擋的。

防禦措施

1.限制請求頻率

在應用中針對每個“用戶端”做一個請求頻率的限制。

2.驗證碼

阻止自動化重放行為

3.伺服器配置

Apache配置：調小Timeout、KeepAliveTimeout值、增加MaxClients值。

Apache提供的子產品接口為我們擴充Apache、設計防禦措施提供了可能。目前已經有一些開源的Module實作了針對應用層DDOS保護攻擊。

mod_qos是Apache的一個Module，它開源幫助緩解應用層的DDOS攻擊。

思路：限制IP通路頻率。

如果攻擊者使用代理伺服器，傀儡機進行攻擊，該如何有效的保護網站呢？

Yahoo提供解決思路：跟進IP位址和Cookie等資訊，可以計算客服端的請求頻率并進行攔截。

Slowloris攻擊

原理：極低的速度往伺服器發送HTTP請求，占用請求連接配接數不釋放，無法接受新的請求，導緻拒絕服務。

要保持住這個連接配接，RSnake構造了一個畸形的HTTP請求，準确地說，是一個不完整的HTTP請求。

在正常的HTTP標頭中，以兩個CLRF表示HTTP Headers部分結束。

正常的 Content-Length：42\r\n\r\n 處理後的 42\r\n

由于web service隻收到一個\r\n，是以認為還沒結束，并保持此連接配接。

此類拒絕服務攻擊本質，實際上是對有限的資源的無限制濫用。

HTTP Request Header長度最大8192位元組。

HTTP Request Body預設限制大小2GB。

正則寫不好可能被惡意輸入利用，消耗大量資源，進而導緻DOS。這種攻擊叫做ReDos。

第14章 PHP安全

檔案包含漏洞

include()

require()

include_once()

require_once()

當使用這四個函數包含一個新的檔案時，該檔案将作為PHP代碼執行，PHP核心并不會在意該被包含檔案是什麼類型。

利用漏洞需要兩個條件：

1.包含檔案為動态變量

2.使用者能夠控制該變量

要解決檔案包含漏洞，避免包含動态的變量，尤其是使用者可以控制的變量。

一種變通方式，使用枚舉：

<?php
switch($file)
    case ‘main’:
        include ‘xxxxxx’;
    break;
    case ‘xxx’:
        include ‘xxxxxx’;
    break;
    default:
        include ‘xxxxxx’;
?>
           

遠端檔案包含漏洞（ RFI：Remote File Inclusion）

PHP配置allow_url_include為ON的話，則include/require函數可以加載遠端檔案。

變量覆寫漏洞

當register_globals為ON時，送出請求URL：hit://www.a.com/test.php？auth=1變量$auth将自動得到指派。

安全建議：

首先，確定register_globals=OFF.若不能自定義php.ini，則應該在代碼中控制。

其次，熟悉可能造成變量覆寫的函數和方法，檢查使用者是否能夠控制變量的來源。

最後，養成初始化變量的好習慣。

代碼執行漏洞

挖掘漏洞的過程，通常需要先找到危險函數，然後回溯函數的調用過程，最終看在整個調動過程中使用者是否有可能控制輸入。

PHP有很多函數可以直接執行代碼的函數：比如：eval()、assert()、system()、exec()、shell_exec()、passthru()、escapeshellcmd()、pcntl_exec()等。

一般來說最好禁用這些函數。

定制安全的PHP環境

register_globals = OFF（防止變量覆寫）

allow_url_include = OFF（加載遠端檔案）

allow_url_open = OFF（打開遠端檔案）

display_errors = OFF（錯誤回顯）

log_errors= OFF（錯誤日志）

cgi.fix_pathinfo = 0（避免檔案解析問題）

session.cookie_httponly = 1（開啟HttpOnly，包含cookie）

session.cookie_secure = 1（若是全站HTTPS則請開啟）

第15章 WebServer配置安全

WebServer的安全：

1.本身是否安全。

2.是否提供安全功能。

Apache安全：

1.檢查Module的安裝情況，根據最小權限原則，應該盡可能的減少不必要的Module，對于要使用的Module，則檢查其對應的版本是否存在已知的安全漏洞。

2.Apache以root身份或者admin身份運作是一個非常糟糕的決定，最好使用隻有運作web應用的權限使用者身份運作。

3.Apache還提供了一些配置參數優化伺服器的性能，提高對抗DDOS攻擊能力。詳細請看“《web安全》第13章 應用層拒絕服務攻擊”

Nginx安全：

1.Nginx與Apache最大的差別在于，檢查Apache安全時需要更多的要關注Module的安全，而Nginx則需要關注軟體本身，及時更新軟體版本。

2.Nginx的配置非常靈活，可以做一些簡單的條件判斷，比如客服端的User-Agent具有什麼特征。

JBoss遠端指令執行

1.預設安裝時通路JMX-Console是沒有任何認證的。

2.通過DeploymentScanner遠端加載一個war包。

Tomcat遠端指令執行

和Boss一樣，可以直接通路控制頁面，管理者可以通過控制頁面部署war包。

第16章 網際網路業務安全

安全是一個産品的特性

如果我們的産品能夠潛移默化的培養使用者的安全習慣，将使用者往更安全的行為上引導，那麼這樣的安全就是最理想的産品安全。

提高注冊門檻，防止垃圾注冊。

賬号被盜途徑：

1、網站登入過程中無HTTPS，密碼在網絡中嗅探。

2、使用者電腦中了木馬，密碼被鍵盤記錄軟體所擷取。

3、使用者被釣魚網站所迷惑，密碼被釣魚網站所騙取。

4、網站某登入入口可以被暴力破解。

5、網站密碼取回流程存在邏輯漏洞。

6、網站存在XSS等客服端腳本漏洞，使用者賬戶被間接竊取。

7、網站存在SQL注入等伺服器漏洞，網站被黑客入侵導緻使用者賬戶資訊洩露。

第17章 安全開發流程（SDL）

微軟的安全開發流程：

1.教育訓練

2.安全要求

3.bug欄

4.安全和隐私風險評估

5.設計要求

6.減小攻擊面

7.威脅模組化

8.使用指定的工具

9.棄用不安全函數

10.靜态分析

11.動态程式分析

12.模糊測試

13.威脅模型和攻擊面評價

14.事件響應計劃

15.最終安全評析

16.釋出/存檔

SDL實戰經驗

1、與項目經理進行充分溝通，排出足夠事件。

2、規範公司的立項流程，確定所有項目都能通知到安全團隊，避免遺漏。

3、梳理安全的部門的權威，項目必須由安全部門稽核完成後才能釋出。

4、将技術方案寫入開發、測試工作手冊中。

5、給工程師教育訓練安全方案。

6、記錄所有安全BUG，激勵程式員編寫安全的代碼。