畸形的請求測試（繞過waf的一種手法）
另一個有用測試是傳送畸形的請求或者不存在的頁面請求，考慮如下HTTP響應： Consider the following HTTP responses。
Apache 1。3。23
檔案上傳
Windows 8。3 經典檔案處理有時候能夠繞過檔案上傳過濾機制：
一些用例：
file。phtml 能被視為PHP程式碼處理
FILE~1。PHT 能訪問，但不被PHP ISAPI處理程式處理
shell。phPWND 能上傳
SHELL~1。PHP 會被OS shell擴充套件，然後被PHP ISAPI處理程式處理測試潛在的XST注意： 為了理解這個攻擊的邏輯和目標，攻擊者必須熟悉 。TRACE方法，看上去沒有危害，但能在某些場景下成功被利用並盜取合法使用者的憑證。這個攻擊技巧被Jeremiah Grossman在2003年發現，一次企圖繞過 標籤，以及微軟引進IE6 SP1來保護cookies被JavaScript訪問。事實上，XSS上最常見的攻擊模式是獲取document。cookie，並將它發到攻擊者控制的伺服器，以便於攻擊者能夠劫持受害者的會話。標記為httponly的cookie禁止JavaScript訪問，被保護無法傳送給第三方。然而TRACE方法能用於繞過這層防護已經在上述場景裡訪問cookie。正如先前提到的，TRACE簡單返回任何傳送給伺服器的字串。為了證明方法可行（或使用OPTIONS請求），測試者像如下例子中操作：
響應主體正好是我們原始請求的複製，意味著目標允許這個方法。現在哪裡潛伏危機？如果測試者指示瀏覽器向web伺服器發起TRACE請求，並且瀏覽器存在該域名的cookie，這個cookie會自動包含在請求頭中，如此會在響應結果中回顯。此時，cookie能被JavaScript訪問並最後可能傳送給第三方即使這個cookie是標記為httpOnly的。有多種方式使瀏覽器傳送TRACE請求，比如IE中的XMLHTTP ActiveX控制元件，Mozilla和Nescape的XMLDOM。然而，由於安全原因，瀏覽器只允許從惡意指令碼存在的域名發起這樣連線。這是一個緩解因素，因為攻擊者需要結合其他漏洞和TRACE方法來完成攻擊。一個攻擊者有兩種成功實施XST攻擊的方法：·； 利用其他伺服器端漏洞：攻擊者向漏洞應用注入包含TRACE請求的惡意JavaScript程式碼就像正常XSS攻擊那樣。·； 利用客戶端漏洞：攻擊者建立一個惡意站點包含惡意JS程式碼和瀏覽器的跨域漏洞利用程式，使JS程式碼能成功發起支援TRACE方法和目標cookie的請求。更多的資訊和程式碼例子能從Jeremah Grossman的白皮書中找到。測試任意HTTP方法
找到一個頁面含有安全約束控制使通常訪問強制返回302跳轉到登陸頁面或強制登陸。這個測試URL在下面例子中是這麼工作的，如同許多web應用那樣。然後，如果測試者獲得一個200響應卻又不是登陸頁面，那麼他可能繞過了認證和授權過程。
如果框架或者防火牆或應用不支援“JEFF”方法，那麼他應該指向一個錯誤頁面（更好的是返回405響應不允許，或者501響應未實現錯誤頁面）。如果伺服器產生正常應答，那麼這可能是一個漏洞。如果測試者覺得系統存在這個漏洞，他們應該發起一些像CSRF一樣的攻擊來利用這個問題，比如：·； FOOBAR /admin/createUser。php？member=myAdmin·； JEFF /admin/changePw。php？member=myAdmin&passwd=foo123&confirm=foo123·； CATS /admin/groupEdit。php？group=Admins&member=myAdmin&action=add如果足夠幸運，使用上面三個命令 - 修改符合適合測試情況的需求 - 一個新的管理員使用者將被建立，並分配了密碼。測試HEAD訪問控制繞過
找到一個頁面含有安全約束控制使通常訪問強制返回302跳轉到登陸頁面或強制登陸。這個測試URL在下面例子中是這麼工作的，如同許多web應用那樣。然後，如果測試者獲得一個200響應卻又不是登陸頁面，那麼他可能繞過了認證和授權過程。
如果攻擊者得到 “405 方法不允許” 或 “501 方法未實現”，那麼目標（應用/框架/語言/系統/防火牆）是正確工作的。如果返回200響應，而且不存在響應主體，那麼很可能應用在沒有認證和授權的情況下處理了請求，需要進一步測試。如果測試者覺得系統存在這個漏洞，他們應該發起一些像CSRF一樣的攻擊來利用這個問題，比如：·； HEAD /admin/createUser。php？member=myAdmin·； HEAD /admin/changePw。php？member=myAdmin&passwd=foo123&confirm=foo123·； HEAD /admin/groupEdit。php？group=Admins&member=myAdmin&action=add如果足夠幸運，使用上面三個命令 - 修改符合適合測試情況的需求 - 一個新的管理員使用者將被建立，並分配了密碼，所有過程使用了盲請求提交。HTTP嚴格傳輸安全測試綜述HTTP嚴格傳輸安全（HTTP Strict Transport Security， HSTS）頭是一項機制：在特定域名下，網站和瀏覽器之間通訊必須都透過https傳輸。這有助於保護資訊從非加密請求中洩露。考慮這個安全措施的重要意義，測試的關鍵在於驗證網站是否使用這個HTTP頭，來確保所有資料都是從瀏覽器加密傳輸到伺服器端的。HTTP嚴格傳輸安全特徵使得web應用能夠透過使用特別的響應頭告訴瀏覽器不要使用HTTP與特定伺服器建立連線。相對的，所有訪問請求都應該自動透過HTTPS建立連線。HSTS頭使用兩個指令：·； max-age： 來指示瀏覽器應該自動轉換所有HTTP請求為HTTPS的時間（秒）。·； includeSubDomains： 來指明所有web應用的子域名也必須使用HTTPS。下面是一個HSTS頭實現的例子：
使用HSTS頭的應用必須檢查如下幾個可能產生的問題：·； 攻擊者可能嗅探網路瀏覽來訪問未加密的通道獲得資訊。·； 攻擊者利用中間人攻擊手段，因為證書可能不可信任。·； 使用者錯誤輸入HTTP地址來替換HTTPS，或者使用者點選了web應用中的錯誤使用HTTP協議的連結。如何測試可以使用劫持代理或者curl來測試HSTS頭是否存在與伺服器應答中，如下所示： $ curl -s -D- https：//domain。com/ | grep Strict期望結果：Strict-Transport-Security： max-age=。。。
