PHP本身並沒有安全性問題（假設需要安全更新），因為它存在很多流行的基於PHP的軟件，都存在嚴重的安全性問題。您可能會批評PHP是一種語言，它給您足夠的繩索來使自己感到窒息，但是真正的問題是易受攻擊的PHP代碼實際上是多麼普遍。一個人只需要使用 Stack Overflow PHP標記就可以發現PHP的新手根據舊教程的一些殘酷性來編寫令人毛骨悚然的代碼。

此外，大量受歡迎的PHP以其普遍存在的安全漏洞而聞名的軟件基於很老的代碼和編碼慣例。由於固有的安全性問題，許多舊的做法被認為是不當行為。

在我看來，這聽起來像是告訴某人不要開車，以免發生車禍。

是的。更好的建議可能是“不要駕駛沒有安全氣囊的舊車”。

我的直覺是，主機正在試圖將安全漏洞歸咎於客戶。自己的系統。

不一定。如果用戶為WordPress網站和cPanel使用相同的密碼，則破壞WordPress密碼也會損害cPanel。那將是用戶的錯。黑客很少需要走那麼遠，而只需使用PHP shell。

我告訴我的客戶，要處理聯繫表單，他們將需要某種形式的動態腳本。 （否？）

不一定是真的。您可以使用第三方服務來處理郵件發送。然後，該服務將處理動態服務器腳本並接管安全隱患。有許多具有不同功能集的此類服務可用，它們很受支持為靜態生成的站點上的聯繫表單提供動力。

聲稱使用任何PHP腳本（無論多麼簡單）是一個固有的安全性問題有多少道理？

有些，但不是很多。 PHP確實在PHP和執行它的服務器軟件中都包含一些活動代碼。如果該過程中曾經有一個不依賴於特定PHP代碼的安全漏洞，則可以利用它。儘管這種風險很小，但是這是沒有這種支持的服務器所沒有的風險。

“正確”可能不是正確的詞，但是會想到“明智”，“謹慎”和“盡責”。自成立以來，PHP一直秉承降低軟件正確性的理念。程序可能會遇到很多情況，其他語言（例如Python）會放棄並拋出錯誤來告訴您您的程序是錯誤的，但是PHP卻選擇做一些荒謬的事情並繼續進行，就像事情只是

請記住，正確性對於安全性非常重要。傾向於靜默忽略左右錯誤的語言將比帶有安全問題的程序擁有更多的份額。例如，您可能有一段代碼，您的程序員認為這些代碼可以防止某種攻擊，但實際上由於解釋程序忽略錯誤而被跳過。

此外：

• PHP的設計宗旨是吸引程序員的最低分母，並以最少的動力去熟練自己的技術。因此，最有可能編寫不安全的軟件。
• PHP團隊在解決常見的安全問題方面有著嚴重的缺陷。例如看一下SQL注入保護，它出賣了反复的錯誤嘗試來解決問題： real_escape_string （因為原始的 escape_string 已損壞，但直到後來，他們才將其刪除） ）與 斜杠與 mysql_escape_string / pg_escape_string 等。幾乎所有其他語言都帶有準備好的語句和查詢參數，並且在第一次嘗試時就可以將其設計擴展到所有數據庫。

因此，所有有關您如何使用其他答案的討論可以用PHP編寫安全的軟件，如果您嘗試使用它，將會非常不符合潮流。

PHP的安全問題通常可以分為兩類

未打補丁的系統

截至目前， Wordpress統計信息顯示了所有用戶的一半以上在壽命終止（PHP 5.2-5.4）之後的PHP版本上運行PHP。在兩週內，PHP 5.5停產，然後躍升至所有安裝量的80％。公平地說，現在，某些Enterprise / LTS Linux安裝將向後移植安全修復程序，但是其中絕大部分都沒有在使用向後移植的修復程序（或某些未對他們的系統打補丁）。更糟糕的是，許多人拒絕升級PHP本身。他們要么無法/不會更新其代碼，要么他們認為較舊的軟件更穩定。

