安全測試：xss，cookie，xst注入攻防

時間 2019-11-10

原文原文鏈接

查找並利用保存型XSS漏洞

肯定保存型XSS漏洞的過程與前面描述的肯定反射型XSS漏洞的過程有不少類似之處，都包括提交一個特殊的字符竄做爲每一個頁面的第一個參數。可是，這兩個過程之間也存在着一些重要的區別。必須記住這些區別，以肯定更多的漏洞。php

滲透測試步驟：html

（1）嚮應用程序的每個可能的位置提交一個特殊的字符串後，必須反覆檢查應用程序的整個內容與功能，肯定這個字符串在瀏覽器中顯示的任何狀況。在一個位置（例如，我的信息頁面的姓名字段）輸入用戶控制的數據，這個數據可能會在應用程序的許多不一樣位置顯示（例如，用戶主頁上，註冊用戶列表中、任務等工做流程項目中、其餘用戶的聯繫列表中、用戶提交的消息或問題中、應用程序日誌等）。應用程序可能對每一個出現的字符串實施了不一樣的保護性過濾，所以須要對他們進行單獨分析。java

（2）若是有可能，應檢查管理員可以訪問的全部應用程序區域，肯定其中是否存在任何可被非管理用戶控制的數據。例如，應用程序通常容許管理員在瀏覽器中檢查日誌文件。瀏覽器

這種類型的功能極有可能包含XSS漏洞，攻擊者經過生成含有惡意HTML的日誌記錄便可對其加以利用。安全

（3）再向應用程序中的每一個位置提交一個測試字符串時，並不老是把它做爲每一個頁面的每個參數這樣簡單。在保存被提交的數據以前，許多應用程序功能須要經歷幾個階段的操做。例如，註冊新用戶、處理購物訂單、轉帳等操做每每須要按預約的順序提交幾個不一樣的請求。爲避免遺漏任何漏洞，必須確保每次測試完全完成。服務器

（4）當探查反射型XSS漏洞時，應該注意可以控制的受害者的請求的每個方面。包括請求的全部參數和每個HTTP消息頭，由於可使用一個專門設計的Flash對象控制他們。當探查保存型XSS漏洞時，還應該分析應用程序接受並處理可以控制的輸入的任何帶外通道。任何這類通道都是引入保存型XSS攻擊的適當攻擊向量。同時，審查在應用程序解析過程當中獲得的結果，肯定每個可能的受攻擊面。cookie

（5）若是應用程序容許文件上傳和下載，應始終探查這種功能是否易於受到保存型XSS攻擊。若是應用程序容許HTML或文本文件，且並不確認或淨化他們的內容，那麼幾乎能夠確定他們易於受到攻擊。若是它容許JPEG文件且並不確認其中是否包含有效的圖像，那麼可能易於受到針對Internet Explorer用戶的攻擊。測試應用程序如何處理它支持的每種文件類型，並弄清瀏覽器如何處理包含HTML而非正常內容的響應。app

（6）充分發揮想象，肯定控制的數據是否可經過任何其餘方法保存在應用程序中並顯示給其餘用戶。例如，若是應用程序的搜索功能顯示經常使用的搜索項列表，就能夠經過屢次搜索這個列表，引入一個保存型XSS有效載荷，即便主搜索功能安全處理輸入。框架

肯定用戶控制的數據被應用程序保存並隨後在瀏覽器中顯示的每一種狀況後，應當遵循與前面描述的探查潛在的反射型XSS漏洞時相同的過程。也就是說，決定須要提交哪些輸入，以在周圍的HTML中嵌入有效的JavaScript，而後嘗試避開干擾攻擊有效載荷執行的過濾dom

