【文章內(nèi)容簡介】 展名，泄漏腳本源代碼。 ? 攻擊者可以自定義 form里 file_name變量的值，上傳覆蓋任意有寫權(quán)限的文件。 ? 攻擊者還可以上傳 PHP腳本執(zhí)行主機的命令。 itsec 五、文件上傳（ 5） ? 解決方法 ? 程序員： – is_uploaded_file和 move_uploaded_file函數(shù)，可以檢查操作的文件是否是用戶上傳的文件，從而避免把系統(tǒng)文件拷貝到 web目錄。 – 使用 $HTTP_POST_FILES數(shù)組來讀取用戶上傳的文件變量。 – 嚴格檢查上傳變量。比如不允許是 php腳本文件。 ? 管理員： – 對于上傳目錄去掉 PHP解釋功能，可以通過修改 ： – Directory /usr/local/apache/htdocs/test – php_flag engine off – 如果是 php3換成 php3_engine off – /Directory itsec 六、 sql_inject（ 1） ? 六、 sql_inject PHP有良好的數(shù)據(jù)庫編程接口，支持眾多的數(shù)據(jù)庫，與 MySQL的組合應用更是廣泛。 ? 如下的 SQL語句如果未對變量進行處理就會存在問題： select * from login where user=39。$user39。 and pass=39。$pass39。 ? 攻擊者可以用戶名和口令都輸入 139。 or 1=39。1繞過驗證。 itsec 六、 sql_inject（ 2） ? 不過 PHP有一個默認的選項 magic_quotes_gpc = On，該選項使得從 GET, POST, COOKIE來的變量自動加了 addslashes()操作。上面 SQL語句變成了： select * from login where user=?1\? or 1=\?1? and pass=?1\? or 1=\?1? 從而避免了 sql_inject攻擊。 ? 雖然 PHP默認該選項打開，可是為了安全起見我們還是應該對 SQL語句中的變量進行處理。 添加了一個 mysql_escape_string()來處理這種情況。 itsec 六、 sql_inject（ 3） ? 對于數(shù)字類型的字段，很多程序員會這樣寫： select * from test where id=$id ? 由于變量沒有用單引號擴起來，就會造成sql_inject攻擊。幸虧 MySQL功能簡單，沒有sqlserver等數(shù)據(jù)庫有執(zhí)行命令的 SQL語句，而且 PHP的 mysql_query()函數(shù)也只允許執(zhí)行一條 SQL語句，所以用分號隔開多條 SQL語句的攻擊也不能奏效。但是攻擊者起碼還可以讓查詢語句出錯，泄漏系統(tǒng)的一些信息，或者一些意想不到的情況。 itsec 六、 sql_inject（ 4） ? 解決方法 ? 程序員： 對所有用戶提交的要放到 SQL語句的變量用mysql_escape_string()進行過濾 。 即使是數(shù)字類型的字段，變量也要用單引號擴起來， MySQL自己會把字串處理成數(shù)字。 ? 管理員： 不要給 PHP程序高級別權(quán)限的用戶，只允許對自己的庫進行操作。 itsec 七、安全模式（ 1） ? 前面我們也已經(jīng)提到過 PHP的safe_mode，默認是關(guān)閉的。啟用safe_mode，會對許多 PHP函數(shù)進行限制，特別是和系統(tǒng)相關(guān)的文件打開、命令執(zhí)行等函數(shù)。 ? 所有操作文件的函數(shù)將只能操作與腳本屬主相同的文件和目錄，所以 PHP腳本的屬主最好獨立設(shè)置，不要和其它文件的屬主相同。 itsec 八、信息顯示（ 1） ? PHP默認顯示所有的警告及錯誤信息： error_reporting = E_ALL amp。 ~E_NOTICE display_errors = On ? 在平時開發(fā)調(diào)試時這非常有用，我們可以馬上根據(jù)警告信息找到程序錯誤所在。 ? 正式應用時，警告及錯誤信息讓用戶不知所措，而且給攻擊者泄漏了腳本所在的物理路 itsec 九、信息顯示（ 2） ? 徑，為攻擊者的進一步攻擊提供了有利的信息。而且由于我們自己沒有訪問到錯誤的地方，反而不能及時修改程序的錯誤。 ? 所以把 PHP的所有警告及錯誤信息記錄到一個日志文件是非常明智的，即不給攻擊者泄漏物理路徑，又能讓自己知道程序錯誤所在。 itsec 九、信息顯示（ 3） ? 修改 Error handling and logging部分內(nèi)容： ? error_reporting = E_ALL display_errors = Off log_errors = On error_log = /usr/local/apache/logs/ ? 然后重啟 apache，注意文件/usr/local/apache/logs/讓 nobody用戶可寫。 itsec JSP安全編程 ? JSP (Java Server Pages)是一種基于Java語言的 Web服務端編程語言 ? Java語言自身的安全性比較高，使得使用 JSP編程出現(xiàn)安全問題幾率變小 itsec JSP – 緩沖區(qū)溢出（ 1） ? JSP不受緩沖區(qū)溢出漏洞影響 ? 從輸入流讀取輸入數(shù)據(jù)的 C代碼通常如下所示： char buffer[1000]。 int len = read(buffer)。 由于實現(xiàn)無法確定讀入的數(shù)據(jù)長度，上述代碼就可能發(fā)生緩沖溢出。 ? 在 Java中，一般用字符串而不是字符數(shù)組保存用戶輸入。與前面 C代碼等價的 Java代碼如下所示： String buffer = ()。 itsec JSP – 緩沖區(qū)溢出（ 2） ? 在上面的例子中，“緩沖區(qū)”的大小總是和輸入內(nèi)容的大小完全一致。由于 Java字符串在創(chuàng)建之后不能改變，緩沖區(qū)溢出也就不可能出現(xiàn)。就算用字符數(shù)組替代字符串作為緩沖區(qū)， Java也不象 C那樣容易產(chǎn)生可被攻擊者利用的安全漏洞。 ? 例如，下面的 Java代碼將產(chǎn)生溢出： char[] bad = new char[6]。 bad[7] = 50。 這段代碼總是會產(chǎn)生一個異常： itsec JSP – 緩沖區(qū)溢出（ 3） ? 這種處理過程永遠不會導致不可預料的行為。無論用什么方法溢出一個數(shù)組，我們總是得到 ArrayOutOfBoundsException異常。因此 Java運行時底層環(huán)境就能夠保護自身免受任何侵害。 ? Java編程模式從根本上改變了用戶輸入的處理方法，避免了輸入緩沖區(qū)溢出，從而使得Java程序員擺脫了這種最危險的編程漏洞。 itsec JSP – 執(zhí)行系統(tǒng)命令 ? Java實現(xiàn)了比較完善的 API，很多涉及系統(tǒng)的操作都可以通過這些 API完成，例如發(fā)送郵件就可以使用 JavaMail來完成。但是如果程序員非要使用系統(tǒng) 程序來完成，就可能會存在一些安全問題，例如 ().exec()函數(shù)就可以執(zhí)行系統(tǒng)命令，如果沒有對傳遞進來的數(shù)據(jù)進行檢查，就可能被攻擊者利用來執(zhí)行系統(tǒng)命令。 ? 解決方法：盡量使用 Java API來完成相關(guān)操作。 itsec JSP – SQL注入攻擊 (1) ? 一段問題代碼 String user = (“username”)。 String pass = (“password”)。 String query = “SELECT id FROM users WHERE username=”+user+