Discuz!基礎(chǔ)的代碼安全和代碼規(guī)范

我是小站長(zhǎng)

變量
所有漏洞都來(lái)源于變量,因此變量首先要做的就是定義初始化。用任何一個(gè)變量前一定要先定義，初始化它
雖然現(xiàn)在Discuz!X來(lái)說(shuō)，GPC不會(huì)被全局覆蓋了，但是大家寫(xiě)插件的過(guò)程中也不要忽視了
因?yàn)樵诜?wù)器php.ini的配置中 global on 時(shí)
所有的GET POST 都會(huì)變成變量
$_GET['xxx']  如果存在
就會(huì)變成 $xxx 而產(chǎn)生在程序里
因此，你自己要用的變量，一定要初始化

第一點(diǎn)，變量的初始化
無(wú)論你要怎么利用變量，一定要初始化
不管是Discuz!還是Discuz!X
由于PHP的歷史原因
你不能相信任何一個(gè)服務(wù)器
只因?yàn)閜hp有個(gè)global on 的參數(shù)
他會(huì)讓GPC變量直接變成全局變量
因此，你自己的變量一定要初始化

第二點(diǎn)，認(rèn)清變量的類型
整剛才說(shuō)到，變量一定要初始化，那么初始化成什么類型
如果你要用于數(shù)組

初始化$a = array();
字串 $a ='';
數(shù)字 $a = 0

這樣子，這里說(shuō)說(shuō)數(shù)組，這里又存在一個(gè)php歷史問(wèn)題，這歷史延續(xù)至今。

$s = '123456';
echo $s[2];
等于什么？

[]大家都知，這是數(shù)組的用法，但php太自由了 $s[3] 的數(shù)組用法，竟然可以用在字串里，這個(gè)在大家認(rèn)為很自然。
但是，很多漏洞會(huì)從此誕生，這就是認(rèn)清自己的變量類型的道理所在。
$s[1] 是數(shù)組的用法，可以用在字串中，但是我不推薦大家用，黑客會(huì)這么用在GET中更改你的變量類型。

舉例
echo $s[2];
簡(jiǎn)單這一句，你認(rèn)為這是輸出數(shù)組的一個(gè)項(xiàng)，還是字串？
大多數(shù)人會(huì)認(rèn)為這明顯是輸出數(shù)組的一個(gè)項(xiàng)目，但是剛才也看到了，它輸出字串的一個(gè)字節(jié)也可以。
那，我們反過(guò)來(lái)思考，如果程序的某邏輯需要輸出字串的某字節(jié)，但是，如果你沒(méi)明確告知變量類型。那么有可能會(huì)讓這一個(gè)字節(jié)變成一個(gè)字串 xxx.php?s[2]=hello

初始化+認(rèn)清自己的變量類型
特別是數(shù)組和字串，如果你要取字串的某一位，安全的方法，可能還是 substr($s, 2, 1)
切忌[]的用法，一定要$a = array() 不要讓他和字串類型的變量產(chǎn)生互用理中

第三點(diǎn)、不要相信任何一個(gè)即將入庫(kù)的變量
進(jìn)很多SQL注入都是從變量開(kāi)始，要仔細(xì)看每一個(gè)SQL語(yǔ)句中可能出現(xiàn)的變量，如，整數(shù)一定要intval；字串一定要addslashes處理，說(shuō)到addslashes，說(shuō)說(shuō)Discuz!的特點(diǎn)，國(guó)外某些論壇是，所有變量都無(wú)需addslashes，addslashes只在SQL數(shù)據(jù)庫(kù)類中統(tǒng)一處理，但Discuz!不是，Discuz!會(huì)統(tǒng)一給GPC變量自動(dòng)addslashes。

注意，是只給GPC變量加addslashes，其他的都沒(méi)加。所以，你要注意兩件事：
1. GPC變量你想用于顯示？
那么別忘記stripslashes 后在顯示，否則萬(wàn)一遇到有帶有 ' 的，那就會(huì)多一個(gè)\，I'm 變成 I\'m
htmlspecial只處理<>這些，和單引號(hào)無(wú)關(guān)

