Re: [討論] PHP是個漏洞多且不安全的後端語言？

看板PHP作者MoMoShota (正太控)時間4年前 (2020/05/07 19:04)推噓6(6推 0噓 1→)

留言7則, 6人參與討論串3/4 (看更多)

這類謬論看多了也就覺得見怪不怪。 ※ 引述《red0whale (red whale)》之銘言： : 昨天我的資料庫老師說 : PHP是一個漏洞相當多、非常不安全其實不否認在某些「歷史共業」的情況下，PHP 常常會寫出有漏洞的程式碼。例如我在之前文章提過的一個例子： <?php if (!session_id()) session_start(); extract($_GET); var_dump($_SESSION); 如果 /?_SESSION['login']=true 會發生什麼事？雖然在近幾年 Modern PHP 越來越普及的今天，已經罕有人會寫出這種程式（如果有，請打爆他）但是維護多年以前的程式，確實還是有機會看到各種漏洞滿天飛。 : 而且是外面業界鮮少在使用的後端程式語言 : 他還說PHP只是給學生在用的程式語言 : 而他建議我們做網頁後端最好使用像C#或Java之類的需要編譯過後才能使用的「編譯語言 : 」 : 而非使用像PHP這種「直譯語言」 : 原因之一在於PHP是以明文儲存程式碼 : 在外面業界如果使用明文丟後端程式語言給其他人，早就造成安全上的漏洞了其實我不知道為什麼你的老師要用 C# 或 Java 這種有 bytecode 語言來舉例。因為在沒有特別處理的情況下，C# IR 跟 Java bytecode 幾乎可以很完美地轉回原始程式碼。註：以前某國立大學的學生資訊系統前端就是用 Java Applet 寫的，把東西載下來逆向甚至看得到他們 DB 的密碼。註2：曾經有一款用 Unity 寫的手遊，因為把 AES Key 直接寫在程式碼裡，所以載下來之後拖進 ILSpy 就可以直接寫出脫機外掛所以一般在發佈 APP 時還是會注意要做混淆，或是直接依賴 LLVM 這種編譯器會優化到他媽都不認得也是一種方法。註：其實混淆、加殼之類的都有機會可以解，不過如果破解成本遠高於獲益的話就很少有人會幹這種苦差事。註2：我 FB 上的好友看到這篇文章之後就嗆說「當我們逆向狗吃素的？」然後其實 PHP 也是可以編譯的，你可以在發佈前把 PHP Code 編成 Zend VM Opcode，一般人是不會這麼幹就是了。或是也可以依賴 inocube 之類的 obfuscator 把 PHP 混到一個很恐怖的境界。註：PHP 的混淆如果沒有 extension 支持的話，基本上就只是演演戲罷了。 : 所以非常不建議使用PHP作為網頁後端的程式語言 : 另外，他也提及 : 用PHP連後端資料庫是非常危險的 : 原因也是因為直譯式的關係 : 如果用PHP的話，資料庫的帳號密碼之類的也很容易外露造成資安漏洞一般來說，「正常的」PHP 應用程式不應該把 secret data（如 DB Password）寫在程式裡，而是應該利用 environment variable 去處理或是一些比較先進的會用 Docker secret、k8s secret 之類的 Tools。 : 所以他說在外面業界幾乎很少有人會使用像PHP這種直譯式程式語言作為網頁後端的程式 : 語言 : 也非常不建議使用PHP，因為它本身的漏洞實在太多，且相當不安全 : 不曉得各位有什麼看法？ : 對於PHP不安全、漏洞多有沒有什麼能夠補救的辦法？ : 順帶一提，我也有想過，像Facebook、Wikipedia 之類的大網站不也是使用PHP作為其中 : 一種程式語言嗎？這邊點一個問題，很多 PHP 的擁護者在 PHP 受到批評的時候常常會拿 Facebook 出來嘴。不過還是要認清一個現實：Facebook 雖然草創初期是使用 PHP，但是他們也嫌它的效能不足所以開發 Hack 與 HHVM。目前 Facebook 還停留在「我們一般所認知的」PHP 的程式碼應該是少之又少的（應該都已經重構並用其它語言取而代之）大部份 PHP 應用程式的漏洞都是起因於工程師觀念不足，還有許許多多錯誤的範例在網路上流竄的結果。當然，PHP 語言本身允許這樣的錯誤存在也是責無旁貸，如果它的設計可以再嚴謹一些，有很多問題都可以不存在。我非常推薦任何一個 PHP 工程師都應該要讀過 Modern PHP（中譯：現代 PHP），它為一個充滿歷史的語言提供未來的可能性。然後遵守 PSR 標準，可以讓 PHP 的生涯過得更加愉快（不過後面的標準越出越雜，Laravel 的作者就有在推特上批評過）順帶一提，其實 PHP 核心也是存在漏洞的，例如 PHP 7.4.5 就才剛剛修復了 CVE-2020-7067。不過就這語言核心漏洞來說，就算是很現代的 Golang 或 Rust 也存在這樣的問題。然而，正因為這些東西是 Open Source，在大多數人的檢視及貢獻下才能夠發掘這些問題，這也是為什麼「OpenSource 不等於有安全風險」的理由。 : 雖然昨天也有跟老師討論到這個 : 不過老師是跟我說，那些大網站使用PHP也只是用來做顯示前端的一些部分事實上也還真的有不少公司把 PHP 當前端，然後去接後端 API（Java）的。不過我思考了 Hen 久，到底為什麼不用更方便、社群更龐大的 React, Vue 或 Angular 呢… 雖然 PHP 之父自己說過，他創造這個語言只是想當 template engine，但隨著時代的不同它早就擁有不同的定位。我常常說「每個語言都有它的特性存在，使用不同的語言只是為了不同的場景需求罷了。」 PHP 可不可以寫 GUI？可以啊，PHP-GTK，只是沒有人會這麼幹。 PHP 可不可以實現 Websocket Server？可以啊，Swoole PHP 跟 React PHP，只是也不是主流用法。對我來說，PHP 就是一個快速開發 Prototype 並且寫超來很快很爽的語言，但在追求高效能或是一些特定場景（例如 IoT 之類的）我不會優先選擇它 : 真正使用後端像是連資料庫之類的根本不可能使用PHP來寫 : 他說如果他們用PHP做後端的話是相當不安全、風險很高的作法 : 然而，我已經使用PHP做為後端語言已經好幾年了 : 聽到老師這番話要我全部改學另一種語言而且又要把先前已寫好好幾萬行的PHP碼全部都 : 改寫 : 我認為這是個相當相當浩大的工程 : 希望各位可以給些建議和看法 : 謝謝以我個人的角度，你可以先思考這「幾萬行」程式是不是都適合 PHP 實現？如果都適合，那就放手去做。在大多數的情況，「有成果」遠比「沒有成果」來得有說服力。舉例來說，你今天把你的程式通通砍掉，然後改成 Rust 好了。但是這份作業你要花比原本多 20 倍的時間才能完成，而且可能因為不熟悉而無法完成。你的老師會因為你用了 Rust 好棒棒，給你比有成果的 PHP 程式更高分嗎？如果會的話，那就放手去改吧。當然，如果站在學習的角度，其實也沒什麼不可。你可以嘗試著把某些比較常使用到的功能改成其它語言實現： 1. 假設原本有 Polling, Long-Polling 實作的聊天室就改成 Websocket + Nodejs 實作看看 2. 假設原本有需要「排程」的功能，可以導入 Message Queue 去改善看看 3. 假設原本有需要影像處理，可以試試看 golang 實作會不會效能更高終歸一句話，程式語言是個工具，端看你怎麼應用它。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.135.87.237 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/PHP/M.1588849468.A.4E9.html