當探查反射型XSS漏洞時，經過每次測試一個參數，並檢查每一個響應中是否出現輸入，就能夠輕易肯定哪些請求參數易於受到攻擊，可是，當探查保存型XSS漏洞時，要肯定這一點並不容易。若是在每一個頁面的每個參數提交相同的測試字符串。那麼可能會發現，這個字符串在應用程序的許多位置重複出現，於是沒法準確肯定每一個出現的字符串由哪一個參數負責。爲避免出現這個問題，當探查保存型XSS時，能夠爲每一個參數提交一個不一樣的測試字符竄，例如，把測試字符串與它提交到其中的字段名稱鏈接起來。

查找並利用基於DOM的XSS漏洞

使用如下方法沒法肯定基於DOM的XSS漏洞：提交一個特殊的字符串做爲參數，而後監控響應中是否出現該字符串。

肯定基於DOM的XSS漏洞的基本方法是，用瀏覽器手動瀏覽應用程序，並修改每個URL參數，在其中插入一個標準測試字符串，例如：

"<script>alert(document.cookie)</script>

經過在瀏覽器中顯示每個返回的頁面，能夠執行全部客戶端腳本，必要時引用修改的URL參數。只要包含cookie的對話框出現，就表示發現了一個漏洞（可能基於DOM的或標準的反射型XSS漏洞）。使用一個執行自身JavaSript註釋器的工具甚至能夠自動完成這個過程。

然而，這種基本的方法並不能肯定全部基於DOM的XSS漏洞，如上所述，在一個HTML文檔中注入有效JavaScript所需的準確語法，取決於用戶可控制的字符串插入點先後已經存在的語法。可能須要終止一個被單引號或雙引號引用的字符串，或者結束特殊的標籤。有時可能須要插入新標籤，但有時並不須要。應用程序可能會以各類方式修改輸入，但它仍然易於受到攻擊。即便應用程序可能易於受到精心設計的攻擊，但若是插入標準測試字符串仍不能獲得有效的語法，那麼嵌入式JavaScript將不會執行，所以也不會有對話框出現。因爲沒法在每一個參數中提交每一種可能的XSS攻擊字符串，這種基本的探查方法必然會遺漏大量的漏洞。

肯定基於DOM的XSS漏洞的一種更加有效的方法是檢查全部客戶端JavaScript，看其中是否使用了任何可能會致使漏洞的DOM屬性。

滲透測試步驟：

使用在應用程序解析過程當中獲得的結果，檢查每一段客戶端JavaScript，看其中是否出現如下API，他們可用於訪問經過一個專門設計的URL控制的數據：

document.location

document.URL

document.URLUnencoded

document.referrer

window.location

確保檢查出現的靜態HTML頁面及動態生成的頁面中的腳本，不管頁面爲什麼種類型，或者是否看到被提交給頁面的參數，任何使用腳本的位置均可能存在基於DOM的XSS漏洞。

在每個使用上述API的位置，仔細檢查那裏的代碼，肯定應用程序如何處理用戶可控制的數據，以及是否可使用專門設計的輸入促使任意JavaScript得以執行。尤爲注意檢查並測試控制的數據被傳送至如下任何一個API的狀況：

document.write()

document.writeln()

document.body.innerHtml

eval()

window.execScript()

window.setInterval()

window.setTimeout()

和查找反射與保存型XSS漏洞時同樣，咱們可能會發現應用程序執行了一些過濾，阻止包含某些惡意字符串的請求。即便客戶端出現易受攻擊的操做，服務器並不在響應中返回用戶提交的數據，可是URL仍然被提交給了服務器；所以，當應用程序檢測到有效載荷時，他會對數據進行確認，且不會返回易受攻擊的客戶端腳本。

若是遇到這種防護，滲透測試員應該嘗試使用前面在查找反射型XSS漏洞時描述的每一種可能避開過濾的攻擊方法，測試服務器數據確認機制的可靠性。除這些攻擊外，還有幾種專門針對基於DOM的XSS漏洞的技巧可幫助攻擊有效載荷避開服務器端確認。

當客戶端腳本從URL中提取一個參數時，他們不多將查詢字符串正確解析成名稱/值對。相反，他們一般會在URL中搜索後面緊跟着等號的參數名稱，而後提取出等號後直到URL結束位置的內容。這種行爲可以以兩種方式加以利用。

