應該是好久以前吧，呵呵，大家應該還記得動易那個沒有過濾.和asp的漏子吧.在2003系統的iis6.0的配合下，我們小黑們很容易在如xx.asp的文件夾下上傳一個xx.jpg的木馬文件，這樣我們就可以得到web木馬了.今天我們談到的問題就是這個設計缺陷.

一：無法訪問大馬的疑問及解決辦法.

本來也想往原理性的方面探討下，可用google和百度怎么也搜索不出我想要的結果，而且網上找到的也只說了個方法：讓我們建一個xx.asp的文件夾，然后在其文件夾里面上傳一個木馬，把木馬改成jpg或者gif后就可以得到我們的后門馬了，可今天我試了一下的時候卻出現了一些讓人疑惑的問題.還是用實驗來說明下情況吧.我的虛擬機是2003的，裝有iis6.0并充許asp及aspx腳本文件執行.那么我們一步步來實驗下,首現我的的IIS目錄下建一個1.asp的文件夾，里面放了一個大馬，文件名已經改成dama.jpg，如圖1.

接著我們來到本機上訪問下，如圖2 ,成功訪問了.然后我們訪問下試，如圖3. 直接轉向了1.asp文件夾下了，這是怎么回事呢？這個是本文要解決的問題之一.問題很奇怪，按理說，都能訪問了，應該可以正常登陸及使用呀.到網上搜索了下，沒有發現有這樣類似的問題出現，于是和群里討論了下，小組成員小浪給了我很大的啟發：他認為既然都可以解析web木馬了，那出現不能登陸的問題應該出現木馬的身上,從剛才的圖片可以看得出，木馬接收到的參數發生了變化，也就是自動轉向了1.asp文件夾里，這是為什么呢？我們來看看木馬的參數是怎么接收的呢？我從一個大馬里找出了以下幾行代碼：
URL=Request.ServerVariables("URL")
ServerIP=Request.ServerVariables("LOCAL_ADDR")
Action=Request("Action")
最關鍵的是***句，接收到的參數是通過url來傳遞的，也就是說當我們登陸的時候，服務器會解析1.asp（這里我也表達的不太清楚），所以無法驗證的情況便出現了.因此為了解決這個問題，我們只需要把***句換成:
URL=Request.ServerVariables("PATH_INFO")
這樣，我們就可以順利的用大馬訪問了，如圖4. 這里我們就不得不提下path_info這個變量了它的功能就是呈現虛擬路徑了,也就是可以順利解析到dama.jpg下.不過從網上得到答案是，直接先訪問小馬就不會出現這個問題，如圖5

.這是因為小馬的功能簡單，不涉及到復雜的路徑解析，不過我等小菜應該本著學習的精神把更多的原理弄懂才是最要緊的.

二：對其它腳本文件解析的思考.

小菜貴在學習和舉一反三，可能我說的這個問題大牛們早就知道了，不過自己想出來的以及證明才是最重要的！不多說了，當時我就想既然能解析xx.asp文件夾下的文件，那xx.aspx，xx.php等是不是會解析相應的腳本文件，我的虛擬機可以解析aspx的馬，我們來試試，我這里就直接在IIS目錄下新建了個文件，然后訪問我的aspx文件，如圖6.

開始以為和asp大馬一樣要改下什么東西，可當我把一個平常的aspx文件放上去的時候，也不能.(不過，后來證實確實不能解析xx.aspx下的，因為連正常木馬的aspx頁面都沒出來).那么xx.php呢？雖然我的虛擬機上沒有裝php的環境，但如果能解析的話，當我訪問的時候，要么就全部把php源碼直接顯示出來，要么直接顯示下載，大家看圖，證明我的猜想是正確的，如圖7.

猜想始終是猜想，為了確保想法的正確性，又叫小浪同學測試了下，確實能夠把xx.php文件夾下的文件解析成php文件（不過，他是用正常的PHP文件測試的，沒有用PHP馬來測試）.

小結下:這篇文章主要是想弄清其它的原理以及對其它腳本是否也支持這種形式的解析做的探討，當然因為條件有限，我也沒有繼續測試cfm,cgi以及jsp等其它腳本文件了.同時也希望大家多關注下原理性的東西，畢竟了解原理才是最重要的.