PHP中SQL注入與跨站攻擊的防范說課講解

1、Good is good, but better carries it.精益求精，善益求善。PHP中SQL注入與跨站攻擊的防范-HYPERLINK/blog/722458PHP中SQL注入與跨站攻擊的防范SQLinjection即SQL注入是我們每個WEB程序員都需要面對的問題，一個WEB應(yīng)用假如沒有起碼的安全性，那么其它的一切就可以免談了。注入問題在ASP上可謂是鬧得沸沸揚(yáng)揚(yáng)，當(dāng)然還有不少PHP程序“遇難”。至于SQLinjection的詳情，網(wǎng)上的文章很多，在此就不作贅述。追其罪惡之源，就是我們誤以為用戶提交的數(shù)據(jù)是可靠的。無論你是否有足夠的PHP安全開發(fā)經(jīng)驗(yàn)，本文的目的就是用來幫助你構(gòu)建

2、更為安全的在線應(yīng)用程序。針對不同的情況，我們可以使用下面的一種或幾種方法來對SQL注入的風(fēng)險進(jìn)行預(yù)防。1、在書寫SQL語句時不要省略單引號，即使是整型字段也應(yīng)該加上單引號。首先，從技術(shù)上講，引號對于數(shù)字值來說是不需要使用的。但是，假如你不使用引號把例如書籍?dāng)?shù)量這樣的一個值括起來，并且假如你的用戶把一個空值輸入到你的表單中，那么，你將會看到一個類似下面的查詢：SELECT*FROMbooksWHEREnum=當(dāng)然，這個查詢從語法上講是無效的；但是，下面的語法卻是有效的：SELECT*FROMbooksWHEREnum=第二個查詢雖然也不會返回任何結(jié)果，但是至少它不會返回一個錯誤消息。其次，單引號

3、可以增加注入者的難度，第二句由于把變量放在一對單引號中，這樣使得我們所提交的變量都變成了字符串，即使包含了正確的SQL語句，也不會正常執(zhí)行，而第一句不同，由于沒有把變量放進(jìn)單引號中，那我們所提交的一切，只要包含空格，那空格后的變量都會作為SQL語句執(zhí)行，因此，我們要養(yǎng)成給SQL語句中變量加引號的習(xí)慣。2、檢查用戶提交的值的類型，對接收到的整型參數(shù)使用intval()強(qiáng)制轉(zhuǎn)換成整形。我們知道SQL注入的主要來源往往出在一個意料之外的表單提交或URL參數(shù)中，所以當(dāng)你接受一個由用戶提交的參數(shù)時，你應(yīng)該有相當(dāng)?shù)臋?quán)利來確定你想取得什么樣的輸入內(nèi)容。在以前的學(xué)習(xí)中我們已經(jīng)討論過很多這樣或那樣的校驗(yàn)問題。因

4、此我們只要簡單的總結(jié)當(dāng)時我們討論的要點(diǎn)即可比較輕易的檢查用戶提交數(shù)據(jù)的有效性。假如你期望得到的是一個數(shù)值，那么你可以使用下面這些技術(shù)之一來確保你得到的參數(shù)的安全性。使用is_int()函數(shù)(或is_integer()或is_long()。使用gettype()函數(shù)。使用intval()函數(shù)。使用settype()函數(shù)。我們通常把傳送過來的整型參數(shù)使用intval()函數(shù)強(qiáng)制轉(zhuǎn)換成整形，因?yàn)榧偃绮贿@樣做，接收到的查詢子句很可能會附帶著其它一些我們并不愿看到的語句，比如原本應(yīng)該是“nid=17”可能會成為“nid=17or1=1”，這會使我們預(yù)計(jì)的SQL語句變成這樣：SELECT*FROMnews