（1）若是服務器根據每一個參數而不是整個URL應用確認機制，那麼能夠將有效載荷插入到附加在易受攻擊的參數後面的一個虛構參數中。例如：

https://wahh-app.com/error.php?message=Sorry%2c+an+error+occurred&

foo=<script>alert(document.cookie)</script>

這時，虛構的參數被服務器忽略，所以不會受到任何過濾。可是，由於客戶端腳本在查詢字符串中搜索message=，並提取其後的所有內容，因此它處理的字符串中正好包含該有效載荷。

（2）若是服務器對整個URL而不只僅是消息參數應用確認機制，仍然能夠將有效載荷插入到HTML片斷字符#的右邊，從而避開過濾。例如：

https://wahh-app.com/error.php?message=Sorry%2c+an+error+occurred#<script>alert(document.cookie)</script>

這時，片斷字符串仍然屬於URL的一部分，所以被保存在DOM中，並由易受攻擊的客戶端腳本處理。可是，因爲瀏覽器並不將URL中的片斷部分提交給服務器，所以攻擊字符串不會傳送到服務器中，於是不會被任何服務器端過濾所阻止。由於客戶端腳本提取message=後面的所有內容，因此有效載荷仍然被複制到HTML頁面源代碼中。

一些應用程序使用更加複雜的客戶端腳本，對查詢字符竄進行更加嚴格的解析。例如，他在URL中搜索後面緊跟着等號的參數名稱，而後提取等號後面的內容，直到遇到一個分隔符，如&或#，在這種狀況下，能夠對前面的兩個攻擊進行以下修改：

https://wahh-app.com/error.php?foo message=<script>alert(document.cookie)</script>&message=Sorry%2c+an+error+occurred

https://wahh-app.com/error.php#message=<script>alert(document.cookie)</scirpt>

這這兩個示例中，第一個message=後面緊跟着攻擊字符串，其中沒有任何干擾腳本執行的分隔符，所以攻擊有效載荷被處理，且被複制到HTML頁面源代碼中。

有時候，基於DOM的數據通過很是複雜的處理，僅經過靜態審查JavaScript源代碼可能很難追蹤用戶控制的數據採用的不一樣路徑以及對它進行的各類操做。在這種狀況下，使用一個JavaScript調試器監控腳本的執行狀況可能會有很大幫助。Firefox瀏覽器的FireBug擴展是一款用於監控客戶端代碼與內容的優秀調試器，可幫助設置斷點（breakpoint）、監視感興趣的代碼或數據，爲咱們瞭解複雜腳本的執行過程提供極大的便利

12.1.9 HttpOnly cookie與跨站點追蹤

攻擊XSS漏洞的一種有效載荷，就是使用嵌入式JavaScript訪問document.cookie屬性，截獲受害者的會話令牌。HttpOnly cookie是某些瀏覽器所支持的一種防護機制，許多應用程序使用它防止這種攻擊有效載荷執行。

當應用程序設定一個cookie時，它可能在Set-Cookie消息頭標記爲HttpOnly：

Set-Cookie:SessID=12kj234kj2343k5j34lj53l4k5j3;HttpOnly;

當一個cookie以這種方式標記時，支持它的瀏覽器將阻止客戶端JavaScript直接訪問該cookie。雖然瀏覽器仍然會在請求的HTTP消息頭中提交這個Cookie，但它不會出如今document.cookie返回的字符串中。所以，使用HttpOnly cookie有助於阻止攻擊者使用XSS漏洞實施會話劫持攻擊。

HttpOnly cookie不會影響其餘可以使用XSS漏洞傳送的攻擊有效載荷。例如，他不會影響前面在MySpace蠕蟲中使用的誘使用戶執行任意操做的攻擊。並非全部瀏覽器都支持HttpOnly cookie，這表示不能老是依賴他們阻止攻擊。並且，稍後咱們會講到，即便使用HttpOnly cookie，攻擊者有時仍然能實施會話劫持攻擊。

