PHP開發安全問題總結

2021-07-05 17:47:39 字數 4642 閱讀 1329

php給了開發者極大的靈活性,但是這也為

問題帶來了潛在的隱患,近期需要總結一下以往的問題,在這裡借翻譯一篇文章同時加上自己開發的一些感觸總結一下。

當開發乙個網際網路服務的時候,必須時刻牢記安全觀念,並在開發的**中體現。php指令碼語言對安全問題並不關心,特別是對大多數沒有經驗的開發者來說。每當你講任何涉及到錢財事務等交易問題時,需要特別注意安全問題的考慮,例如開發乙個論壇或者是乙個購物車等。

。需要在伺服器端進行驗證,對每個php指令碼驗證傳遞到的資料,防止xss攻擊和sql注入

要假設你的**接收的每一條資料都是存在惡意**的,存在隱藏的威脅,要對每一條資料都進行清理

在php.ini檔案中進行以下配置:

register_globals = off
,接收使用者輸入資料的表單可能如下:

提交到process.php,同時對於任何post或get請求引數,都會設定這樣的變數。如果不是顯示進行初始化那麼就會出現下面的問題:

<?php 

// define $authorized = true only if user is authenticated

if (authenticated_user())

?>

此處,假設authenticated_user函式就是判斷$authorized變數的值,如果開啟了register_globals配置,那麼任何使用者都可以傳送乙個請求,來設定$authorized變數的值為任意值從而就能繞過這個驗證。

都應該通過php預定義內建的全域性陣列來獲取,包括$_post、$_get、$_files、$_server、$_request等,其中$_request是乙個$_get/$_post/$_cookie三個陣列的聯合變數,預設的順序是$_cookie、$_post、$_get。

配置選項

error_reporting設定為off:不要暴露錯誤資訊給使用者,開發的時候可以設定為on

safe_mode設定為off

register_globals設定為off

將以下函式禁用:system、exec、passthru、shell_exec、proc_open、popen

open_basedir設定為 /tmp ,這樣可以讓session資訊有儲存許可權,同時設定單獨的**根目錄

設定為off

allow_url_fopen設定為off

allow_url_include設定為off

對於操作

的sql語句,需要特別注意

性,因為使用者可能輸入特定語句使得原有的sql語句改變了功能。類似下面的例子:

$sql = "select * from pinfo where product = '$product'";
此時如果使用者輸入的$product引數為:

39'; drop pinfo; select 'foo
那麼最終sql語句就變成了如下的樣子:

select product from pinfo where product = '39'; drop pinfo; select 'foo'
這樣就會變成三條sql語句,會造成pinfo表被刪除,這樣會造成嚴重的後果。

這個問題可以簡單的使用php的內建函式解決:

$sql = 'select * from pinfo where product = '"' 

mysql_real_escape_string($product) . '"';

防止sql注入攻擊需要做好兩件事:

對輸入的引數總是進行型別驗證

_real_escape_string函式進行轉義

但是,這裡根據開發經驗,不要開啟php的magic quotes,這個特性在php6中已經廢除,總是自己在需要的時候進行轉義。

指令碼在使用者待提交的表單頁面,將使用者提交的資料和cookie偷取過來。

達到保護使用者資料的目的,這裡主要使用的是對使用者的資料進行過濾,一般過濾掉html標籤,特別是a標籤。下面是乙個普通的過濾方法:

function transform_html($string, $length = null) 

return $string;

}

這個函式將html的特殊字元轉換為了html實體,瀏覽器在渲染這段文字的時候以純文字形式顯示。如bold會被顯示為:

boldtext

上述函式的核心就是htmlentities函式,這個函式將html特殊標籤轉換為html實體字元,這樣可以過濾大部分的xss攻擊。

但是對於有經驗的xss攻擊者,有更加巧妙的辦法進行攻擊:將他們的惡意**使用十六進製制或者utf-8編碼,而不是普通的ascii文字,例如可以使用下面的方式進行:

這樣瀏覽器渲染的結果其實是:

的最大長度。

**的方法,也沒有辦法能完全阻止這個情況。

