網站語言醜小鴨：PHP之安全性探討原則
原作者：Edward Lee, Brian Chess, Jacob West(Fortify Software 顧問)
一、前言
1995年丹麥的Rasmus Lerdorf開發出Personal Home Pages(PHP)後，PHP已成為網站使用最頻繁的程式語言，特別是PHP語言正好搭上企業使用開放源碼工具的風潮。PHP出現的頭10年，安全上已經聲名狼籍。PHP是否能勝任企業應用程式開發工具，或其快速開發能力與使用簡便也能讓開發出來的應用程式足夠堅實與安全？即便PHP正逐漸演變為滿足企業使用的程式語言，但這樣的疑問在2009年仍被大量的提起。也就是說，PHP的開發人員的開發習慣並未和安全劃上等號。
開發人員最需要的是嚴格的PHP撰寫規範，避免落入使用不安全的功能窠臼裡。這些程式撰寫規範最少要使用PHP 5.3.0之後版本，並進行相關安全設定。撇開撰寫技巧，開發人員必須額外關注PHP的安全性，而非紙上談兵。
接下來，我們會比較PHP、Java和.NET三種程式語言，到底PHP是否適用於企業、PHP的安全性、以及探討企業軟體安全未來動向。
二、「適用」的定義
「判斷」某個程式語言是否適合企業使用之前，我們先來「判斷」該如何「判斷」。首先，昇陽科技公司(Sun)區別Java SE(Java Standard Edition)和Java EE (Java Enterprise Edition)之不同；以Java SE建立起Java使用環境之後，Java EE提供企業更完整、穩定、安全、快速的企業平台功能。再者，微軟也針對.NET的範圍、安全性、穩定度、整體表現等提出類似看法。本章節歸納出企業採用的必備條件如函式庫、健全性、及效能等面向，同時分析PHP、.NET、Java於各面向的優劣評比，最後再帶出資安議題。
函式庫涵蓋廣度
企業所用的系統程式語言非常複雜，他們希望採用的framework能簡化程式碼，並且元件可以重複使用。設計良好的framework已經考量常用的演算法與資料結構，開發人員程式碼可以精簡，管理起來也比較方便。
Java EE函式庫涵蓋度很好，而且開發人員都有許多第三方函式庫及framework能選擇使用，這些函式庫與framework讓開發人員增加資料庫的使用授權認證與管理功能。.NET framework的第三方函式庫雖不及Java EE，但因微軟函式庫涵蓋度很好，開發工具完備，開發彈性一樣深受開發人員喜愛。
PHP內建的函式(function)與方法(method)已經很多，但是開發人員需要的更多。在開放源碼裡，PEAR與PECL專案是為了提供PHP核心函式庫擴充功能而生。PEAR與PECL套件(package)的加入，PHP開發人員多了數千種第三方函式庫的支援。新版的PHP核心函式庫已經納入許多新的功能。例如PHP 6現在納入XML函式庫，取代原來的PECL套件。簡單來說，現在的PHP開發人員想要的函式庫幾乎都已經有了。
提到資安，第三方函式庫能給開發人員最有力的支援。像是Hibernate、CakePHP與Doctrine這類的物件關連式對應(Object-Related Mapping) framework函式庫，可以對資料庫建立參數化(parameterized)的查詢語法，限制變數資料型態，限制使用者的存取權限。另一方面，第三方函式庫更新的速度其實有限，PHP就沒有MVC架構，而其他程式語言早就支援，看來使用方便的重要性還是大於資安議題。
穩定性與效能
一般來說，網頁開發平台沒有所謂的「穩定性」及「效能」標準，所以我們以大型商業建置案例做為「標準」。企業應用程式必須處理大量資料，系統故障時間必須降至最低，反應時間必須合理；這表示程式語言至少需具備「穩定」和「效能」以應付龐大資料量。以「穩定」和「效能」來說，Java 於業界有口皆碑，事實上大部分的應用程式伺服器(application server)以Java撰寫。而微軟陣營，流量最大的網站包括msn.com, live.com. Microsoft.com，皆以.NET語言開發。此外，不少財政機構、電子商務平台、新聞媒體組織等都是.NET的成功案例。
PHP也不惶多讓，知名網站如Yahoo、Facebook、MySpace、Wikipedia等使用PHP語言開發。根據統計，世界十大流量網站，使用PHP的比例居各語言之冠（如表一）。既然PHP使用率如此高，不管是穩定性或效能，早已不證自明。然而，若上述範圍擴大至資安面，PHP似乎又多了些不確定性。
三、PHP的安全性
說到安全性，PHP名聲不算太好；但若追根究底，是否PHP本身漏洞百出？或者只是PHP使用比率高，使得出錯量相對較高？我們將問題分為「語言安全性」與「安全實作方式」來看，在3.1節，我們討論語言安全性，開發人員出錯的可能性如何(例如新手使用C語言最容易造成「緩衝區溢位(buffer overflow)」的漏洞)。安全實作方式，換句話說就是開發人員可實作使用的安全功能為何，我們要研究PHP函式庫，解析他的安全實作能力。在3.2節，我們將從Fortify Open Review專案裡統計PHP開發的應用程式弱點，並作為討論的基準。
- 語言安全性
早期版本的PHP因功能強大，方便性夠，連帶使開發人員忘了注意安全問題。隨著PHP越來越成熟，許多功能預設關閉，或乾脆完全移除。本節後續篇幅將討論PHP最危險的功能，使PHP安全性惡名昭彰的功能。此外盡可能不要在手機上執行太過複雜的運算，如果本來就會花上一段時間的行為例如由網路取得資料，應該要另開執行緒處理，避免前景發生無回應的狀況。儲存空間使用方面，雖然現在的手機平台沒有像以前J2ME時代會限制單一應用程式的大小不得超過512K之類的規定，但Android的應用程式在Android 2.2版之前是不能安裝在SD卡上的。手機的內建記憶體大小通常是256 MB至512 MB，你的應用程式如果太過肥大，當使用者空間不足時可能會首先遭到移除的命運。- Register Globals
觀察程式語言安全的一個重要的點，就是這個語言如何保護程式碼與資料。程式語言不應讓程式使用者隨意的更動程式碼與資料。PHP有一個register globals功能，使得程式開發人員無法輕易安全的處理使用者的輸入資料。這個功能會自動產生變數，將HTTP request收到的資料定義於變數數值內。所以，攻擊者也可以如法炮製產生變數數值。PHP 3可以將此功能關閉，但是在PHP 4.2.0又恢復。好消息是，在PHP 6已經將此功能移除。沒有經驗的開發人員遇上這樣的功能，其實是件雪上加霜的壞消息。現今大部分有危機意識的開發人員已經可以調整心態，不使用這樣危險的撰寫方式。 - SafeMode-Sandboxing
早期版本的PHP提供數種「安全」選項，應用程式可使用「沙盒」這樣的安全機制。PHP的安全模式用在相同主機上隔離不同的應用程式環境。然而PHP的沙盒功能並不完備，甚至有可能被避開，導致管理者與開發人員對於PHP的安全機制有所誤解。
Java開發人員可以使用Security Manager隔離應用程式，但大多數的開發人員並不重視這項功能。同樣地，.NET允許開發人員設定程式碼存取安全原則，但是開發人員大都只使用預設原則。
沙盒可增進應用程式的安全強度，但是安全原則必須由有經驗的人士設定方可達到最大效力，所以不該視沙盒為最主要的防線。原本可增進安全強度的安全模式，到PHP6被移除了。 - Allow_URL_Fopen功能
PHP有一項功能讓開發人員存取URL像開檔一樣的簡單。這個功能看起來方便，但容易釀成大禍。例如Web應用程式允許使用者指定PHP檔案並加以執行，這個功能給駭客有機可乘，指定主機上已存在的檔案並加以執行。如果主機的檔案系統的存取控制有適當的設定，那這個漏洞對系統不會有多大影響。但是PHP可以include遠端檔案的機制卻可對系統造成相當大的危害，因為遠端檔案不受主機的存取控制的限制，駭客可以將遠端檔案注入主機並加以執行。
PHP 5.2.0版本已經可關閉Allow_URL_Fopen功能，可限制遠端檔案注入弱點。但是Allow_URL_Fopen已經在Java與.NET之外開了一扇不同的弱點之門。 - 神奇的引號功能
PHP在版本5.0之前，開發人員通常會使用動態數值，字串相加方式組成SQL語法字串，這樣的組成方式非常容易遭受SQL注入攻擊。PHP稱為神奇引號功能的addslashes()函式，是PHP團隊嘗試過濾動態組成SQL字串內容的一項工作。神奇引號功能函式addslashes()可自動地在單引號「'」、雙引號「"」、反斜線「\」與空字元之前加入反斜線「\」符號。神奇引號功能可自動塞入反斜線，開發人員若非用於處理SQL字串，就必須拿掉這些多出來的反斜線。神奇引號功能並非SQL注入攻擊的萬用解藥，他對資料後製處理的複雜度也相對提高，在PHP 5.3.0版神奇引號已經不受重視，在PHP 6這個功能也已被移除。
- Register Globals
- PHP安全性
本節以Fortify Open Review專案大量的PHP專案檢核，深入討論PHP安全實作的一些問題。Fortify Open Review專案以找出熱門開放源碼軟體弱點為工作主旨。Fortify Open Review專案使用Fortify SCA進行掃描，為了撰寫本文，我們依據freshmeat.net網站的10大PHP專案挑選掃描標的：phpMyAdmin、Gallery、SquirreMail、TikiWiki、DocuWiki、phpBB、PHPProjekt、WebCalendar、eZPublish與Group-Office。這些專案共有的弱點包括：Cross-Site Scripting、SQL Injection、System Information Leak、Path Manipulation、Header Manipulation、use of dangerous function與code injection等問題。表二總結了所有找出的弱點問題。
四、結論
PHP需要的是全新的設計。經過我們的分析，雖然PHP正逐漸成形為安全與堅實的開發環境，但現今的PHP專案正反應了PHP開發社群並未趕上最新的安全技術。開發時期使用到的第三方元件可以為PHP專案開發帶來安全上的好處。軟體系統規模越來越大，可重複使用的元件就越能彰顯他們的價值。像是OWASP提供的安全專用的API OWASP Enterprise Security API(ESAPI)能解決特定的安全問題，如Input Validation，就是這些第三方軟體崛起的最好時機。可重複使用的元件在鼓勵開發人員注重安全開發佔有重要的地位。換句話說，當第三方元件採用不良的安全設計，追蹤問題的困難度相對更高，因為元件與程式碼中間通常隔了一層抽離層。對使用者來說，軟體開發社群必須持續不斷精進安全技術能力，打造夠出安全的元件。