|
先來說說安全問題,我們首先看一下兩篇文章:
http://www.xfocus.NET/articles/200107/227.html
http://www.xfocus.NET/articles/200107/228.html
上面文章是安全焦點上的關于php安全的文章,基本上比較全面的介紹了關于php的一些安全問題。
在php編碼的時候,如果考慮到一些比較基本的安全問題,首先一點:
1. 初始化你的變量
為什么這么說呢?我們看下面的代碼:
if ($admin)
{
echo '登陸成功!';
include('admin.php');
}
else
{
echo '你不是管理員,無法進行管理!';
}
好,我們看上面的代碼好像是能正常運行,沒有問題,那么加入我提交一個非法的參數過去呢,那么效果會如何呢?比如我們的這個頁是 http://www.traget.com/login.php,那么我們提交:http://www.target.com/login.php?admin=1,呵呵,你想一些,我們是不是直接就是管理員了,直接進行管理。
當然,可能我們不會犯這么簡單錯的錯誤,那么一些很隱秘的錯誤也可能導致這個問題,比如最近暴出來的phpwind 1.3.6論壇有個漏洞,導致能夠直接拿到管理員權限,就是因為有個$skin變量沒有初始化,導致了后面一系列問題。
那么我們如何避免上面的問題呢?首先,從php.ini入手,把php.ini里面的register_global = off,就是不是所有的注冊變量為全局,那么就能避免了。但是,我們不是服務器管理員,只能從代碼上改進了,那么我們如何改進上面的代碼呢?我們改寫如 下:
$admin = 0; // 初始化變量
if ($_POST['admin_user'] && $_POST['admin_pass'])
{
// 判斷提交的管理員用戶名和密碼是不是對的相應的處理代碼
// ...
$admin = 1;
}
else
{
$admin = 0;
}
if ($admin)
{
echo '登陸成功!';
include('admin.php');
}
else
{
echo '你不是管理員,無法進行管理!';
}
那么這時候你再提交 http://www.target.com/login.php?admin=1 就不好使了,因為我們在一開始就把變量初始化為 $admin = 0 了,那么你就無法通過這個漏洞獲取管理員權限。
2. 防止SQL Injection (sql注射)
SQL 注射應該是目前程序危害最大的了,包括最早從ASP到php,基本上都是國內這兩年流行的技術,基本原理就是通過對提交變量的不過濾形成注入點然后使惡意用戶能夠提交一些sql查詢語句,導致重要數據被竊取、數據丟失或者損壞,或者被入侵到后臺管理。
基本原理我就不說了,我們看看下面兩篇文章就很明白了:
http://www.4ngel.NET/article/36.htm
http://www.4ngel.NET/article/30.htm
那么我們既然了解了基本的注射入侵的方式,那么我們如何去防范呢?這個就應該我們從代碼去入手了。
我們知道Web上提交數據有兩種方式,一種是get、一種是post,那么很多常見的sql注射就是從get方式入手的,而且注射的語句里面一定是包含一些sql語句的,因為沒有sql語句,那么如何進行,sql語句有四大句:
select 、update、delete、insert,那么我們如果在我們提交的數據中進行過濾是不是能夠避免這些問題呢?
于是我們使用正則就構建如下函數:
/*
函數名稱:inject_check()
函數作用:檢測提交的值是不是含有SQL注射的字符,防止注射,保護服務器安全
參 數:$sql_str: 提交的變量
返 回 值:返回檢測結果,ture or false
函數作者:heiyeluren
*/
function inject_check($sql_str)
{
return eregi('select|insert|update|delete|'|/*|*|../|./|union|into|load_file|outfile', $sql_str); // 進行過濾
}
我們函數里把 select,insert,update,delete, union, into, load_file, outfile /*, ./ , ../ , ' 等等危險的參數字符串全部過濾掉,那么就能夠控制提交的參數了,程序可以這么構建:
if (inject_check($_GET['id']))
{
exit('你提交的數據非法,請檢查后重新提交!');
}
else
{
$id = $_GET['id'];
echo '提交的數據合法,請繼續!';
}
?>
假設我們提交URL為:http://www.target.com/a.php?id=1,那么就會提示:
"提交的數據合法,請繼續!"
如果我們提交 http://www.target.com/a.php?id=1' select * from tb_name
就會出現提示:"你提交的數據非法,請檢查后重新提交!"
那么就達到了我們的要求。
但是,問題還沒有解決,假如我們提交的是 http://www.target.com/a.php?id=1asdfasdfasdf 呢,我們這個是符合上面的規則的,但是呢,它是不符合要求的,于是我們為了可能其他的情況,我們再構建一個函數來進行檢查:
/*
函數名稱:verify_id()
函數作用:校驗提交的ID類值是否合法
參 數:$id: 提交的ID值
返 回 值:返回處理后的ID
函數作者:heiyeluren
*/
function verify_id($id=null)
{
if (!$id) { exit('沒有提交參數!'); } // 是否為空判斷
elseif (inject_check($id)) { exit('提交的參數非法!'); } // 注射判斷
elseif (!is_numeric($id)) { exit('提交的參數非法!'); } // 數字判斷
$id = intval($id); // 整型化
return $id;
}
呵呵,那么我們就能夠進行校驗了,于是我們上面的程序代碼就變成了下面的:
if (inject_check($_GET['id']))
{
exit('你提交的數據非法,請檢查后重新提交!');
}
else
{
$id = verify_id($_GET['id']); // 這里引用了我們的過濾函數,對$id進行過濾
echo '提交的數據合法,請繼續!';
}
?>
好,問題到這里似乎都解決了,但是我們有沒有考慮過post提交的數據,大批量的數據呢?
比如一些字符可能會對數據庫造成危害,比如 ' _ ', ' % ',這些字符都有特殊意義,那么我們如果進行控制呢?還有一點,就是當我們的php.ini里面的magic_quotes_gpc = off 的時候,那么提交的不符合數據庫規則的數據都是不會自動在前面加' '的,那么我們要控制這些問題,于是構建如下函數:
/*
函數名稱:str_check()
函數作用:對提交的字符串進行過濾
參 數:$var: 要處理的字符串
返 回 值:返回過濾后的字符串
函數作者:heiyeluren
*/
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;
}
OK,我們又一次的避免了服務器被淪陷的危險。
最后,再考慮提交一些大批量數據的情況,比如發貼,或者寫文章、新聞,我們需要一些函數來幫我們過濾和進行轉換,再上面函數的基礎上,我們構建如下函數:
/*
函數名稱:post_check()
函數作用:對提交的編輯內容進行處理
參 數:$post: 要提交的內容
返 回 值:$post: 返回過濾后的內容
函數作者:heiyeluren
*/
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. 一定記得要過濾你的變量
php技術:php xfocus防注入資料,轉載需保留來源!
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯系我們修改或刪除,多謝。