marc by marc jacobs 官網 腳本安全的本質_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的內容釋放出去做為全局變量，但是危險可能更大，後面會提到。

目前1/3頁 123下一頁

以上就介紹了marc by marc jacobs 官網 腳本安全的本質_PHP+MYSQL第1/3頁，包括了marc by marc jacobs 官網方面的內容，希望對PHP教程有興趣的朋友有所幫助。