防護的方式:白名單和黑名單。其中白名單更加簡單和有效。

一種白名單解決方案就是safehtml,它足夠智慧型能夠識別有效的html,然後就可以去除任何危險的標籤。這個需要基於htmlsax包來進行解析。

安裝使用safehtml的方法: 

的classes 目錄,這個目錄包含所有的safehtml和htmlsax庫

3、在自己的指令碼中包含safehtml類檔案

4、建立乙個safehtml物件

5、使用parse方法進行過濾

<?php 

/* if you're storing the htmlsax3.php in the /classes directory, along

with the safehtml.php script, define xml_htmlsax3 as a null string. */

define(xml_htmlsax3, '');

// include the class file.

require_once('classes/safehtml.php');

// define some sample bad code.

$data = "this data would raise an alert";

// create a safehtml object.

$safehtml = new safehtml();

// parse and sanitize the data.

$safe_data = $safehtml->parse($data);

// display result.

echo 'the sanitized data is

' . $safe_data;

?>

safehtml並不能完全防止xss攻擊,只是乙個相對複雜的指令碼來檢驗的方式。

單向hash加密保證對每個使用者的密碼都是唯一的,而且不能被破譯的,只有終端使用者知道密碼,系統也是不知道原始密碼的。這樣的乙個好處是在系統被攻擊後攻擊者也無法知道原始密碼資料。

加密和hash是不同的兩個過程。與加密不同,hash是無法被解密的,是單向的;同時兩個不同的字串可能會得到同乙個hash值,並不能保證hash值的唯一性。

md5函式處理過的hash值基本不能被破解,但是總是有可能性的,而且網上也有md5的hash字典。

使用mcrypt加密資料

md5 hash函式可以在可讀的表單中顯示資料,但是對於儲存使用者的信用卡資訊的時候,需要進行加密處理後儲存,並且需要之後進行解密。

<?php 

$data = "stuff you want encrypted";

$key = "secret passphrase used to encrypt your data";

$cipher = "mcrypt_serpent_256";

$mode = "mcrypt_mode_cbc";

function encrypt($data, $key, $cipher, $mode)

function decrypt($data, $key, $cipher, $mode)

?>

mcrypt函式需要以下資訊:

1、待加密資料

2、用來加密和解密資料的key

3、使用者選擇的加密資料的特定演算法(cipher:如 mcrypt_twofish192,mcrypt_serpent_256, mcrypt_rc2, mcrypt_des, and mcrypt_loki97)

4、用來加密的模式

5、加密的種子,用來起始加密過程的資料,是乙個額外的二進位制資料用來初始化加密演算法

6、加密key和種子的長度,使用mcrypt_get_key_size函式和mcrypt_get_block_size函式可以獲取

欄位中會引起其他錯誤,使用了base64encode將這些資料轉換為了十六進製制數方便儲存。

參考文獻:

PHP開發安全問題總結

簡介 當開發乙個網際網路服務的時候,必須時刻牢記安全觀念,並在開發的 中體現。php指令碼語言對安全問題並不關心,特別是對大多數沒有經驗的開發者來說。每當你講任何涉及到錢財事務等交易問題時,需要特別注意安全問題的考慮,例如開發乙個論壇或者是乙個購物車等。需要在伺服器端進行驗證,對每個php指令碼驗證...

php 安全問題

做web開發,相信搭建都知道一些安全基本知識,千萬不能相信客戶端資料 而php又是一種弱型別語言。很多人在開發過程中忽略了型別轉換,引數過濾直接量成不可估量的後果。不使用過濾函式可能出現以下情況 資料庫被 sql 注入。直接可以導致你的系統崩潰,系統資料丟失,使用者資訊丟失。被掛馬,遇到檔案處理則可...

PHP弱型別安全問題總結

前段時間做了南京郵電大學網路攻防平台上面的題目,寫了乙個writeup之後,還有必要總結一下。由於做的題目都是web型別的,所有的題目都是使用php來寫的,所以很多題目並沒有考察到傳統的如sql注入,xss的型別的漏洞,很多都是php本身語法的問題。鑑於目前php是世界上最好的語言,php本身的問題...