跨站點追蹤（XST）是一種攻擊技巧，有時能夠利用它避開HttpOnly cookie提供的保護，容許客戶端JavaScript訪問標記爲HttpOnly的cookie值。

這種技巧使用許多Web服務器默認激活的HTTP TRACE方法，它主要用於診斷目的。當服務器收到一個使用TRACE方法的請求時，它經過一條消息做出響應，消息主體中包含服務器收到的Trace請求的原始文本。TRACE方法之因此可用於診斷目的，其緣由在於，服務器收到的請求可能不一樣於客戶送出的請求。TRACE方法之因此可用於診斷目的，其緣由在於，服務器收到的請求可能不一樣於客戶傳送的請求，由於請求會被攔截代理服務器修改。這個方法可用於肯定請求在客戶與服務器之間傳送時發生了哪些變化。

瀏覽器在HTTP請求中提交全部cookie，包括使用TRACE方法的請求以及標記爲HttpOnly的cookie。

12.1.10 防止XSS攻擊

儘管XSS的表現形式各異，利用方法各不相同，但從概念上講，防止這種漏洞實際上至關簡單。預防他們之因此存在困難，主要在於咱們沒法肯定用戶可控制的數據以潛在危險的方式被處理的每一種狀況。任何應用程序頁面都會處理並顯示一些用戶數據。除核心功能外，錯誤消息與其餘位置也可能產生漏洞。所以，XSS漏洞廣泛存在也就不足爲奇了，即便在最爲注重安全的應用程序中也是如此。

因爲形成漏洞的緣由各不相同，一部分防護方法適用於反射型與保存型XSS漏洞，而另外一些則適用於基於DOM的XSS漏洞。

1.防止反射型與保存型XSS漏洞

用戶可控制的數據未經適當確認與淨化就被複制到應用程序響應中，這時形成反射型與保存型XSS漏洞的根本緣由。因爲數據被插入到一個HTML頁面的源代碼中，惡意數據就會干擾這個頁面，不只修改它的內容，還會破壞它的結構（影響引用字符串、起始與結束標籤、輸入腳本等）。

爲消除反射型與保存型XSS漏洞，首先必須肯定應用程序中用戶可控制的數據被複制到響應中的每一種情形。這包括從當前請求中複製的數據以及用戶以前輸入的保存在應用程序中的數據，還有經過帶外通道輸入的數據。爲確保肯定每一種情形，除仔細審查應用程序的所有源代碼外，沒有其餘更好的辦法。

肯定全部可能存在XSS風險、須要適當進行防護的操做後，須要採起一種三重防護方法阻止漏洞的發生。這種方法由如下三個因素組成：

#確認輸入

#確認輸出

#消除危險的插入點

（1）確認輸入

若是應用程序對某個位置收到的用戶提交的數據未來有可能被複制到它的響應中，應用程序應根據這種情形對這些數據執行儘量嚴格的確認。須要確認的數據的潛在特性包括如下幾點。

數據不是太長

數據僅包含某組合法字符

數據與一個特殊的正規表達式相匹配

根據應用程序但願在每一個字段中收到的數據類型，應儘量限制性的對姓名、電子郵件地址、帳號等應用不一樣的確認規則。

（2）確認輸出

若是應用程序將某位用戶或第三方提交的數據複製到它的響應中，那麼應用程序應對這些數據進行HTML編碼，以淨化可能的惡意字符。HTML編碼指用對應的HTML實體替代字面量字符。這樣作可確保瀏覽器安全處理可能爲惡意的字符，把他們當作HTML文檔的內容而非結構處理。一些常常形成問題的字符的HTML編碼以下：

" "

' '

& &

< <

> >

除這些經常使用的編碼外，實際上，任何字符均可以用它的數字ASCII字符代碼進行HTML編碼，

