Web應用程式安全－從良好的程式開發習慣開始

開發語言
每個程式語言都有其特性，但是多數的開發者對其所擅長之開發語言所掌握的安全認知往往不足，開發者最為常見的錯誤為使用了教科書中的範例或是沿襲了特定書籍的編寫風格。殊不知範例程式碼有可能是書籍作者為了讀者方便閱讀而精簡其範例，甚至作者本身因為專業領域不同，本身的安全開發能力較為薄弱，以致從安全性的角度來檢視其範例程式碼，往往都是有待加強的結果。
阿碼科技在其開發自動化的原始碼檢測工具過程中，初期選擇了PHP程式語言作為檢測對象，其資訊安全研究團隊則於PHP語言常用的伺服器環境變數($ _Server Array)共35個，找出了14個變數是具有潛在風險性的，比例約為五分之二，比例之高不可不重視。開發者若是在使用這些環境變數前，沒有先使用過濾函數或是安全化函數就直接進行資料庫檢索(SQL Query)或是輸出至網頁上面，那麼很容易造成SQL 隱碼攻擊 (SQL Injection)或是跨站腳本攻擊(Cross-Site Scripting / XSS)。
範例一：
http://HOST/PATH/FILENAME.php/[弱點]
PHP的環境變數中，最為常見且風險性最高當屬$ _[‘PHP_SELF''] 。 $ _[‘PHP_SELF'']的語意相當特別，使用該變數之結果會獲得該PHP程式之路徑名稱及檔案名稱。同時，也容許添加斜線後再添加其他的內容。由於多數的開發者並不曉得這一點，所以常見的程式碼如下：
　　　
這段程式若被惡意攻擊者添加斜線及HTML語法或是JavaScript語法，則足以形成跨站腳本攻擊(Cross-Site Scripting / XSS)。
範例二：
http://HOST/PATH/[弱點]/
早期介紹Web應用程式安全性的文章，多數都會強調三種來自外部的資料—GET/POST/COOKIE (簡稱為GPC)需要特別過濾後才能使用；隨著Web 2.0時代的來臨，有一項很受歡迎的內容分類方式，tag。傳統上使用tag時，還是使用Request(GET/POST)來傳遞；目前則有越來越多的Web 2.0內容網站則是解析(Parsing)整個統一資源識別符(URI)，將其中的路徑名或是檔案名稱作為tag，目前線上的內容平台像是Blog、Album、Video Share…等等，使用tag為分類方式則已成為主流。但是對開發人員來說，URI的來源來自伺服器環境變數，並非傳統的GPC，以致多數的開發人員都忽略掉這是一個來自外部的資料，很可能受到了篡改，而惡意攻擊者則可以製作一個包含特殊語法的URI對應用程式做請求來達到特定的攻擊方式。

協同開發
單一專案多人開發，及單一人力參與多專案, 這些多人多專案的協同開發方式普及程度越高，則注重安全性的專案經理人越是擔憂。開發團隊中在招聘成員時, 往往是以特定領域的專業背景作為招聘與否的主要因素，甚少會以其產出原始碼之安全性作為參考依據。若以程式碼安全性作為人力素質之評量方式之一，那麼成員安全認知不足或是團隊安全認知不均確實是安全性難以確保的主因。
在此舉個筆者觀察到的現象，有時候在對一些網站做檢測時，可以發現大型且知名的入口網站絕大部份都有足夠的安全認知，其Web應用程式都有嚴格的把關其資料輸入與輸出，並將特定的中介字元(Meta-char)做安全化的轉換。但是，總有些許的功能或是模組會遺漏了安全檢查的動作。這說明了資安的認知從以前的不足，而現況則是不均；在此建議專案經理人，如何提升及確保開發團隊整體的資安認知, 可列為2007年年度目標之一。

源碼複用
新專案的成案，採用開放原始碼專案作為專案雛形(Prototype)以評估專案可行性，這在軟體業界早已不是新聞。但是評估人員的考量方向多數是功能導向式的思考，並未涵蓋開放原始碼專案之安全性。常常見到IT人員或是RD人員將開放原始碼專案修改成符合規格所需之軟體，卻沒有注意到新的專案也繼承了舊的安全缺陷而持續殘留。或是使用開放原始碼專案作為專案函式庫或模組，其所撰寫之Web應用程式本身相當安全，但是卻忘記對第三方函式庫或模組檢視安全性或是追蹤安全弱點並予以持續修正。

品質確保
Web應用程式安全作為專案品質管理的一部份，確保方式可分為教育訓練及開發輔助工具兩種方法。國內目前較為傾向採用教育訓練的方式，一來是以前確實沒有良好的開發輔助工具能夠同時確保品質及安全性，二來是教育訓練的成效較為難以量化，對開發人員來說，教育訓練較為輕鬆，亦可逃避專案經理人的監督。隨著軟體安全產業的進化，越來越多的工具廠商致力於整合專案管理，程式碼安全性稽核，及教具式導向開發工具。筆者認為教育訓練間隔過長，亦不易與軟體安全開發生命週期(SDLC)結合；教育訓練提升開發團隊安全認知，而工具則可以較短週期性來督促開發團隊的撰寫習慣，使其安全開發實務更為扎實，兩者相輔相成，不可偏廢。