Wordpress（全球範圍內排名第一的PHP應用程序）做出了共同努力，以確保用戶能夠及時了解最新信息。關於軟件本身的日期（他們已經取得了長足的進步），但是儘管如此，只有40％的人運行最新版本的Wordpress。這意味著大約60％的人可能存在未修補的安全漏洞。那隻是基礎程序。 WordPress具有龐大的插件生態系統，其中許多具有自己的安全漏洞。

然後還有其他問題，例如許多使用已失效的 mcrypt的舊代碼庫。那隻是您可以編譯的一個PHP插件。

現在將其推斷為未運行的服務器，並將統計信息報告給WP。它沒有畫出漂亮的圖畫。去年夏天，我發現一個運行電子商務頁面的網站仍在Apache 1.3.3和PHP 4.1.2上。太老了，啟用了SSLv2 ...

錯誤的做法

如果您對SO PHP問題的討論時間足夠長，就會發現很多人在練習錯誤的代碼。我多年來看到的一些問題

• SQL注入
• 認為MD5是保護密碼的好方法
• 使用過時的API int他們的代碼（即 ext / mysql ，舊的MySQL連接器）
• 信任用戶輸入以執行代碼（即對用戶提供的數據使用 eval）
• 未關閉PHP代碼中的安全風險（即 exec函數）

對於未經培訓的人，這看起來像一個PHP問題，編碼器及其產生問題的生態系統。也許他們很著急。也許他們雇了一個在業餘時間做這件事的人，“只是讓它起作用”。

可以安全嗎？

是的！但是，這種安全性需要付出一些努力。使您的PHP安裝保持最新。哎呀，讓您的整個服務器保持最新狀態。主機不會做安全和補丁程序嗎？ 找到另一位主持人。（令我驚訝的人對此感到驚訝）。構建自己的服務器（VM很便宜）。但首先要注意。了解有關安全性的所有知識。不要只是讓您的網站和服務器出海。

有人告訴您PHP不安全只是在偷懶。

與任何其他語言（Java，Rails等）相比，PHP都一樣，或更安全或更不安全。這全都與編碼有關。是否進行製衡，以偏轉，防禦，防止或減輕攻擊。引用：

WhiteHat Security使用.NET，Java，ASP，PHP，Cold Fusion和Perl對30,000多個網站進行了漏洞評估。使用最廣泛的語言是.NET（佔Web應用程序的28.1％），Java（佔24.9％）和ASP（佔15.9％）。

...

編程語言.Net每個插槽，Java 11.32和ASP 10.98的平均漏洞為11.36。最安全的語言ColdFusion每個插槽有六個漏洞。 Perl每個插槽有七個漏洞，PHP有10個漏洞。

...

Java佔發現的漏洞的28％，ASP佔15％。報告說：“同樣，必須考慮使用該語言編寫的應用程序的數量以及網站的複雜性。” PHP也佔發現的漏洞的15％。 ColdFusion僅佔漏洞的4％，Perl佔2％。 （ source）

這並沒有說明根據良好的編碼慣例如何開發網站。例如，如果您使用每種語言的非熟練（缺乏術語）程序員，則這些數字可能會相反，而perl的漏洞最多，而.Net的漏洞最少。一切都歸結為代碼本身應該做什麼。在將代碼投入開發之前，是否已對其進行編程以執行其唯一功能並進行了篡改/濫用測試？

有很多安全性備忘單，最佳實踐指南，以及涉及安全性問題的其他文章，但這是一種情況客戶會根據其提供者的建議而感到厭倦。她說，要說服您的客戶允許您使用PHP創建網站，這可能是一個障礙，因為這變成了“他說”。如果我仍然想使用PHP，我可能會使用的一種方法是創建一個演示站點，然後對它使用漏洞評估掃描程序（Acunetix，AppScan，Burpsuite）來檢查缺陷。如果找不到任何內容，我將向該報告提供詳細說明您對兩個客戶端構建的安全狀態的報告，並以可以提供給提供商的方式（PDF等）進行創建。