% &#37；

* &#42；

再將用戶可控制的字符串複製到服務器的響應中以前，ASP應用程序可使用Server，HTMLEncode API淨化其中的常見惡意字符。這個API把字符"&<和>轉換成他們對應的HTML實體，而且使用數字形式的編碼轉換任何大於Ox7f的ASCII字符。

在Java平臺中沒有與之等效的API；可是可使用數據形式的編碼構造本身的等效方法。例如：

public static String HTMLEncode(String s)

{

StringBuffer out = new StringBuffer();

for(int i = 0;i < s.length();i++)

{

char c = s.charAt(i);

if(c > Ox7f || c=='"' || c=='&'|| c=='<' || c=='>')

out.append("&#"+(int)c+";");

else out.append(c);

}

return out.toString();

}

當處理用戶提交的數據時，開發者經常會犯一個錯誤，即僅對在特殊狀況下對攻擊者有用的字符串進行HTML編碼。例如，若是數據被插入到一個雙引號引用的字符串中，應用程序可能只編碼"字符；若是數據被插入到一個沒有引號的標籤中，應用程序智慧編碼>字符。這種方法明顯增長了攻擊者避開確認的風險。攻擊者經常利用瀏覽器接受無效HTML與JavaScript的弱點，改變確認情境或以意外的方式注入代碼，並且攻擊者能夠將一個攻擊字符串分佈到幾個可控制的字段中，利用應用程序對每一個字段採用的不一樣過濾避開其餘過濾。一種更加可靠的方法是，不管數據插入到什麼地方，始終對攻擊者可能使用的每個字符進行HTML編碼。爲儘量的確保安全，開發者可能會選擇HTML編碼每個非字母數字字符，包括空白符。這種方法一般會顯著增長應用程序的工做壓力，同時給任未嘗試避開過濾的攻擊設置巨大障礙。

應用程序之因此結合使用輸入確認與輸出淨化，緣由在於這種方法可以提供兩層防護：若是其中那個一層被打破，另外一層還能提供一些保護。如上所述，許多執行輸入與輸出確認的過濾都容易被攻破。結合這兩種技巧，應用程序就可以得到額外的保護，即便攻擊者發現其中一種過濾存在缺陷，另外一種過濾仍然可以阻止他實施攻擊。在這兩種防護中，輸出確認最爲重要，必不可少。實施嚴格的輸入確認應被視爲一種次要故障恢復。

固然，當設計輸入與輸出確認機制時，咱們應特別當心，儘可能避免任何可能致使攻擊者避開確認的漏洞。尤爲要注意的是，應在實施相關規範化後在對數據進行過濾與編碼，並且以後不得對數據實施進一步的規範化。應用程序還必須保證其中存在空字節不會對它的確認形成任何干擾。

（3）消除危險的插入點

應用程序頁面中有一些位置，在這裏插入用戶提交的輸入就會形成極大的風險；所以，開發者應力求尋找其餘方法執行必要的功能。

應儘可能避免直接在現有的JavaScript中插入用戶可控制的數據。若是應用程序嘗試以安全的方式在其中插入數據。可能會使攻擊者有機會避開他實施的防護性過濾。一旦公告記者可以控制它提交的數據插入點，他不用付出多大努力就能夠注入任意腳本命令，從而實施惡意操做。

若是一個位置上有JavaScript命令直接出現，那麼也應禁止在這裏插入用戶輸入。例如：

在這些狀況下，攻擊者就能夠直接在引用字符串中注入JavaScript命令。並且，這時經過HTML編碼用戶數據進行防護也不會生效，由於一些瀏覽器在處理引用字符串的內容以前，會對他進行HTML解碼。例如：

