PHP中防止SQL注入的方法
【1、在服務器端配置】php
安全，PHP代碼編寫是一方面，PHP的配置更是很是關鍵。
咱們php手手工安裝的，php的默認配置文件在 /usr/local/apache2/conf/php.ini，咱們最主要就是要配置php.ini中的內容，讓咱們執行 php可以更安全。整個PHP中的安全設置主要是爲了防止phpshell和SQL Injection的攻擊，一下咱們慢慢探討。咱們先使用任何編輯工具打開 /etc/local/apache2/conf/php.ini，若是你是採用其餘方式安裝，配置文件可能不在該目錄。
(1) 打開php的安全模式
php的安全模式是個很是重要的內嵌的安全機制，可以控制一些php中的函數，好比system()，
同時把不少文件操做函數進行了權限控制，也不容許對某些關鍵文件的文件，好比/etc/passwd，
可是默認的php.ini是沒有打開安全模式的，咱們把它打開：
safe_mode = on
(2) 用戶組安全
當safe_mode打開時，safe_mode_gid被關閉，那麼php腳本可以對文件進行訪問，並且相同
組的用戶也可以對文件進行訪問。
建議設置爲：
safe_mode_gid = off
若是不進行設置，可能咱們沒法對咱們服務器網站目錄下的文件進行操做了，好比咱們須要
對文件進行操做的時候。
(3) 安全模式下執行程序主目錄
若是安全模式打開了，可是倒是要執行某些程序的時候，能夠指定要執行程序的主目錄：
safe_mode_exec_dir = D:/usr/bin
通常狀況下是不須要執行什麼程序的，因此推薦不要執行系統程序目錄，能夠指向一個目錄，
而後把須要執行的程序拷貝過去，好比：
safe_mode_exec_dir = D:/tmp/cmd
可是，我更推薦不要執行任何程序，那麼就能夠指向咱們網頁目錄：
safe_mode_exec_dir = D:/usr/www
(4) 安全模式下包含文件
若是要在安全模式下包含某些公共文件，那麼就修改一下選項：
safe_mode_include_dir = D:/usr/www/include/
其實通常php腳本中包含文件都是在程序本身已經寫好了，這個能夠根據具體須要設置。
(5) 控制php腳本能訪問的目錄
使用open_basedir選項可以控制PHP腳本只能訪問指定的目錄，這樣可以避免PHP腳本訪問
不該該訪問的文件，必定程度上限制了phpshell的危害，咱們通常能夠設置爲只能訪問網站目錄：
open_basedir = D:/usr/www
(6) 關閉危險函數
若是打開了安全模式，那麼函數禁止是能夠不須要的，可是咱們爲了安全仍是考慮進去。好比，
咱們以爲不但願執行包括system()等在那的可以執行命令的php函數，或者可以查看php信息的
phpinfo()等函數，那麼咱們就能夠禁止它們：
disable_functions = system,passthru,exec,shell_exec,popen,phpinfo
若是你要禁止任何文件和目錄的操做，那麼能夠關閉不少文件操做
disable_functions = chdir,chroot,dir,getcwd,opendir,readdir,scandir,fopen,unlink,delete,copy,mkdir, rmdir,rename,file,file_get_contents,fputs,fwrite,chgrp,chmod,chown
以上只是列了部分不叫經常使用的文件處理函數，你也能夠把上面執行命令函數和這個函數結合，
就可以抵制大部分的phpshell了。
(7) 關閉PHP版本信息在http頭中的泄漏
咱們爲了防止黑客獲取服務器中php版本的信息，能夠關閉該信息斜路在http頭中：
expose_php = Off
好比黑客在 telnet www.12345.com 80 的時候，那麼將沒法看到PHP的信息。
(8) 關閉註冊全局變量
在PHP中提交的變量，包括使用POST或者GET提交的變量，都將自動註冊爲全局變量，可以直接訪問，
這是對服務器很是不安全的，因此咱們不能讓它註冊爲全局變量，就把註冊全局變量選項關閉：
register_globals = Off
固然，若是這樣設置了，那麼獲取對應變量的時候就要採用合理方式，好比獲取GET提交的變量var，
那麼就要用$_GET['var']來進行獲取，這個php程序員要注意。
(9) 打開magic_quotes_gpc來防止SQL注入
SQL注入是很是危險的問題，小則網站後臺被入侵，重則整個服務器淪陷，
因此必定要當心。php.ini中有一個設置：
magic_quotes_gpc = Off
這個默認是關閉的，若是它打開後將自動把用戶提交對sql的查詢進行轉換，
好比把 ' 轉爲 \'等，這對防止sql注射有重大做用。因此咱們推薦設置爲：
magic_quotes_gpc = On
(10) 錯誤信息控制
通常php在沒有鏈接到數據庫或者其餘狀況下會有提示錯誤，通常錯誤信息中會包含php腳本當
前的路徑信息或者查詢的SQL語句等信息，這類信息提供給黑客後，是不安全的，因此通常服務器建議禁止錯誤提示：
display_errors = Off
若是你倒是是要顯示錯誤信息，必定要設置顯示錯誤的級別，好比只顯示警告以上的信息：
error_reporting = E_WARNING & E_ERROR
固然，我仍是建議關閉錯誤提示。
(11) 錯誤日誌
建議在關閉display_errors後可以把錯誤信息記錄下來，便於查找服務器運行的緣由：
log_errors = On
同時也要設置錯誤日誌存放的目錄，建議根apache的日誌存在一塊兒：
error_log = D:/usr/local/apache2/logs/php_error.log
注意：給文件必須容許apache用戶的和組具備寫的權限。
MYSQL的降權運行
新創建一個用戶好比mysqlstart
net user mysqlstart fuckmicrosoft /add
net localgroup users mysqlstart /del
不屬於任何組
若是MYSQL裝在d:\mysql ，那麼，給 mysqlstart 徹底控制 的權限
而後在系統服務中設置，MYSQL的服務屬性，在登陸屬性當中，選擇此用戶 mysqlstart 而後輸入密碼，肯定。
從新啓動 MYSQL服務，而後MYSQL就運行在低權限下了。
若是是在windos平臺下搭建的apache咱們還須要注意一點，apache默認運行是system權限，
這很恐怖，這讓人感受很不爽.那咱們就給apache降降權限吧。
net user apache fuckmicrosoft /add
net localgroup users apache /del
ok.咱們創建了一個不屬於任何組的用戶apche。
咱們打開計算機管理器，選服務，點apache服務的屬性，咱們選擇log on，選擇this account，咱們填入上面所創建的帳戶和密碼，
重啓apache服務，ok，apache運行在低權限下了。
實際上咱們還能夠經過設置各個文件夾的權限，來讓apache用戶只能執行咱們想讓它能幹的事情，給每個目錄創建一個單獨能讀寫的用戶。
這也是當前不少虛擬主機提供商的流行配置方法哦，不過這種方法用於防止這裏就顯的有點大材小用了。 html
【2、在PHP代碼編寫】mysql
雖然國內不少PHP程序員仍在依靠addslashes防止SQL注入，仍是建議你們增強中文防止SQL注入的檢查。addslashes的問題在於黑客能夠用0xbf27來代替單引號，而addslashes只是將0xbf27修改成0xbf5c27，成爲一個有效的多字節字符，其中的0xbf5c仍會被看做是單引號，因此addslashes沒法成功攔截。
固然addslashes也不是毫無用處，它是用於單字節字符串的處理，多字節字符仍是用mysql_real_escape_string吧。
另外對於php手冊中get_magic_quotes_gpc的舉例：
if (!get_magic_quotes_gpc()) {
$lastname = addslashes($_POST[‘lastname’]);
} else {
$lastname = $_POST[‘lastname’];
}程序員
最好對magic_quotes_gpc已經開放的狀況下，仍是對$_POST[’lastname’]進行檢查一下。
再說下mysql_real_escape_string和mysql_escape_string這2個函數的區別：
mysql_real_escape_string 必須在(PHP 4 >= 4.3.0, PHP 5)的狀況下才能使用。不然只能用 mysql_escape_string ，二者的區別是：mysql_real_escape_string 考慮到鏈接的
當前字符集，而mysql_escape_string 不考慮。
總結一下：
* addslashes() 是強行加\；
* mysql_real_escape_string() 會判斷字符集，可是對PHP版本有要求；
* mysql_escape_string不考慮鏈接的當前字符集。
-------------------------------------------------------------------------------------------------
在PHP編碼的時候，若是考慮到一些比較基本的安全問題，首先一點：
1. 初始化你的變量
爲何這麼說呢？咱們看下面的代碼：
PHP代碼
算法
|
1
2
3
4
5
6
7
8
9
10
11
|
<?php
if
(
$admin
)
{
echo
'登錄成功！'
;
include
(
'admin.php'
);
}
else
{
echo
'你不是管理員，沒法進行管理！'
;
}
?>
|
好，咱們看上面的代碼好像是能正常運行，沒有問題，那麼加入我提交一個非法的參數過去呢，那麼效果會如何呢？好比咱們的這個頁是http://daybook.diandian.com/login.php，那麼咱們提交：http://daybook.diandian.com/login.php?admin=1，呵呵，你想一些，咱們是否是直接就是管理員了，直接進行管理。
固然，可能咱們不會犯這麼簡單錯的錯誤，那麼一些很隱祕的錯誤也可能致使這個問題，好比phpwind論壇有個漏洞，致使可以直接拿到管理員權限，就是由於有個$skin變量沒有初始化，致使了後面一系列問題。那麼咱們如何避免上面的問題呢？首先，從php.ini入手，把php.ini裏面的register_global =off，就是否是全部的註冊變量爲全局，那麼就能避免了。可是，咱們不是服務器管理員，只能從代碼上改進了，那麼咱們如何改進上面的代碼呢？咱們改寫以下：
PHP代碼
sql
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
<?php
$admin
= 0;
// 初始化變量
if
(
$_POST
[
'admin_user'
] &&
$_POST
[
'admin_pass'
])
{
// 判斷提交的管理員用戶名和密碼是否是對的相應的處理代碼
// ...
$admin
= 1;
}
else
{
$admin
= 0;
}
if
(
$admin
)
{
echo
'登錄成功！'
;
include
(
'admin.php'
);
}
else
{
echo
'你不是管理員，沒法進行管理！'
;
}
?>
|
那麼這時候你再提交http://daybook.diandian.com/login.php?admin=1就很差使了，由於咱們在一開始就把變量初始化爲 $admin = 0 了，那麼你就沒法經過這個漏洞獲取管理員權限。
2. 防止SQL Injection (sql注射)
SQL 注射應該是目前程序危害最大的了，包括最先從asp到php，基本上都是國內這兩年流行的技術，基本原理就是經過對提交變量的不過濾造成注入點而後使惡意用戶可以提交一些sql查詢語句，致使重要數據被竊取、數據丟失或者損壞，或者被入侵到後臺管理。
那麼咱們既然瞭解了基本的注射入侵的方式，那麼咱們如何去防範呢？這個就應該咱們從代碼去入手了。
咱們知道Web上提交數據有兩種方式，一種是get、一種是post，那麼不少常見的sql注射就是從get方式入手的，並且注射的語句裏面必定是包含一些sql語句的，由於沒有sql語句，那麼如何進行，sql語句有四大句：select 、update、delete、insert，那麼咱們若是在咱們提交的數據中進行過濾是否是可以避免這些問題呢？
因而咱們使用正則就構建以下函數：
PHP代碼
shell
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<?php
function
inject_check(
$sql_str
)
{
return
eregi
(
'select|insert|update|delete|'
|
function
verify_id(
$id
=null)
{
if
(!
$id
) {
exit
(
'沒有提交參數！'
); }
// 是否爲空判斷
elseif
(inject_check(
$id
)) {
exit
(
'提交的參數非法！'
); }
// 注射判斷
elseif
(!
is_numeric
(
$id
)) {
exit
(
'提交的參數非法！'
); }
// 數字判斷
$id
=
intval
(
$id
);
// 整型化
return
$id
;
}
?>
|
呵呵，那麼咱們就可以進行校驗了，因而咱們上面的程序代碼就變成了下面的：
PHP代碼
數據庫
|
1
2
3
4
5
6
7
8
9
10
11
|
<?php
if
(inject_check(
$_GET
[
'id'
]))
{
exit
(
'你提交的數據非法，請檢查後從新提交！'
);
}
else
{
$id
= verify_id(
$_GET
[
'id'
]);
// 這裏引用了咱們的過濾函數，對$id進行過濾
echo
'提交的數據合法，請繼續！'
;
}
?>
|
好，問題到這裏彷佛都解決了，可是咱們有沒有考慮過post提交的數據，大批量的數據呢？
好比一些字符可能會對數據庫形成危害，好比 ' _ ', ' %'，這些字符都有特殊意義，那麼咱們若是進行控制呢？還有一點，就是當咱們的php.ini裏面的magic_quotes_gpc = off的時候，那麼提交的不符合數據庫規則的數據都是不會自動在前面加' '的，那麼咱們要控制這些問題，因而構建以下函數：
PHP代碼
apache
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<?php
function
str_check(
$str
)
{
if
(!get_magic_quotes_gpc())
// 判斷magic_quotes_gpc是否打開
{
$str
=
addslashes
(
$str
);
// 進行過濾
}
$str
=
str_replace
(
"_"
,
"\_"
,
$str
);
// 把 '_'過濾掉
$str
=
str_replace
(
"%"
,
"\%"
,
$str
);
// 把' % '過濾掉
return
$str
;
}
?>
|
咱們又一次的避免了服務器被淪陷的危險。
最後，再考慮提交一些大批量數據的狀況，好比發貼，或者寫文章、新聞，咱們須要一些函數來幫咱們過濾和進行轉換，再上面函數的基礎上，咱們構建以下函數：
PHP代碼
安全
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
<?php
function
post_check(
$post
)
{
if
(!get_magic_quotes_gpc())
// 判斷magic_quotes_gpc是否爲打開
{
$post
=
addslashes
(
$post
);
// 進行magic_quotes_gpc沒有打開的狀況對提交數據的過濾
}
$post
=
str_replace
(
"_"
,
"\_"
,
$post
);
// 把 '_'過濾掉
$post
=
str_replace
(
"%"
,
"\%"
,
$post
);
// 把' % '過濾掉
$post
=
nl2br
(
$post
);
// 回車轉換
$post
= htmlspecialchars(
$post
);
// html標記轉換
return
$post
;
}
?>
|
呵呵，基本到這裏，咱們把一些狀況都說了一遍，其實我以爲本身講的東西還不多，至少我才只講了兩方面，再整個安全中是不多的內容了，考慮下一次講更多，包括php安全配置，apache安全等等，讓咱們的安全正的是一個總體，做到最安全。
最後在告訴你上面表達的：1. 初始化你的變量 2. 必定記得要過濾你的變量
一個是沒有對輸入的數據進行過濾（過濾輸入），還有一個是沒有對發送到數據庫的數據進行轉義（轉義輸出）。這兩個重要的步驟缺一不可，須要同時加以特別關注以減小程序錯誤。
對於攻擊者來講，進行SQL注入攻擊須要思考和試驗，對數據庫方案進行有根有據的推理很是有必要（固然假設攻擊者看不到你的源程序和數據庫方案），考慮如下簡單的登陸表單：
<form action="/login.php" method="POST">
<p>Username: <input type="text" name="username" /></p>
<p>Password: <input type="password" name="password" /></p>
<p><input type="submit" value="Log In" /></p>
</form>
做爲一個攻擊者，他會從推測驗證用戶名和密碼的查詢語句開始。經過查看源文件，他就能開始猜想你的習慣。
好比命名習慣。一般會假設你表單中的字段名爲與數據表中的字段名相同。固然，確保它們不一樣未必是一個可靠的安全措施。
第一次猜想，通常會使用下面例子中的查詢：
<?php
$password_hash = md5($_POST['password']);
$sql = "SELECT count(*)
FROM users
WHERE username = '{$_POST['username']}'
AND password = '$password_hash'";
?>
使用用戶密碼的MD5值原來是一個通行的作法，但如今並非特別安全了。最近的研究代表MD5算法有缺陷，並且大量MD5數據庫下降了MD5反向破解的難度。請訪問http://md5.rednoize.com/ 查看演示（原文如此，山東大學教授王小云的研究代表能夠很快的找到MD5的「碰撞」，就是能夠產生相同的MD5值的不一樣兩個文件和字串。MD5是信息摘要算法，而不是加密算法，反向破解也就無從談起了。不過根據這個成果，在上面的特例中，直接使用md5是危險的。）。
最好的保護方法是在密碼上附加一個你本身定義的字符串，例如：
<?php
$salt = 'SHIFLETT';
$password_hash = md5($salt . md5($_POST['password'] . $salt));
?>
固然，攻擊者未必在第一次就能猜中，他們經常還須要作一些試驗。有一個比較好的試驗方式是把單引號做爲用戶名錄入，緣由是這樣可能會暴露一些重要信息。有不少開發人員在Mysql語句執行出錯時會調用函數mysql_error()來報告錯誤。見下面的例子：
<?php
mysql_query($sql) or exit(mysql_error());
?>
雖然該方法在開發中十分有用，但它能向攻擊者暴露重要信息。若是攻擊者把單引號作爲用戶名，mypass作爲密碼，查詢語句就會變成：
<?php
$sql = "SELECT *
FROM users
WHERE username = '''
AND password = 'a029d0df84eb5549c641e04a9ef389e5'";
?>
當該語句發送到MySQL後，系統就會顯示以下錯誤信息：
You have an error in your SQL syntax. Check the manual that corresponds to your
MySQL server version for the right syntax to use near 'WHERE username = ''' AND
password = 'a029d0df84eb55
不費吹灰之力，攻擊者已經知道了兩個字段名(username和password)以及他們出如今查詢中的順序。除此之外，攻擊者還知道了數據沒有正確進行過濾（程序沒有提示非法用戶名）和轉義（出現了數據庫錯誤），同時整個WHERE條件的格式也暴露了，這樣，攻擊者就能夠嘗試操縱符合查詢的記錄了。
在這一點上，攻擊者有不少選擇。一是嘗試填入一個特殊的用戶名，以使查詢不管用戶名密碼是否符合，都能獲得匹配：
myuser' or 'foo' = 'foo' --
假定將mypass做爲密碼，整個查詢就會變成：
<?php
$sql = "SELECT *
FROM users
WHERE username = 'myuser' or 'foo' = 'foo' --
AND password = 'a029d0df84eb5549c641e04a9ef389e5'";
?>
幸運的是，SQL注入是很容易避免的。正如前面所說起的，你必須堅持過濾輸入和轉義輸出。
雖然兩個步驟都不能省略，但只要實現其中的一個就能消除大多數的SQL注入風險。若是你只是過濾輸入而沒有轉義輸出，你極可能會遇到數據庫錯誤（合法的數據也可能影響SQL查詢的正確格式），但這也不可靠，合法的數據還可能改變SQL語句的行爲。另外一方面，若是你轉義了輸出，而沒有過濾輸入，就能保證數據不會影響SQL語句的格式，同時也防止了多種常見SQL注入攻擊的方法。
固然，仍是要堅持同時使用這兩個步驟。過濾輸入的方式徹底取決於輸入數據的類型（見第一章的示例），但轉義用於向數據庫發送的輸出數據只要使用同一個函數便可。對於MySQL用戶，可使用函數mysql_real_escape_string( )：
<?php
$clean = array();
$mysql = array();
$clean['last_name'] = "O'Reilly";
$mysql['last_name'] = mysql_real_escape_string($clean['last_name']);
$sql = "INSERT
INTO user (last_name)
VALUES ('{$mysql['last_name']}')";
?>
儘可能使用爲你的數據庫設計的轉義函數。若是沒有，使用函數addslashes()是最終的比較好的方法。
當全部用於創建一個SQL語句的數據被正確過濾和轉義時，實際上也就避免了SQL注入的風險。若是你正在使用支持參數化查詢語句和佔位符的數據庫操做類（如PEAR::DB, PDO等），你就會多獲得一層保護。見下面的使用PEAR::DB的例子：
<?php
$sql = 'INSERT
INTO user (last_name)
VALUES (?)';
$dbh->query($sql, array($clean['last_name']));
?>
因爲在上例中數據不能直接影響查詢語句的格式，SQL注入的風險就下降了。PEAR::DB會自動根據你的數據庫的要求進行轉義，因此你只須要過濾輸出便可。若是你正在使用參數化查詢語句，輸入的內容就只會做爲數據來處理。這樣就沒有必要進行轉義了，儘管你可能認爲這是必要的一步（若是你但願堅持轉義輸出習慣的話）。實際上，這時是否轉義基本上不會產生影響，由於這時沒有特殊字符須要轉換。在防止SQL注入這一點上，參數化查詢語句爲你的程序提供了強大的保護。注：關於SQL注入，不得不說的是如今大多虛擬主機都會把magic_quotes_gpc選項打開，在這種狀況下全部的客戶端GET和POST的數據都會自動進行addslashes處理，因此此時對字符串值的SQL注入是不可行的，但要防止對數字值的SQL注入，如用intval()等函數進行處理。但若是你編寫的是通用軟件，則須要讀取服務器的magic_quotes_gpc後進行相應處理。
- 1. PHP+Mysql防止SQL注入的方法
- 2. PHP+Mysql防止SQL注入的方法:
- 3. php--防止sql注入的方法
- 4. PHP防止SQL注入方法
- 5. PHP最全防止sql注入方法
- 6. PHP防止SQL注入
- 7. PHP PDO 防止SQL注入
- 8. php中防止SQL注入的最好方法是什麼?
- 9. 轉：php中防止SQL注入的方法
- 10. 轉：PHP中防止SQL注入的方法
- 更多相關文章...
- • Spring DI（依賴注入）的實現方式：屬性注入和構造注入 - Spring教程
- • SQLite 注入 - SQLite教程
- • C# 中 foreach 遍歷的用法
- • SpringBoot中properties文件不能自動提示解決方法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. PHP+Mysql防止SQL注入的方法
- 2. PHP+Mysql防止SQL注入的方法:
- 3. php--防止sql注入的方法
- 4. PHP防止SQL注入方法
- 5. PHP最全防止sql注入方法
- 6. PHP防止SQL注入
- 7. PHP PDO 防止SQL注入
- 8. php中防止SQL注入的最好方法是什麼?
- 9. 轉：php中防止SQL注入的方法
- 10. 轉：PHP中防止SQL注入的方法