5、WHEREnid=17or1=1這對于一個新聞表中的信息可能不會造成什么大的危害，但假如是在顯示某個用戶的信息時呢？此外，為了檢查用戶輸入內(nèi)容的長度，你可以使用strlen()函數(shù)。為了檢查一個期望的時間或日期是否有效，你可以使用strtotime()函數(shù)。它似乎一定能夠確保一位用戶的提交參數(shù)中沒有包含分號字符(除非標(biāo)點(diǎn)符號可以被合法地包括在內(nèi))。你可以借助于strpos()函數(shù)輕易地實(shí)現(xiàn)這一點(diǎn)，如下所示：if(strpos($variety，;)exit($varietyisaninvalidvalueforvariety!);正如我們在前面所提到的，只要你仔細(xì)分析你的用戶輸入期望，那么，你

6、應(yīng)該能夠很輕易地檢查出其中存在的許多問題。3、使用mysql_real_escape_string()函數(shù)從查詢字符串中過濾掉危險字符盡管有很多文章已經(jīng)討論過如何過濾掉危險字符的問題，但是在本文中還是讓我們再次簡單的強(qiáng)調(diào)并歸納一下這個問題：不要使用magic_quotes_gpc指令或它的搭擋addslashes()函數(shù)，此函數(shù)在程序開發(fā)中應(yīng)該是被限制使用的，在PHP的下一個版本PHP6中已經(jīng)取消了對此函數(shù)的支持，并且此函數(shù)還要求使用額外的步驟stripslashes()函數(shù)。相比之下，mysql_real_escape_string()函數(shù)更為適合，受此函數(shù)影響的字符包括：x00,n,r,x

7、1a。這二個函數(shù)的功能類似，但addslashes()函數(shù)無法轉(zhuǎn)換以十六進(jìn)制形式提交的字符，另外需要注重的是，mysqli_real_escape_string()函數(shù)需要先建立數(shù)據(jù)庫連接，因?yàn)樾枰紤]到連接的當(dāng)前字符集，通常防止數(shù)據(jù)庫被攻擊的使用方法如下：4、對用戶輸入的字符進(jìn)行HTML編碼以防止跨站攻擊（這個一般在服務(wù)器端進(jìn)行過濾）對于數(shù)據(jù)庫防止SQL注入的問題，通過前面三點(diǎn)所述綜合的運(yùn)用我們似乎全部解決，但假如用戶提交的內(nèi)容中有一些不良的HTML標(biāo)簽則可能會導(dǎo)致頁面變形，嚴(yán)重的還可能會出現(xiàn)跨站攻擊之類的安全問題，所以對帶有HTML的內(nèi)容增加過濾檢查是很有必要的。例如一段接收用戶的輸入并顯

8、示的功能代碼，一但惡意用戶輸入：location.href=;這樣的一條數(shù)據(jù)，網(wǎng)頁在顯示該條數(shù)據(jù)時，用戶的瀏覽器將會跳轉(zhuǎn)到惡意代碼指定的地址，這就是最簡單的跨站攻擊，我們試想一下，假如跳轉(zhuǎn)的地址是一個偽造原網(wǎng)站來騙取用戶密碼或銀行信息的頁面，那么會是什么樣的后果？對于這類攻擊行為，就需要我們在接收用戶提交的數(shù)據(jù)時在服務(wù)器端進(jìn)行過濾，我們可以編寫一個過濾函數(shù)用來查詢提交數(shù)據(jù)中有害字符并將之替換掉，還有一種較簡便的方式就把用戶所提交的內(nèi)容中“”，“&”等符號轉(zhuǎn)換成正確的HTML編碼，而函數(shù)htmlspecialchars()正是干這個活的。htmlspecialchars()功能：將“&”五個字符

9、轉(zhuǎn)換成HTML字符串。語法：stringhtmlspecialchars(string,quotestyle,character-set);參數(shù)：ENT_NOQUOTES，不對任何引號進(jìn)行格式化；ENT_QUOTES，對單引號及雙引號進(jìn)行格式化；默認(rèn)為ENT_COMPAT，僅編碼雙引號。返回值：字符串因此，用戶提交的數(shù)據(jù)經(jīng)過格式化后為：location.href=;這樣代碼就失去了原有的攻擊功能，可以基本預(yù)防腳本攻擊的潛在危險，假如不明白這之間的區(qū)別，可以測試下面這段代碼：?php$str=PHP3C技術(shù)分享社區(qū);echo$str;echo;echohtmlspecialchars($str);?另外，轉(zhuǎn)換非凡字符為HTML字符串還可以使用函數(shù)htmlentities()，使用方法相同，它與htmlspecialchars在格式化帶有英文字符的html代碼的時候沒有什么區(qū)別，但是htmlentities對中文字符也不放過，所以同樣的調(diào)用方法得出來的結(jié)果是由于沒有指定字符集而默認(rèn)由ISO-8859-1代替，中文字符部分變?yōu)橐欢褋y碼，因此我們在使用的時候，需要指定參數(shù)character-set為我們頁面使用的字符集，例如UTF-8或GB2312。SQL注入