若是攻擊者經過插入一個相關指令，或者由於應用程序使用一個請求參數指定首選的編碼類型，於是可以控制應用程序響應的編碼類型，那麼這些狀況也應該加以免。在這種狀況下，在其餘方面通過精心設計的輸入與輸出過濾可能就會失效，由於攻擊者的輸入進行了不常見的編碼，以至上述過濾並不將其視爲惡意輸入。只要有可能，應用程序應在他的響應消息頭中明確指定一種編碼類型，禁止對它進行任何形式的修改，並確保應用程序的XSS過濾與其兼容。例如：Content-Type ：text/html;charset=ISO-8859-1

2.防止基於DOM的XSS漏洞

很明顯，迄今爲止，咱們描述的防護機制並不能防止基於DOM的XSS漏洞，由於形成這種漏洞並不須要將用戶可控制的數據複製到服務器響應中

應用程序應儘可能避免使用客戶端腳本處理DOM數據並把它插入到頁面中。因爲被處理的數據再也不服務器的直接控制範圍內，有時甚至不在他的可見範圍內，所以這種行爲存在着固有的風險。

若是沒法避免的要以這種方式使用客戶端腳本，咱們能夠經過兩種防護方法防止基於DOM的XSS漏洞，他們分別與前面描述的防止反射型XSS漏洞時使用的輸入與輸出確認相對應。

（1）確認輸入

許多時候，應用程序能夠對它處理的數據執行嚴格的確認。確實，在這方面，客戶端確認比服務器端確認更加有效。在前面描述的易受攻擊的示例中，women你能夠經過確認將要插入到文檔中的數據僅包含字母數字字符與空白符，從而阻止攻擊發生。例如：

var a = document.URL;

a = a.substring(a.indexof("message=")+8,a.length);

a = unescape(a);

var regex=/^([A-Za-zO-9+\s])*$/;

if (regex.test(a))

document.write(a);

</script>

除這種客戶端控制外，還能夠在服務器端對URL數據進行嚴格的確認，實施深層防護，以檢測利用基於DOM的XSS漏洞的惡意請求。在剛剛說明的同一個示例中，應用程序甚至只需實施服務器端數據確認，經過確認如下數據來阻止攻擊：

查詢字符串中只有一個參數；

參數名爲message（大小寫檢查）；

參數值僅包含字母數字內容。

實施了這些控制後，客戶端腳本仍有必要正確解析出message參數的值，確保其中並不包含任何URL片斷字符。

（2）確認輸出

與防止反射型XSS漏洞時同樣，在將用戶可控制的DOM數據插入到文檔以前，應用程序也能夠對他們進行HTML編碼。這樣就能夠將各類危險的字符與表達式以安全的方式顯示在頁面中。

例如，使用下面的函數便可在客戶端JavaScript中執行HTML編碼：

function sanitize(str)

{

var d = document.createElement('div');

d.appendChild(document.createTextNode(str));

return d.innerHtml;

}

3.防止XST

應用程序XST技巧取決於攻擊者可否找到某種XSS漏洞，可在其餘用戶查看的頁面中插入任意JavaScript。所以，要想消除所有的XSS漏洞，必須阻斷攻擊者使用這種技巧的任何機會。儘管如此，咱們仍然建議在管理應用程序的Web服務器上將全部Cookie標記爲HttpOnly，同時禁止TRACE方法。

12.2 重定向攻擊

若是應用程序提取用戶可控制的輸入，並使用這個數據執行一個重定向，指示用戶的瀏覽器訪問一個不一樣於用戶要求的URL，那麼就會形成重定向漏洞。相比於可用以執行大量惡意操做的跨站點腳本漏洞，重定向漏洞不大會引發攻擊者的興趣。攻擊者主要利用重定向漏洞實施釣魚攻擊，誘使受害者訪問一個欺騙性Web站點並輸入敏感信息。對受害者而言，重定向漏洞提升了攻擊者的可信度，由於它容許攻擊者建立一個指向他所針對的可信Web站點的URL，所以更具備說服力，但任何訪問這個URL的用戶將被悄悄重定向到攻擊者控制的一個Web站點。實際上，許多應用程序確實將指向第三方站點的重定向做爲他們的正常功能，例如，處理顧客支付貸款。這促使用戶在交易過程當中信任重定向。當利用重定向漏洞時，攻擊者便可對這種認知加以利用。

