PHP安全性漫談
更新時間：2012年06月28日 15:45:04 作者：
本文所討論的安全性環(huán)境是在Linux+Apache+Mysql+PHP。超出此范圍的安全性問題不在本文范疇之內(nèi)
一、apache server安全性設(shè)置
1、以Nobody用戶運行
一般情況下，Apache是由Root 來安裝和運行的。如果Apache Server進程具有Root用戶特權(quán)，那么它將給系統(tǒng)的安全構(gòu)成很大的威脅，應(yīng)確保Apache Server進程以最可能低的權(quán)限用戶來運行。通過修改httpd.conf文件中的下列選項，以Nobody用戶運行Apache 達到相對安全的目的。
User nobody
Group# -1
2、ServerRoot目錄的權(quán)限
為了確保所有的配置是適當(dāng)?shù)暮桶踩?，需要嚴格控制Apache 主目錄的訪問權(quán)限，使非超級用戶不能修改該目錄中的內(nèi)容。Apache 的主目錄對應(yīng)于Apache Server配置文件httpd.conf的Server Root控制項中，應(yīng)為：
Server Root /usr/local/apache
3、SSI的配置
在配置文件access.conf 或httpd.conf中的確Options指令處加入Includes NO EXEC選項，用以禁用Apache Server 中的執(zhí)行功能。避免用戶直接執(zhí)行Apache 服務(wù)器中的執(zhí)行程序，而造成服務(wù)器系統(tǒng)的公開化。
Options Includes Noexec
4、阻止用戶修改系統(tǒng)設(shè)置
在Apache 服務(wù)器的配置文件中進行以下的設(shè)置，阻止用戶建立、修改 .htaccess文件，防止用戶超越能定義的系統(tǒng)安全特性。
AllowOveride None
Options None
Allow from all
然后再分別對特定的目錄進行適當(dāng)?shù)呐渲谩?
5、改變Apache 服務(wù)器的缺省訪問特性
Apache 的默認設(shè)置只能保障一定程度的安全，如果服務(wù)器能夠通過正常的映射規(guī)則找到文件，那么客戶端便會獲取該文件，如http://local host/~ root/ 將允許用戶訪問整個文件系統(tǒng)。在服務(wù)器文件中加入如下內(nèi)容：
order deny,ellow
Deny from all
將禁止對文件系統(tǒng)的缺省訪問。
6、CGI腳本的安全考慮
CGI腳本是一系列可以通過Web服務(wù)器來運行的程序。為了保證系統(tǒng)的安全性，應(yīng)確保CGI的作者是可信的。對CGI而言，最好將其限制在一個特定的目 錄下，如cgi-bin之下，便于管理；另外應(yīng)該保證CGI目錄下的文件是不可寫的，避免一些欺騙性的程序駐留或混跡其中；如果能夠給用戶提供一個安全性 良好的CGI程序的模塊作為參考，也許會減少許多不必要的麻煩和安全隱患；除去CGI目錄下的所有非業(yè)務(wù)應(yīng)用的腳本，以防異常的信息泄漏。
7、SSL鏈接加密
以上這些常用的舉措可以給Apache Server 一個基本的安全運行環(huán)境，顯然在具體實施上還要做進一步的細化分解，制定出符合實際應(yīng)用的安全配置方案。
二、PHP安全性設(shè)置
服務(wù)器并不能阻止所有的安全問題，例如程序漏洞問題、用戶輸入表單問題、PHP文件權(quán)限問題等。
也可以通過一些手段來迷惑黑客或者別有用心者。
1、程序代碼漏洞問題
很多 PHP 程序所存在的重大弱點并不是 PHP 語言本身的問題，而是編程者的安全意識不高而導(dǎo)致的。因此，必須時時注意每一段代碼可能存在的問題，去發(fā)現(xiàn)非正確數(shù)據(jù)提交時可能造成的影響。
<?php
unlink ($evil_var);
fwrite ($fp, $evil_var);
system ($evil_var);
exec ($evil_var);
?>
必須時常留意你的代碼，以確保每一個從客戶端提交的變量都經(jīng)過適當(dāng)?shù)臋z查，然后問自己以下一些問題：
此腳本是否只能影響所預(yù)期的文件？
非正常的數(shù)據(jù)被提交后能否產(chǎn)生作用？
此腳本能用于計劃外的用途嗎？
此腳本能否和其它腳本結(jié)合起來做壞事？
是否所有的事務(wù)都被充分記錄了？
在寫代碼的時候問自己這些問題，否則以后可能要為了增加安全性而重寫代碼了。注意了這些問題的話，也許還不完全能保證系統(tǒng)的安全，但是至少可以提高安全性。
還可以考慮關(guān)閉 register_globals，magic_quotes 或者其它使編程更方便但會使某個變量的合法性，來源和其值被搞亂的設(shè)置。
2、用戶輸入表單問題
驗證用戶輸入的任何數(shù)據(jù)，保證PHP代碼的安全。
注意1：JS只是為了提高來訪用戶的體驗而產(chǎn)生的，而不是驗證的工具。因為任何一個來訪的用戶都可能會，也有可能無意間就禁用了客戶端腳本的執(zhí)行，從而跳過這層驗證。所以我們必須在PHP的服務(wù)器端程序上檢驗這些數(shù)據(jù)。
注意2：不要使用$_SERVER['HTTP_REFERER']這個超級變量來檢查數(shù)據(jù)的來源地址，一個很小的菜鳥黑客都會利用工具來偽造這個變量的數(shù)據(jù)，盡可能利用Md5，或者rand等函數(shù)來產(chǎn)生一個令牌，驗證來源的時候，驗證這個令牌是否匹配。
3、PHP文件權(quán)限問題
PHP 被設(shè)計為以用戶級別來訪問文件系統(tǒng)，所以完全有可能通過編寫一段 PHP 代碼來讀取系統(tǒng)文件如 /etc/passwd，更改網(wǎng)絡(luò)連接以及發(fā)送大量打印任務(wù)等等。因此必須確保 PHP 代碼讀取和寫入的是合適的文件。 請看下面的代碼，用戶想要刪除自己主目錄中的一個文件。假設(shè)此情形是通過 web 界面來管理文件系統(tǒng)，因此 Apache 用戶有權(quán)刪除用戶目錄下的文件。
<?php
$username = $_POST['user_submitted_name'];
$homedir = "/home/$username";
$file_to_delete = "$userfile";
unlink ("$homedir/$userfile");
echo "$file_to_delete has been deleted!";
?>
既然 username 變量可以通過用戶表單來提交，那就可以提交別人的用戶名和文件名，并刪除該文件。這種情況下，就要考慮其它方式的認證：
只給 PHP 的 web 用戶很有限的權(quán)限。
檢查所有提交上來的變量。
以下是更加安全的文件名和變量的驗證和檢查：
<?php
$username = $_SERVER['REMOTE_USER'];
$homedir = "/home/$username";
if (!ereg('^[^./][^/]*$', $userfile))
die('bad filename');
if (!ereg('^[^./][^/]*$', $username))
die('bad username');
?>
4、隱藏PHP擴展名
一般而言，通過隱藏的手段提高安全性被認為是作用不大的做法。但某些情況下，盡可能的多增加一份安全性都是值得的。
一些簡單的方法可以幫助隱藏 PHP，這樣做可以提高攻擊者發(fā)現(xiàn)系統(tǒng)弱點的難度。在 php.ini 文件里設(shè)置 expose_php = off ，可以減少他們能獲得的有用信息。
另一個策略就是讓 web 服務(wù)器用 PHP 解析不同擴展名。無論是通過 .htaccess 文件還是 Apache 的配置文件，都可以設(shè)置能誤導(dǎo)攻擊者的文件擴展名：
# 使PHP看上去像其它的編程語言
AddType application/x-httpd-php .asp .py .pl
# 使 PHP 看上去像未知的文件類型
AddType application/x-httpd-php .bop .foo .133t
# 使 PHP 代碼看上去像 HTML 頁面
AddType application/x-httpd-php .htm .html
要讓此方法生效，必須把 PHP 文件的擴展名改為以上的擴展名。這樣就通過隱藏來提高了安全性，雖然防御能力很低而且有些缺點。
三、Mysql數(shù)據(jù)庫安全性設(shè)置
PHP 本身并不能保護數(shù)據(jù)庫的安全。下面的章節(jié)只是講述怎樣用 PHP 腳本對數(shù)據(jù)庫進行基本的訪問和操作。記住一條簡單的原則：深入防御。保護數(shù)據(jù)庫的措施越多，攻擊者就越難獲得和使用數(shù)據(jù)庫內(nèi)的信息。正確地設(shè)計和應(yīng)用數(shù)據(jù)庫可以減少被攻擊的擔(dān)憂。
1、數(shù)據(jù)庫設(shè)計問題
應(yīng)用程序永遠不要使用數(shù)據(jù)庫所有者或超級用戶帳號來連接數(shù)據(jù)庫，因為這些帳號可以執(zhí)行任意的操作，比如說修改數(shù)據(jù)庫結(jié)構(gòu)（例如刪除一個表）或者清空整個數(shù)據(jù)庫的內(nèi)容。以下截圖的用戶設(shè)置是危險的。
應(yīng)該為程序的每個方面創(chuàng)建不同的數(shù)據(jù)庫帳號，并賦予對數(shù)據(jù)庫對象的極有限的權(quán)限。僅分配給能完成其功能所需的權(quán)限，避免同一個用戶可以完成另一個用戶的事情。這樣即使攻擊者利用程序漏洞取得了數(shù)據(jù)庫的訪問權(quán)限，也最多只能做到和該程序一樣的影響范圍。
2.數(shù)據(jù)庫連接問題
把連接建立在 SSL 加密技術(shù)上可以增加客戶端和服務(wù)器端通信的安全性，或者 SSH 也可以用于加密客戶端和數(shù)據(jù)庫之間的連接。如果使用了這些技術(shù)的話，攻擊者要監(jiān)視服務(wù)器的通信或者得到數(shù)據(jù)庫的信息是很困難的。
3.數(shù)據(jù)庫數(shù)據(jù)的加密
SSL/SSH 能保護客戶端和服務(wù)器端交換的數(shù)據(jù)，但 SSL/SSH 并不能保護數(shù)據(jù)庫中已有的數(shù)據(jù)。SSL 只是一個加密網(wǎng)絡(luò)數(shù)據(jù)流的協(xié)議。
如果攻擊者取得了直接訪問數(shù)據(jù)庫的許可（繞過 web 服務(wù)器），敏感數(shù)據(jù)就可能暴露或者被濫用，除非數(shù)據(jù)庫自己保護了這些信息。對數(shù)據(jù)庫內(nèi)的數(shù)據(jù)加密是減少這類風(fēng)險的有效途徑，但是只有很少的數(shù)據(jù)庫提供這些加密功能。
對于這個問題，有一個簡單的解決辦法，就是創(chuàng)建自己的加密機制，然后把它用在 PHP 程序內(nèi)，最常見的例子就是把密碼經(jīng)過 MD5 加密后的散列存進數(shù)據(jù)庫來代替原來的明文密碼。
<?php
$query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
addslashes($username), md5($password));
$result = pg_query($connection, $query);
$query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
addslashes($username), md5($password));
$result = pg_query($connection, $query);
if (pg_num_rows($result) > 0) {
echo 'Welcome, $username!';
} else {
echo 'Authentication failed for $username.';
}
?>
4、SQL注入問題
直接 SQL 命令注入就是攻擊者常用的一種創(chuàng)建或修改已有 SQL 語句的技術(shù)，從而達到取得隱藏數(shù)據(jù)，或覆蓋關(guān)鍵的值，甚至執(zhí)行數(shù)據(jù)庫主機操作系統(tǒng)命令的目的。這是通過應(yīng)用程序取得用戶輸入并與靜態(tài)參數(shù)組合成 SQL 查詢來實現(xiàn)的。下面將會給出一些真實的例子。
<?php
$query = "SELECT id, name, inserted, size FROM products
WHERE size = '$size'
ORDER BY $order LIMIT $limit, $offset;";
$result = odbc_exec($conn, $query);
?>
可以在原來的查詢的基礎(chǔ)上添加另一個 SELECT 查詢來獲得密碼：
union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;
假如上述語句（使用 ' 和 --）被加入到 $query 中的任意一個變量的話，那么就麻煩了。
這些攻擊總是建立在發(fā)掘安全意識不強的代碼上的。所以，永遠不要信任外界輸入的數(shù)據(jù)，特別是來自于客戶端的，包括選擇框、表單隱藏域和 cookie。就如上面的第一個例子那樣，就算是正常的查詢也有可能造成災(zāi)難。
永遠不要使用超級用戶或所有者帳號去連接數(shù)據(jù)庫。要用權(quán)限被嚴格限制的帳號。
檢查輸入的數(shù)據(jù)是否具有所期望的數(shù)據(jù)格式。PHP 有很多可以用于檢查輸入的函數(shù)，從簡單的變量函數(shù)和字符類型函數(shù)（比如 is_numeric()，ctype_digit()）到復(fù)雜的 Perl 兼容正則表達式函數(shù)都可以完成這個工作。
如果程序等待輸入一個數(shù)字，可以考慮使用 is_numeric() 來檢查，或者直接使用 settype() 來轉(zhuǎn)換它的類型，也可以用 sprintf() 把它格式化為數(shù)字。
一個更安全的防止SQL注入的分頁顯示方法：
<?php
settype($offset, 'integer');
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
$query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",
$offset);
?>
1、以Nobody用戶運行
一般情況下，Apache是由Root 來安裝和運行的。如果Apache Server進程具有Root用戶特權(quán)，那么它將給系統(tǒng)的安全構(gòu)成很大的威脅，應(yīng)確保Apache Server進程以最可能低的權(quán)限用戶來運行。通過修改httpd.conf文件中的下列選項，以Nobody用戶運行Apache 達到相對安全的目的。
User nobody
Group# -1
2、ServerRoot目錄的權(quán)限
為了確保所有的配置是適當(dāng)?shù)暮桶踩?，需要嚴格控制Apache 主目錄的訪問權(quán)限，使非超級用戶不能修改該目錄中的內(nèi)容。Apache 的主目錄對應(yīng)于Apache Server配置文件httpd.conf的Server Root控制項中，應(yīng)為：
Server Root /usr/local/apache
3、SSI的配置
在配置文件access.conf 或httpd.conf中的確Options指令處加入Includes NO EXEC選項，用以禁用Apache Server 中的執(zhí)行功能。避免用戶直接執(zhí)行Apache 服務(wù)器中的執(zhí)行程序，而造成服務(wù)器系統(tǒng)的公開化。
Options Includes Noexec
4、阻止用戶修改系統(tǒng)設(shè)置
在Apache 服務(wù)器的配置文件中進行以下的設(shè)置，阻止用戶建立、修改 .htaccess文件，防止用戶超越能定義的系統(tǒng)安全特性。
AllowOveride None
Options None
Allow from all
然后再分別對特定的目錄進行適當(dāng)?shù)呐渲谩?
5、改變Apache 服務(wù)器的缺省訪問特性
Apache 的默認設(shè)置只能保障一定程度的安全，如果服務(wù)器能夠通過正常的映射規(guī)則找到文件，那么客戶端便會獲取該文件，如http://local host/~ root/ 將允許用戶訪問整個文件系統(tǒng)。在服務(wù)器文件中加入如下內(nèi)容：
order deny,ellow
Deny from all
將禁止對文件系統(tǒng)的缺省訪問。
6、CGI腳本的安全考慮
CGI腳本是一系列可以通過Web服務(wù)器來運行的程序。為了保證系統(tǒng)的安全性，應(yīng)確保CGI的作者是可信的。對CGI而言，最好將其限制在一個特定的目 錄下，如cgi-bin之下，便于管理；另外應(yīng)該保證CGI目錄下的文件是不可寫的，避免一些欺騙性的程序駐留或混跡其中；如果能夠給用戶提供一個安全性 良好的CGI程序的模塊作為參考，也許會減少許多不必要的麻煩和安全隱患；除去CGI目錄下的所有非業(yè)務(wù)應(yīng)用的腳本，以防異常的信息泄漏。
7、SSL鏈接加密
以上這些常用的舉措可以給Apache Server 一個基本的安全運行環(huán)境，顯然在具體實施上還要做進一步的細化分解，制定出符合實際應(yīng)用的安全配置方案。
二、PHP安全性設(shè)置
服務(wù)器并不能阻止所有的安全問題，例如程序漏洞問題、用戶輸入表單問題、PHP文件權(quán)限問題等。
也可以通過一些手段來迷惑黑客或者別有用心者。
1、程序代碼漏洞問題
很多 PHP 程序所存在的重大弱點并不是 PHP 語言本身的問題，而是編程者的安全意識不高而導(dǎo)致的。因此，必須時時注意每一段代碼可能存在的問題，去發(fā)現(xiàn)非正確數(shù)據(jù)提交時可能造成的影響。
復(fù)制代碼 代碼如下:
<?php
unlink ($evil_var);
fwrite ($fp, $evil_var);
system ($evil_var);
exec ($evil_var);
?>
必須時常留意你的代碼，以確保每一個從客戶端提交的變量都經(jīng)過適當(dāng)?shù)臋z查，然后問自己以下一些問題：
此腳本是否只能影響所預(yù)期的文件？
非正常的數(shù)據(jù)被提交后能否產(chǎn)生作用？
此腳本能用于計劃外的用途嗎？
此腳本能否和其它腳本結(jié)合起來做壞事？
是否所有的事務(wù)都被充分記錄了？
在寫代碼的時候問自己這些問題，否則以后可能要為了增加安全性而重寫代碼了。注意了這些問題的話，也許還不完全能保證系統(tǒng)的安全，但是至少可以提高安全性。
還可以考慮關(guān)閉 register_globals，magic_quotes 或者其它使編程更方便但會使某個變量的合法性，來源和其值被搞亂的設(shè)置。
2、用戶輸入表單問題
驗證用戶輸入的任何數(shù)據(jù)，保證PHP代碼的安全。
注意1：JS只是為了提高來訪用戶的體驗而產(chǎn)生的，而不是驗證的工具。因為任何一個來訪的用戶都可能會，也有可能無意間就禁用了客戶端腳本的執(zhí)行，從而跳過這層驗證。所以我們必須在PHP的服務(wù)器端程序上檢驗這些數(shù)據(jù)。
注意2：不要使用$_SERVER['HTTP_REFERER']這個超級變量來檢查數(shù)據(jù)的來源地址，一個很小的菜鳥黑客都會利用工具來偽造這個變量的數(shù)據(jù)，盡可能利用Md5，或者rand等函數(shù)來產(chǎn)生一個令牌，驗證來源的時候，驗證這個令牌是否匹配。
3、PHP文件權(quán)限問題
PHP 被設(shè)計為以用戶級別來訪問文件系統(tǒng)，所以完全有可能通過編寫一段 PHP 代碼來讀取系統(tǒng)文件如 /etc/passwd，更改網(wǎng)絡(luò)連接以及發(fā)送大量打印任務(wù)等等。因此必須確保 PHP 代碼讀取和寫入的是合適的文件。 請看下面的代碼，用戶想要刪除自己主目錄中的一個文件。假設(shè)此情形是通過 web 界面來管理文件系統(tǒng)，因此 Apache 用戶有權(quán)刪除用戶目錄下的文件。
復(fù)制代碼 代碼如下:
<?php
$username = $_POST['user_submitted_name'];
$homedir = "/home/$username";
$file_to_delete = "$userfile";
unlink ("$homedir/$userfile");
echo "$file_to_delete has been deleted!";
?>
既然 username 變量可以通過用戶表單來提交，那就可以提交別人的用戶名和文件名，并刪除該文件。這種情況下，就要考慮其它方式的認證：
只給 PHP 的 web 用戶很有限的權(quán)限。
檢查所有提交上來的變量。
以下是更加安全的文件名和變量的驗證和檢查：
復(fù)制代碼 代碼如下:
<?php
$username = $_SERVER['REMOTE_USER'];
$homedir = "/home/$username";
if (!ereg('^[^./][^/]*$', $userfile))
die('bad filename');
if (!ereg('^[^./][^/]*$', $username))
die('bad username');
?>
4、隱藏PHP擴展名
一般而言，通過隱藏的手段提高安全性被認為是作用不大的做法。但某些情況下，盡可能的多增加一份安全性都是值得的。
一些簡單的方法可以幫助隱藏 PHP，這樣做可以提高攻擊者發(fā)現(xiàn)系統(tǒng)弱點的難度。在 php.ini 文件里設(shè)置 expose_php = off ，可以減少他們能獲得的有用信息。
另一個策略就是讓 web 服務(wù)器用 PHP 解析不同擴展名。無論是通過 .htaccess 文件還是 Apache 的配置文件，都可以設(shè)置能誤導(dǎo)攻擊者的文件擴展名：
# 使PHP看上去像其它的編程語言
AddType application/x-httpd-php .asp .py .pl
# 使 PHP 看上去像未知的文件類型
AddType application/x-httpd-php .bop .foo .133t
# 使 PHP 代碼看上去像 HTML 頁面
AddType application/x-httpd-php .htm .html
要讓此方法生效，必須把 PHP 文件的擴展名改為以上的擴展名。這樣就通過隱藏來提高了安全性，雖然防御能力很低而且有些缺點。
三、Mysql數(shù)據(jù)庫安全性設(shè)置
PHP 本身并不能保護數(shù)據(jù)庫的安全。下面的章節(jié)只是講述怎樣用 PHP 腳本對數(shù)據(jù)庫進行基本的訪問和操作。記住一條簡單的原則：深入防御。保護數(shù)據(jù)庫的措施越多，攻擊者就越難獲得和使用數(shù)據(jù)庫內(nèi)的信息。正確地設(shè)計和應(yīng)用數(shù)據(jù)庫可以減少被攻擊的擔(dān)憂。
1、數(shù)據(jù)庫設(shè)計問題
應(yīng)用程序永遠不要使用數(shù)據(jù)庫所有者或超級用戶帳號來連接數(shù)據(jù)庫，因為這些帳號可以執(zhí)行任意的操作，比如說修改數(shù)據(jù)庫結(jié)構(gòu)（例如刪除一個表）或者清空整個數(shù)據(jù)庫的內(nèi)容。以下截圖的用戶設(shè)置是危險的。
2.數(shù)據(jù)庫連接問題
把連接建立在 SSL 加密技術(shù)上可以增加客戶端和服務(wù)器端通信的安全性，或者 SSH 也可以用于加密客戶端和數(shù)據(jù)庫之間的連接。如果使用了這些技術(shù)的話，攻擊者要監(jiān)視服務(wù)器的通信或者得到數(shù)據(jù)庫的信息是很困難的。
3.數(shù)據(jù)庫數(shù)據(jù)的加密
SSL/SSH 能保護客戶端和服務(wù)器端交換的數(shù)據(jù)，但 SSL/SSH 并不能保護數(shù)據(jù)庫中已有的數(shù)據(jù)。SSL 只是一個加密網(wǎng)絡(luò)數(shù)據(jù)流的協(xié)議。
如果攻擊者取得了直接訪問數(shù)據(jù)庫的許可（繞過 web 服務(wù)器），敏感數(shù)據(jù)就可能暴露或者被濫用，除非數(shù)據(jù)庫自己保護了這些信息。對數(shù)據(jù)庫內(nèi)的數(shù)據(jù)加密是減少這類風(fēng)險的有效途徑，但是只有很少的數(shù)據(jù)庫提供這些加密功能。
對于這個問題，有一個簡單的解決辦法，就是創(chuàng)建自己的加密機制，然后把它用在 PHP 程序內(nèi)，最常見的例子就是把密碼經(jīng)過 MD5 加密后的散列存進數(shù)據(jù)庫來代替原來的明文密碼。
復(fù)制代碼 代碼如下:
<?php
$query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
addslashes($username), md5($password));
$result = pg_query($connection, $query);
$query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
addslashes($username), md5($password));
$result = pg_query($connection, $query);
if (pg_num_rows($result) > 0) {
echo 'Welcome, $username!';
} else {
echo 'Authentication failed for $username.';
}
?>
4、SQL注入問題
直接 SQL 命令注入就是攻擊者常用的一種創(chuàng)建或修改已有 SQL 語句的技術(shù)，從而達到取得隱藏數(shù)據(jù)，或覆蓋關(guān)鍵的值，甚至執(zhí)行數(shù)據(jù)庫主機操作系統(tǒng)命令的目的。這是通過應(yīng)用程序取得用戶輸入并與靜態(tài)參數(shù)組合成 SQL 查詢來實現(xiàn)的。下面將會給出一些真實的例子。
復(fù)制代碼 代碼如下:
<?php
$query = "SELECT id, name, inserted, size FROM products
WHERE size = '$size'
ORDER BY $order LIMIT $limit, $offset;";
$result = odbc_exec($conn, $query);
?>
可以在原來的查詢的基礎(chǔ)上添加另一個 SELECT 查詢來獲得密碼：
union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;
假如上述語句（使用 ' 和 --）被加入到 $query 中的任意一個變量的話，那么就麻煩了。
這些攻擊總是建立在發(fā)掘安全意識不強的代碼上的。所以，永遠不要信任外界輸入的數(shù)據(jù)，特別是來自于客戶端的，包括選擇框、表單隱藏域和 cookie。就如上面的第一個例子那樣，就算是正常的查詢也有可能造成災(zāi)難。
永遠不要使用超級用戶或所有者帳號去連接數(shù)據(jù)庫。要用權(quán)限被嚴格限制的帳號。
檢查輸入的數(shù)據(jù)是否具有所期望的數(shù)據(jù)格式。PHP 有很多可以用于檢查輸入的函數(shù)，從簡單的變量函數(shù)和字符類型函數(shù)（比如 is_numeric()，ctype_digit()）到復(fù)雜的 Perl 兼容正則表達式函數(shù)都可以完成這個工作。
如果程序等待輸入一個數(shù)字，可以考慮使用 is_numeric() 來檢查，或者直接使用 settype() 來轉(zhuǎn)換它的類型，也可以用 sprintf() 把它格式化為數(shù)字。
一個更安全的防止SQL注入的分頁顯示方法：
復(fù)制代碼 代碼如下:
<?php
settype($offset, 'integer');
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
$query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",
$offset);
?>
相關(guān)文章
在本篇文章里小編給大家整理的是一篇關(guān)于php去除deprecated的實例方法，有興趣的朋友們可以跟著學(xué)習(xí)參考下。2021-10-10
php使用PDO從數(shù)據(jù)庫表中讀取數(shù)據(jù)的實現(xiàn)方法(必看)
下面小編就為大家?guī)硪黄猵hp使用PDO從數(shù)據(jù)庫表中讀取數(shù)據(jù)的實現(xiàn)方法(必看)。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-06-06
PHP的array_diff()函數(shù)在處理大數(shù)組時的效率問題
PHP 5.2.6 以上版本的 array_diff() 函數(shù)在處理大數(shù)組時，需要花費超長時間，這個 bug 已經(jīng)被官方確認；在這個問題被修復(fù)之前或者在我們不能控制 PHP 版本的時候，可以使用本文提供的方法2011-11-11
PHP __autoload函數(shù)（自動載入類文件）的使用方法
在使用PHP的OO模式開發(fā)系統(tǒng)時，通常大家習(xí)慣上將每個類的實現(xiàn)都存放在一個單獨的文件里，這樣會很容易實現(xiàn)對類進行復(fù)用，同時將來維護時也很便利2012-02-02
.htaccess太強大了，但它本身會不會被破解掉呢，請問如何保護它？2011-02-02
Wordpress php 分頁代碼,大家可以參考下。2009-10-10
javascript+php實現(xiàn)根據(jù)用戶時區(qū)顯示當(dāng)?shù)貢r間的方法
這篇文章主要介紹了javascript+php實現(xiàn)根據(jù)用戶時區(qū)顯示當(dāng)?shù)貢r間的方法,實例分析javascript獲取客戶端時區(qū)及與服務(wù)器端php交互的技巧,具有一定參考借鑒價值,需要的朋友可以參考下2015-03-03
PHP中調(diào)用ASP.NET的WebService的代碼
創(chuàng)建一個C#的web service，這個就不多說了，我用vs2008的wizard創(chuàng)建了一個最簡單的，讓它運行在：http://localhost/webservice1/service1.asmx2011-04-04
這篇文章主要介紹了PHP的引用計數(shù)的相關(guān)資料，幫助大家更好的理解和學(xué)習(xí)使用PHP，感興趣的朋友可以了解下2021-04-04
PHP使用自定義key實現(xiàn)對數(shù)據(jù)加密解密的方法
這篇文章主要介紹了PHP使用自定義key實現(xiàn)對數(shù)據(jù)加密解密的方法,涉及php針對字符串的轉(zhuǎn)換、截取等操作實現(xiàn)加密解密功能的相關(guān)技巧,需要的朋友可以參考下2017-12-12