2. 再次，剛才說(shuō)過(guò)DZ只處理GPC。因此，GPC之外的所有變量一定要自己addslashes，特別是有些時(shí)候時(shí)，把A庫(kù)的東西讀出來(lái)后，直接復(fù)制到B庫(kù)的情況。有人說(shuō)A庫(kù)的東西都入進(jìn)去了，直接入B庫(kù)還不安全嗎？這可不一定，I'm 被A讀取出來(lái)后 直接入B庫(kù)，肯定是sql error，必須addslashes。如果要 serialize ，那么 serialize前無(wú)需addslashes，serialize后要，從數(shù)據(jù)庫(kù)中去出來(lái)的肯定是I'm，不是I'\m，serialize是好東西，但不要把a(bǔ)ddslashes后的也給serialize進(jìn)去。

那么，我再繼續(xù)深一步，剛才說(shuō)到了數(shù)據(jù)庫(kù)。
我們保證了入庫(kù)前的所有變量必須是addslashes，但是，如果你不做下面的一件事。那么你再addslashes也是白搭
哪件事呢？
select * from table where id=$id
select * from table where id=I\'m
看，依然sql錯(cuò)誤，而且還被注入

我舉例子
沒(méi)錯(cuò)，單引號(hào)封閉，無(wú)論你是什么類型的字段
在Discuz!的規(guī)范里，必須都加單引號(hào)
select * from table where id='$id'
WHERE后面的所有條件
變量必須加單引號(hào)，這是規(guī)范。也許你少加一個(gè)，并不會(huì)產(chǎn)生漏洞，也只是也許。

但，有些隱形的漏洞就是在七拐八拐中產(chǎn)生的。你少寫(xiě)一個(gè)，那些黑客就會(huì)用七拐八拐的方式去分析，看看可否利用行中。
intval是必須的，規(guī)則也是必須遵守的，然后是html的問(wèn)題，不要漏掉任何一個(gè)字串類型。
所有字串類型，如果你不希望他們顯示html，入庫(kù)前一定要htmlspecialchars后再入庫(kù)，或者strip_tags下

數(shù)字類型
大家都知道intval，字串是htmlspecialchars，當(dāng)然，后臺(tái)無(wú)所謂！后臺(tái)比較安全，但是，最好也有，一個(gè)習(xí)慣，僅作參考。

$a = '12345';
$a_en = htmlspecialchars($a)
$a_ad = addslashes($a);

這樣，入庫(kù)的時(shí)候sql查詢語(yǔ)句里應(yīng)該都是_ad結(jié)尾的
html模版中的應(yīng)該都是_en結(jié)尾的
我說(shuō)不出很多黑客的那些漏洞屬于
但是剛才說(shuō)的那些如果都做到了，代碼安全不成問(wèn)題

然后說(shuō)說(shuō)Discuz!內(nèi)置的一些變量

Discuz!X中，理論上你要用 $_G ($_G['gp_*'] 除外) 里的變量，都要考慮htmlspecialchars和addslashes
$_G['gp_*'] 是DX里的GPC
GP
GET POST 都經(jīng)過(guò)了 addslashes后存放到了$_G['gp_*]中
但_G中的其他，均沒(méi)addslashes
GPC都addslashes過(guò)
dhtmlspecialchars 支持?jǐn)?shù)組
其他同理
如果你有一個(gè)良好的代碼規(guī)范，也會(huì)讓代碼安全性提高
很多規(guī)范大家可以給自己定，像剛才的$a_en $a_ad