滲透測試步驟：

（1）肯定應用程序中使用重定向的全部位置

（2）要肯定全部重定向，一個有效的方法是使用攔截代理服務器瀏覽應用程序，並監控訪問頁面的請求（相對於其餘資源，如圖像、樣式表、腳本文件等）。

（3）若是一個導航操做致使幾個連續請求，分析它使用什麼方法進行重定向。

（4）若是用戶數據被一個包含絕對URL的重定向處理，那麼修改URL中的域名，並測試應用程序是否將重定向到另外一個域。

（5）若是用戶被一個包含相對URL的重定向處理，將相對URL修改成指向另外一個域的絕對URL，並測試應用程序是否將重定向到這個域

（6）不管是哪種狀況，若是見到如下行爲，那麼應用程序確定容易受到重定向攻擊；

GET /redir.php?target=http://wahh-attacker.com/ HTTP/1.1

HOST:wahh-app.com

HTTP/1.1 302 object moved

Location:http://wahh-attacker.com/

1.避開攻擊中的障礙

（1）阻止絕對URL

應用程序可能會檢查用戶提交的字符串是否以HttpP//開頭，若是是，就阻止該請求。

（2）附加一個絕對前綴

12.2.2防止重定向漏洞

毫不將用戶提交的數據合併到重定向目標中是避免重定向漏洞的最有效的方法。

（1）從應用程序中刪除重定向頁面，用直接指向相關目標URL的連接替代指向重定向頁面的連接

（2）創建一個包含全部有效重定向URL的列表，不以參數的形式向重定向頁面傳送目標URL，相反，傳送這個列表的一個索引。重定向頁面應在它的列表中查詢這個索引，並返回一個指向相關URL的重定向。

（3）應用程序應在全部重定向中使用相對URL，重定向頁面應嚴格確認它收到URL是一個相對URL。它應當確認：用戶提交的URL或者以單獨一個斜線字符、後接一個字母開頭。或者以一個字母開頭，而且在第一個斜線前沒有冒號。應拒絕而不是淨化任何其餘輸入。

（4）應用程序應該在全部重定向中使用相對於Web根目錄的URL，在發佈重定向以前，重定向頁面應在全部提交的URL前附加http://yourdomainname.com。若是用戶提交的URL並不以斜線字符開頭，應在它的前面附加http://yourdomainname.com/。

（5）應用程序應對全部重定向使用絕對URL，重定向頁面在發佈重定向以前，應確認用戶提交的URL以http://yourdomainname.com/開頭。此外，應拒絕任何其餘輸入。

12.3 HTTP消息頭注入

若是用戶控制的數據以不安全的方式插入到應用程序返回的HTTP消息頭中，就會出現HTTP消息頭注入漏洞。若是攻擊者可以在他控制的消息頭中注入換行符，他就能再響應中插入其餘HTTP消息頭，並在響應主體中寫入任意內容。

這種漏洞最多見於Location與Set-Cookie消息頭中，但也會出如今其餘HTTP消息頭中。前文已經講到，應用程序提取用戶提交的輸入，並將它插入到響應碼爲3xx的Location消息頭中。一樣，一些應用程序提取用戶提交的輸入，把它插入一個cookie值中。例如：GET /home.php?uid=123 HTTP/1.1

HOST:wahh-app.com

HTTP/1.1 200 OK

Set-Cookie:userID=123

....

在上述任何一種狀況下，攻擊者均可以使用回車符（OxOd）或換行符（OxOa）構造一個專門設計的請求，在他們控制的消息頭中注入一個換行符，從而在下面的行中注入其餘數據。例如：

GET /home.php?uid=123%0d%0aFoo:+bar http/1.1

HOST：myapp.com

HTTP/1.1 200 OK

Set-Cookie:UserID=123

Foo:bar

....