PHP的一個基本問題實際上是CGI事物模型的一個基本問題（儘管 mod_php 陷入困境，PHP還是基於此模型的）-即面向用戶的數據是混合在一起的使用腳本，例如用戶上傳以成為可執行腳本。這並不是PHP本身的問題，但是在系統上完全可以使用PHP使得它成為一個很大的攻擊面。例如，相當多的WordPress插件的安全性問題就來自此方面。

基於CGI的傳統部署在歷史上通過僅允許CGI腳本從受信任的目錄（如 / cgi-bin / ），但許多共享主機提供商最終放寬了對“便利性”的限制，並且在整個PHP中也普遍存在這種便利。

許多基於PHP的現代應用程序經常使用 .htaccess 作為一種快速，骯髒的請求路由機制，確實有助於緩解這些問題，但這遠非通用，而且仍然不是很容易解決。

在我看來，PHP的最大問題在於，可以很容易地在任意配置了它的服務器上執行任意PHP代碼，因此，用PHP編寫的代碼不一定比編寫的代碼更安全或更安全。其他語言（儘管其標準庫在編寫se時並沒有任何幫助治愈代碼），PHP腳本的執行機制通過PHP的優點提出了巨大的安全挑戰，甚至在服務器上也是如此。

我同意您的評估，即使用PHP並不一定會帶來安全風險。有些供應商出於與WordPress被視為安全風險的大致相同的原因而迴避PHP。很受歡迎越流行，就越有更多的精力投入到開發漏洞利用中。 。底線：安全風險是與平台無關的安全風險。更改腳本語言不會減輕與編寫/開發/實施代碼不良相關的安全風險。

如果只想包含一個標準的頁眉/頁腳，則PHP可能會過大-簡單的服務器端包含可以做到這一點。

如先前的回答所述，PHP並不是天生的危險。但是，如果您在服務器上不需要完整的腳本語言，則最佳安全實踐是不安裝一種。如果您說過無論如何都要在服務器上安裝PHP，那麼只要您不做任何愚蠢的事情，使用它所產生的額外風險大約為零。除非您以某種方式從URL參數解析文件名，否則包含模板並不愚蠢。

聯繫表單將需要某種API和數據庫來支持在有人提交時的POST請求。這部分的編寫水平將如何使事情成敗-無論您使用哪種語言，如果是SQL數據庫，那麼SQL注入都值得關注；如果以某種方式在網頁中將用戶的輸入回顯給用戶或客戶端，則需要考慮（java）script注入，並且所有內容均應正確轉義為HTML。與聯繫表相比，使用include會盡可能安全。

如果您只想要一組網頁，而不是交互式Web應用程序，那麼最終的安全性是使用靜態網站生成器-服務器只需要提供文件即可，從而大大減少了攻擊面。

所以：

聲稱使用任何PHP腳本（無論多麼簡單）都是固有的安全性問題有多少道理？

這樣說，幾乎沒有。包含標頭腳本當然不是漏洞。不需要時首先安裝PHP並不是最佳的安全實踐，安裝並在安全補丁發佈時不定期對其進行更新是一個潛在的問題，因為沒有負責由誰負責這些更新的策略-完成網站設計後，客戶將負責此工作嗎？還是託管服務提供商？如果客戶端對此感到擔心，那麼他們首先不應該在服務器上安裝PHP。如果沒有，那麼就沒有安全相關的理由不在您知道自己在做什麼的地方使用它。

語言和工具並不是天生不安全的，糟糕的代碼和安全實踐也不是。

由於php的進入門檻很低，因此不了解網絡安全性和安全編碼的人會造成安全問題

不是工具，而是使用它的猴子；-）

用任何語言編寫的代碼都是不安全的。

“他們不願意，因為託管公司告知他們使用PHP是一種安全問題，這可能會使某人闖入cPanel並獲得對該網站的控制權”。

如果託管公司認為需要cPanel來運行PHP，然後才能移動主機