Web安全基礎

《HTTP圖解》讀書筆記及總結

針對Web的攻擊技術

HTTP不具有必要的安全功能

從總體上看，HTTP就是一個通用的單純協議機制，具有較多優點，但在安全性方面則呈劣勢。好比如今Web網站都會使用的會話管理(session)，加密處理等安全性的功能，HTTP協議內並不具有，須要開發者自行設計並實現。

在客戶端便可篡改請求

經過URL查詢字段或表單，HTTP首部，Cookie等途徑把攻擊代碼傳入。

針對Web應用的攻擊模式

以服務器爲目標的主動攻擊

攻擊者經過直接訪問Web應用，把攻擊代碼傳入，主要來攻擊服務器上的資源。常見的攻擊是SQL注入和OS命令注入攻擊。

以服務器爲目標的被動攻擊

被動攻擊是利用圈套策略執行攻擊代碼的攻擊模式，攻擊者不直接對目標Web應用發起攻擊（借刀殺人），主要攻擊用戶的資源和權限。
一般的攻擊模式以下：

• 在Web頁面或郵件內設置陷阱

• 陷阱誘導

• 用戶的瀏覽器觸發事先已設好陷阱的HTTP請求

• 用戶的瀏覽器運行攻擊代碼

• 執行攻擊代碼的後果是用戶所持的Cookie等被竊取、用戶權限遭到惡意濫用

被動攻擊模式中具備表明性的攻擊是跨站腳本攻擊（XSS）和誇站點請求僞造（CSRF）

因輸出值轉義不徹底引起的安全漏洞

安全對策大體可分爲：

• 客戶端的驗證
  javascript驗證只是爲了儘早地識別輸入錯誤，起到提升UI體驗的做用。但請求仍然能夠篡改，不能徹底依賴客戶端的驗證。

• 服務器端的驗證：輸入值驗證、輸出值轉義
  從數據庫或文件系統、HTML、郵件等輸出Web應用處理的數據之際，針對輸出值作轉義是很重要的安全策略。轉義不徹底時，會因觸發攻擊者傳入的攻擊代碼，而帶來一些危害。

跨站腳本攻擊

跨站腳本攻擊（Cross-Site Scripting, XSS）是在瀏覽器內運行非法的HTML標籤或JS腳本進行的一種攻擊。動態建立的HTML部分有可能隱藏着安全漏洞。

攻擊案例：

• 動態生成HTML處發生，表單中填寫HTML甚至JS腳本

• 瀏覽器地址欄，Chrome和FireFox如今能夠對這種URL進行轉義，避免被攻擊

http://example.com/login?ID="><script>var ..</script>"

• 對用戶Cookie進行竊取
  惡意構造的腳本一樣能以跨站腳本攻擊的方式，竊取到用戶的Cookie信息。

若是響應信息中Cookie設置成HttpOnly，腳本就沒法取到

CSRF跨站點請求僞造

SQL注入

如今後端程序員不多用字符串拼接吧，作個瞭解

//SQL語句
SELECT * FROM party WHERE userName = 
//傳過來是這樣的字符串 'xx' OR 1 = 1
//拼接後，就能夠把全部的用戶查找出來
SELECT * FROM party WHERE userName = 'xx' OR 1 = 1

HTTP首部注入攻擊

有時服務端會把外部就收到的數據賦給首部字段Location和Set-Cookie或者其餘字段，攻擊者即可以在響應首部字段內插入換行，添加任意響應或主體的一種攻擊。

因設置或設計上的缺陷引起的安全漏洞

強制瀏覽
對那些不肯公開的文件，爲了保證安全會隱藏其URL，可一旦知道了URL，也就意味着能夠瀏覽URL對應的文件。直接顯示容易推測的文件名或文件目錄索引是，經過某些方法可能會使URL產生泄露。

不正確的錯誤消息處理
Web應用沒必要在用戶瀏覽畫面上展示詳細的錯誤消息，對攻擊者來講，詳細的錯誤消息有可能給他們下一次攻擊以提示。

開放重定向
開放重定向（Open Redirect）是一種對置頂的任意URL做重定向跳轉的功能。若是重定向的URL到某個具備惡意的Web網站，那麼用戶就回被誘導到那個Web網站。

因回話管理疏忽引起的安全漏洞

會話劫持

攻擊者經過某種手段拿到了用戶的會話ID，並不是法使用此會話ID假裝成用戶，達到攻擊的目的。

獲取會話ID的途徑：

• 經過非正規的生成方法推測會話ID

• 經過竊聽或XSS攻擊盜取會話ID

• 經過會話固定攻擊強行獲取會話ID

會話固定攻擊

• 訪問登陸頁面

• 服務器發佈一個會話ID，如http://example.com?SID=12k2snsjn

• 將第2步中的URL做爲陷阱，誘導用戶A前去認證

• 用戶A認證後，會話ID變味（用戶A已認證）狀態

• 以後攻擊者再用第2步中的URL訪問，假裝成功歡迎用戶A

跨站點請求僞造

攻擊者經過設置好的陷阱，強制對已完成認證的用戶進行非預期的我的信息或設定信息等某些狀態更新，屬於被動攻擊。

攻擊案例：

• 攻擊者在留言板上發表惡意代碼的評論<img src="http://example.com/msg?q=你好">

• 用戶A登陸，查看留言板

• 觸發陷阱，用戶A中瀏覽器的Cookie持有已認證的會話ID，利用用戶A的權限執行發表動做

HTTPS

HTTP在安全方面有如下缺點：

通訊使用明文(不加密)，內容可能會被竊聽
不驗證通訊方的身份，所以有可能遭遇假裝
沒法證實報文的完整性，有可能已遭篡改

HTTPS就是在HTTP上再加入加密處理和認證等機制。

爲何不一直使用HTTPS？

加密通訊會消耗更多的CPU及內存資源。若是每次通訊都加密，會消耗更多的資源，平攤到一臺計算機上，可以處理的請求數量也會隨之減小
節約購買證書的開銷

所以，若是是非敏感信息則使用HTTP通訊，只有在包含我的信息等敏感數據時才使用HTTPS加密通訊。