web安全實踐系列主要是對《黑客web應用安全機密與解決方案（第二版）》的內容做的實踐研究和部分編程實現。所以如果您能完全理解那本書可以跳過本文章。 另外我需要更多的像我一樣的人來參與這項工作。 廢話還是少說的好，我們進入今天的正題。 正文 昨天由于太累了，沒把剩下的內容寫完，今天繼續。主要內容是代理和防火墻的探測。 如果代理服務器對外就表現為一個Web服務器，外部網絡就可以簡單把它當作一個標準的Web服務器而不需要特定的配置。不同之處在于，這個服務器沒有保存任何網頁的真實數據，所有的靜態網頁或者CGI程序，都保存在內部的Web服務器上。因此對反向代理服務器的并不會使得網頁信息遭到，這樣就增強了Web服務器的安全性。我們的主要目的是檢測目標服務器是否通過代理服務器來響應請求，以免我們丟失目標。 （1）Trace請求。當我們像web服務器發送一個Trace請求之后，服務器會回顯接收到的請求。如果正常情況下，返回的請求應該就是我們發送的請求。但是如果我們的請求是先到達一個代理服務器然后真正的web服務器接收到的就應該是代理服務器的請求，也是就是返回的信息也應該是代理服務器的請求信息而不是我們最初發送的請求。說著有點迷糊，下面看一個實際的例子。不過由于一些服務器在處理trace請求存在跨站漏洞，很多網站是不支持trace請求的。 X-AspNet-Version: 2.0.50727Cache-Control: privateContent-Type: text/html; charset=utf-8Content-Length: 3432.....titlePath trace is forbidden./title （2）Connect標準測試. 一般情況下HTTP代理服務都會支持HTTP CONNECT的方法，利用他能建立一個TCP連接來繞過一般的應用層功能。一般，HTTP CONNECT方法都用來通過HTTP代理來建立HTTPS連接。 利用Connect測試的方法就是向一個已知站點發送Connect，觀察響應信息來確定是否來自代理。 （1）連續的具有入侵特征的連接。 如果有防火墻它會你的連接。對于服務器的入侵掃描一般都會遭到防火墻的。其實我們現在可以肯定的是幾乎所有的正規網站都會有防火墻的。我們面臨的難題應該是對方使用的是什么類型的防火墻而不是用沒用防火墻的問題。 （2）防火墻類型的診斷。 其實這和http指紋研究一樣也應該是個統計學的問題。判斷的思想應該是向服務器發送各種類型的非法請求，并判斷出是否是防火墻作出的回應，回應的特征是什么。總結過程該是各個有機會接觸防火墻配置的人。這項工作的研究目前還不是十分完善。我的條件也不允許我做這這個實驗，我還是希望得到更多的人關于這方面的反饋。 觀察的方面： 響應信息 TerosWeb 應用防火墻技術會對trace請求作出500響應，提示：Invalid method code。F5TrafficShield會返回400錯誤，并提示：The Server could not anderstand your request。Your error ID is： Netcontinuum對任何非法請求都返回404錯誤。 SecureIIs會返回406錯誤。 特殊的cookie Teros對每次響應都要使用同一個名st8id。 TrafficShield會使用cookie名為ASINFO。 特殊的錯誤情況 URLScan如果接收一個Path長度大于260個字符的請求，就返回404錯誤，而且如果在請求中添加如ranslate，if，Lock-Token,Transfer-Encoding等頭部，就會請求。 SecureIIs 默認頭部最大長度為1024個字符。 那么就說明這個目錄的寫權限是開著的，反之，如果返回的是一個403錯誤，那么寫權限就是沒有開起來，如果需要你認證，并且返回一個 401(權限) 的響應的話，說明是開了寫權限，但是匿名用戶不允許。如果一個目錄同時開了寫和腳本和可執行程序的話，那么web用戶就可以上傳一個程序并且執行它。今天做了一天的實驗，發現這部分知識總體上技術都不成熟，有待發展。其實這是矛盾的，技術成熟了對現有網站的也就大了。但從技術的角度講我希望得到相關專家的幫助。 明天的內容按計劃應該是簡單的http編程實踐。 |