指令碼安全的本質_PHP+MYSQL第1/3頁

一 前言 問題的存在
從代碼層級上，也就是應用程式層次上考慮代碼安全的話（也就是不考慮底層的語言本身等問題的漏洞），指令碼安全問題就是函數和變數的問題。變數直接或者間接的接收使用者不安全的的輸入，由於php本身的特性，在php中更容易發現這種變數的混亂（很多php程式都用來定義以及初始化以及接收變數，可以直接在程式中使用$id這樣的變數，初始化完全由php的設定來完成，如果稍不注意，就可能導致變數的混亂從而導致攻擊）。
變數接收不安全的輸入之後，沒有做恰當的過濾又用在不同的地方，就可能造成不同的危害。如果直接進入資料庫然後顯示給使用者就會導致跨站指令碼攻擊，如果用在 sql語句中就可能導致 Sql注射攻擊，這幾種攻擊都是是與具體的指令碼語言無關的，在各種指令碼語言裡都可能存在。由於php的變數很靈活，這些有害的變數如果用在一些邏輯語句中，就會導致關鍵代碼的跳過如身分識別驗證失敗和跳過一些變數的初始化從而導致程式邏輯混亂而產生其他漏洞。如果這個變數用在了危險的函數如include等等當中，當然就會出現檔案包含漏洞，出現在fopen函數裡就會可能產生寫檔案的漏洞，出現在mysql_query函數中就是 Sql注射漏洞，eval以及preg_replace中可能導致代碼的執行，出現在htmlspecia函數中可能導致出錯而絕對路徑泄露 變數出現的環境決定了它可能的危害。
思考了問題的存在，那麼如何從代碼層級上檢查這種漏洞呢？當然熟悉熟悉php語言是最基本的，也應該是抓住函數和變數，危險的函數裡如果有變數那麼請確定這個變數的來源，是否正確的初始化，初始化之後是否能被使用者注入敏感字元，在進入函數前這些敏感的字元是否得到了徹底的清除。對於代碼審核工作的痛點可能就在於對變數來源的確定，這需要對php特性以及你所審核的代碼的熟悉，但也並不是所有的變數的來源都清晰可見，可能一些初始化的代碼並沒有像想象中運行，一些變數裡的東西可能也來自於你並不想他來的地方，還有一些變數可能來自於資料庫或者系統的設定檔，但是很可能資料庫和設定檔在之前就已經被修改，或者在後面不安全的操作了這些變數，這些變數也是不可相信的。下面我們就按照變數與函數的思路來思考指令碼代碼的安全。
二 變數來自哪裡？
1 顯示的輸入
叫變數來自哪裡其實也就是說威脅來自哪裡，只是從web上考慮的話，什麼樣的網站最安全？很明顯，那些只提供靜態Html頁面的網站是最安全的，因為這樣的網站不與瀏覽者進行任何互動，就好比打劫一個密不透風的銀行，很難實現，但是對於一個大的論壇或者指令碼程式就不一樣了，你登陸的時候需要傳遞使用者名稱和密碼這些變數給伺服器，甚至包括你登陸的Ip與瀏覽器等等都是程式抓取的對象，抓取一次與伺服器互動的過程如發表文章等等你就發現瀏覽器與伺服器之間進行的資料轉送，你可能看得見的包括提交的表單，地址欄參數等等，你看不見的包括Cookie，Http頭都是提交資料也就是變數的地方。這些地方也是伺服器處理資料最原始的入口。那麼php程式是如何接受變數的呢？所有提交的變數都被php儲存在了一些數組裡，包括
$_GET
$_POST
$_COOKIE
$_FILES
$_SERVER
為了最初的方便與靈活，在php的設定裡有這麼個選項
register_globals
當這個選項為on的時候，上面出現的那些變數都會成為$GLOBALS中的一員，在指令碼中都不需要再取得就可以直接使用，並且以
variables_order
的順序覆蓋。很多程式考慮到了register_globals為off的情況，於是在程式初始化的時候使用如下的代碼：
@extract(daddslashes($_POST));
@extract(daddslashes($_GET));
這些代碼起到了register_globals的作用，作用也是將POST和GET的內容釋放出去做為全域變數，但是危險可能更大，後面會提到。