第四點(diǎn)，下面簡(jiǎn)單說(shuō)說(shuō)代碼規(guī)范
大家閱讀代碼的時(shí)候也許都看到了
$a = 1;
賦值語(yǔ)句前后空格
if(.........
if后面沒(méi)空格，這些細(xì)節(jié)涉及不到安全，但有一點(diǎn)，這些也有安全影響？

SQL
良好的代碼規(guī)范可增加自己的可讀性
DB::query("UPDATE ".DB::table('common_member_count')." set $giftunit = $remaining where uid = $_G[uid]");

Discuz!規(guī)定sql語(yǔ)句中的SQL關(guān)鍵詞必須大寫(xiě)
DB::query("UPDATE ".DB::table('common_member_count')." SET $giftunit='$remaining' WHERE uid='$_G[uid]'");
修正過(guò)的

$giftunit = $remaining
沒(méi)引號(hào)，而且大小寫(xiě)不明，閱讀起來(lái)很累，規(guī)范的不規(guī)范的寫(xiě)在一起
雖然站長(zhǎng)，不會(huì)看代碼。但是，一個(gè)漂亮代碼文檔，就像一篇好作文。

有一個(gè)SQL上的細(xì)節(jié) notifications=notifications+1
這種SQL語(yǔ)句，理論上我們不推薦，雖然這么寫(xiě)本身是正確的
如果a字段是unsigned類型，那么會(huì)產(chǎn)生數(shù)暴增
產(chǎn)生溢出

a=a+'-1'
就不會(huì)

mysql好奇怪的
這點(diǎn)大家通過(guò)pma試試就知道了

插件如有減分操作的時(shí)候
當(dāng)a=0的時(shí)候
1、a=a-1
2、a=a+'-1'
3、a=a+(-1)
三種方法，你看哪個(gè)ok

下面說(shuō)最后一點(diǎn)
涉及安全的,代碼的流程，你的程序，如果只在你的流程下運(yùn)作
允許100、1000次也許都不會(huì)出錯(cuò)。但是，在別人那里，不一定

舉例
foreach($array as $k => $v)
嗯，$array是數(shù)組，并且存在的時(shí)候。。。

沒(méi)錯(cuò)，是，你自己調(diào)試的時(shí)候，這數(shù)組肯定有
但是在用戶那里，有可能就沒(méi)了
這時(shí)候，這語(yǔ)句有錯(cuò)

如果$array不是數(shù)組的情況下，這句就錯(cuò)了
你可以if(is_array($array))
也可以(array)$array

類似影響流程的不僅僅是foreach
如rawurlencode
echo rawurlencode('sss');
誰(shuí)都知沒(méi)問(wèn)題
但！！回到剛才我曾說(shuō)過(guò)的，認(rèn)清變量類型
echo rawurlencode(array('11'));

肯定出錯(cuò)，大家可以測(cè)試下
因此 rawurlencode($s) 的時(shí)候
一定要確保$s是字串還是數(shù)組

用php的每一個(gè)函數(shù)的時(shí)候都要看清接受參數(shù)的類型
如果是字串，切記剛才說(shuō)的
php很傻，有時(shí)候字串、數(shù)組不分
這是最后一點(diǎn)，爆路徑，爆路徑后能干啥，黑客最清楚

耗子

收藏了~~  下次開(kāi)發(fā)插件前注重以下

xzaxza

感謝分享，

ssbaoer89

機(jī)會(huì)是留給

jiangchuankyo

還有很多歷史原因遺留的嚴(yán)重BUG,
php的正則匹配中小數(shù)點(diǎn).即使你后面沒(méi)有加/s也是包括\r這個(gè)換行符的(網(wǎng)絡(luò)上所有的教程說(shuō)法都是錯(cuò)誤誤導(dǎo)的),

還有PHP_EOL這個(gè)常量千萬(wàn)不能用,因?yàn)樗趙indows下等同于\r\n,linux下等同于\n, 比如現(xiàn)在是windows寫(xiě)入和讀取后分割都是用\r\n確實(shí)沒(méi)有問(wèn)題, 但如果你以后服務(wù)器換到了linux的話分割用PHP_EOL \n那么以前在windows時(shí)寫(xiě)入的數(shù)據(jù)分割后后面全部會(huì)平白無(wú)故多一個(gè)\r出來(lái),長(zhǎng)度完全就不對(duì)了