3 回答

TA貢獻(xiàn)1982條經(jīng)驗(yàn) 獲得超2個(gè)贊
好的,除了mysql_*被棄用之外,我了解您想知道可能存在的任何可能的解決方法。也許這篇博客文章和幻燈片可能會(huì)揭示其中的一些內(nèi)容。
但是,正如這里的較早的問(wèn)題所顯示的,強(qiáng)制轉(zhuǎn)換和引用并不能完全證明這一點(diǎn)。有太多事情可能出錯(cuò),而墨菲定律與那句永不止息的口號(hào)“永不信任網(wǎng)絡(luò)”纏繞在一起,將大錯(cuò)特錯(cuò)。
也許這篇文章,但最重要的是,該文章的后續(xù)內(nèi)容可以揭示更多的安全問(wèn)題。老實(shí)說(shuō),我知道m(xù)ysql_real_escape_string即使與類型轉(zhuǎn)換和字符串格式結(jié)合使用也不是完全可靠的:
printf('WHERE id = \'%d\'',(int)mysql_real_escape_string($_REQUEST['id']));
無(wú)法涵蓋所有可能的攻擊。
我不是這方面的專家,但是我可以告訴您的是對(duì)每個(gè)輸入進(jìn)行消毒,如果有的話,將給您帶來(lái)虛假的安全感。大多數(shù)時(shí)候,您會(huì)(最初)知道如何以及為什么以及如何防御攻擊,但是您的同事卻可能不知道。他們可能會(huì)忘記某些事情,并且整個(gè)系統(tǒng)都將受到損害。
總結(jié):是的,您也許能夠阻止任何形式的惡意輸入進(jìn)入您的數(shù)據(jù)庫(kù),但是它需要執(zhí)行的每一項(xiàng)其他操作都會(huì)帶來(lái)額外的風(fēng)險(xiǎn)。在那種情況下,最大的責(zé)任(一如既往)是周一早上沒(méi)有喝過(guò)第四杯咖啡的開(kāi)發(fā)商。任何代碼,無(wú)論如何防御和深思熟慮,都無(wú)法保護(hù)自己免受怪物的侵害,因?yàn)楣治锸瞧獗┰?,脾氣暴躁,?duì)咖啡因和尼古丁無(wú)視的火雞。

TA貢獻(xiàn)1784條經(jīng)驗(yàn) 獲得超9個(gè)贊
本身,我發(fā)布的代碼片段無(wú)法被AFAIK所利用,但會(huì)產(chǎn)生錯(cuò)誤,并且在探測(cè)漏洞時(shí)會(huì)產(chǎn)生惡意,例如惡意調(diào)用ppl。您還很有可能在WHERE
子句中使用1個(gè)以上的參數(shù),每個(gè)參數(shù)都需要三個(gè)附加操作(字符串格式,類型強(qiáng)制轉(zhuǎn)換和轉(zhuǎn)義調(diào)用),因此此方法容易出錯(cuò)(進(jìn)行強(qiáng)制轉(zhuǎn)換)或占位符錯(cuò)誤,則不再安全)。在我也鏈接的問(wèn)題中,排序規(guī)則的意義也提出了,我的摘錄根本沒(méi)有解決
添加回答
舉報(bào)