提示：Request對象探討 Request是ASP裡的一個內部對象，用於獲取HTTP請求中傳遞的任意信息(如頭信息、表單數據、cookIEs等等)。所以這是在ASP裡面最常用的內部對象，常用來獲得GET方式提交的數據(Request.QueryString)、表單POST提交的數據(Request. Form)和CookIEs(Request.
Request對象探討
Request是ASP裡的一個內部對象，用於獲取HTTP請求中傳遞的任意信息(如頭信息、表單數據、cookIEs等等)。所以這是在ASP裡面最常用的內部對象，常用來獲得GET方式提交的數據(Request.QueryString)、表單POST提交的數據(Request. Form)和Cookies(Request.CookIEs)。
我們用Request對象可以指定獲取某個特定方式提交的數據。比如我們用這段代碼獲得通過POST提交的數據lake2的值：request.Form("lake2")；而request.queryString("CSDN")獲得GET方式提交的CSDN的值。
對於獲取HTTP數據，ASP還給了我們一個更簡單的方法：request(key)，即直接使用request而不指定數據集合。此時ASP會依次在QueryString、From、Cookies、ServerVariables、ClIEntCertificate、Browser中檢查匹配的數據，若發現則返回數據。
上面6個集合中，ServerVariables、ClientCertificate和Browser的變量是固定了的；而QueryString、From、Cookies的變量可以任意指定。想不到CookIEs可以拿來傳遞任意數據，以前倒沒有注意。
OK，test一下先。在本地web目錄新建test.ASP文件，內容為：<%=request("b")%>
Step 1：直接訪問http://127.0.0.1/test.ASP?b=la<b>k</b>e2,浏覽器顯示lake2
Step 2：構造表單提交結果也如step 1
Step 3： 構造表單，GET傳遞b值為"He"，同時POST的b為"She"，浏覽器顯示為"He"。呵呵，按前面的排序有個優先級的
Step 4：Telnet到本地80端口，構造HTTP請求如下(注意CookIEs哦)：
GET /test.ASP HTTP/1.1
Accept: */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; TencentTraveler ; .Net CLR 1.1.4322)
Host: 127.0.0.1
Connection: Keep-Alive
CookIE: b=lake2 , Success !
在一堆服務器響應數據之後，我們看到了"lake2,Success!"(Q：為什麼空格不見了？A：因為未對提交的空格進行URL編碼)。
到此，我們已理論和實際相結合的證明了CookIEs可以拿來傳遞數據。
Request對象與SQL注入
現在把話題轉一下，我們來說說SQL Injection。
SQL注入攻擊是由於Web應用程序沒有過濾用戶所提交的有害數據而導致危害服務器的一種攻擊手法。注意咯，這裡涉及到提交數據，自然要跟剛才說了一大堆的request聯系上啊。
歸根結底，ASP下面的SQL注入都是由於request的參數沒有過濾或者過濾不嚴。當然，程序員不是安全專家，他們可能不知道如何過濾。
於是，網絡上就出現了通用的防注入ASP程序——"SQL通用防注入系統"。經過一段時間和幾個作者的改進，該程序已經比較完善了，基本上可以攔截SQL注入(但是，個人認為它的過濾方式太嚴，造成許多不便)。"SQL通用防注入系統"是個ASP文件，只需在有參數提交的文件中include它就是了。程序過濾的原理是遍歷GET和POST參數的值，發現SQL注入關鍵字(如and、select)就停止正常文件執行。
嘿嘿，它遍歷GET和POST，也就是Request對象的QueryString和From集合，忽略了CookIEs。
現在，我們假設有一個SQL Injection漏洞百出的ASP程序，具備網絡安全知識的管理員同學在網上下載並使用了傳說中的"SQL通用防注入系統"，但是很不幸，ASP程序中所有獲取參數都是使用的request(key)……(呵呵，眼看著一個個封鎖被突破，那是很enjoy的事情^_^)
這裡僅僅是假設而已，至於實際中到底有多少ASP程序員喜歡用request(key) 來獲取數據就不得而知咯。
