www.fisc.com.tw ■ 15
淺談應用系統開發之安全強化〡本期企劃
淺談應用系統開發之安全強化
鄭鈞元 / 叡揚資訊股份有限公司資訊安全事業處專案經理
一、 前言
現行資訊安全強調縱深防禦,舉凡防火
牆、入侵偵測 /防禦系統、網際網路應用程式
防火牆、防毒閘道等,皆透過多層次安全防護
基礎設施,阻絕疑似攻擊的惡意訊息,使後端
伺服器面對的訊息,大多是來自真正使用者的
請求訊息。然而,由於應用系統所能接受的訊
息變異相當大,實難由一般安全防護系統透過
特徵或行為設定,阻絕所有疑似的攻擊,因
此,強化應用系統自身安全,仍為確保整體應
用系統安全相當重要的一環。
本文將以目前所面臨各種資安議題為
開端,續以軟體安全開發生命週期架構及
OWASP ( Open Web Application Security
Project ) Top 10說明,如何於應用系統開發
過程中,進行安全強化。
二、 資訊安全現況
「害人之心不可有、防人之心不可無」,
一語道破我們所處的數位世界。為確保金融
機構所提供之電腦系統具一致性基本系統安
全防護能力,並敦促金融機構遵循中華民國
銀行商業同業公會全國聯合會 (以下稱銀行公
會 )制訂之「金融機構資訊系統安全基準」及
「金融機構辦理電子銀行業務安全控管作業基
準」,銀行公會於 103年公布「金融機構辦
理電腦系統資訊安全評估辦法」,期透過各項
資訊安全評估作業,發現資安威脅與弱點,並
藉由實施技術面與管理面相關控制措施,改善
並提升網路與資訊系統安全防護能力。該辦法
將系統依其重要性分為三類,第一類因涉及直
接提供客戶自動化服務或對營運有重大影響之
系統,須每年進行資訊安全評估作業,第二類
及第三類則定期 (每 3或 5年 )依系統特性選
擇必要之評估作業項目;這些作業準則中包含
「資訊架構檢視」、「網路活動檢視」、「網
路設備、伺服器及終端機等設備檢測」、「網
站安全檢測」、「安全設定檢視」、「合規檢
視」。尤以針對「網站安全檢測」項目,要求
委外開發廠商或系統開發人員必須針對網站進
行滲透測試、弱點掃描、原始碼掃描或黑箱測
試等,確保系統交付時無任何潛在重大弱點
(Vulnerability )。
國內尚無任何針對科技企業所明訂之資安
規範,但企業已面臨全球銷售時須提供電子
設備資安證明之處境,如:通過 SANS/CWE
TOP 25規範。當物聯化的同時,民眾常無意
識地交出個人隱私資訊,該等資料也交由第三
方資料中介或開發商進行商業價值分析及統
計,犯罪集團又有了見縫插針之機會。因此,
如何保護個人資料成為重要課題,其關鍵技術
則包含資料密碼學 ( Cryptography )、去識別
16 ■ 財金資訊季刊 / No.88 / 2017.03
本期企劃〡淺談應用系統開發之安全強化
化 ( Tokenization )、資料遮罩 ( Masking )等。
新一代駭客透過組織運作就如同企業一
般有相對應職務,以 ATM盜領事件為例,
該組織分工細密,車手負責領錢、財務長負
責洗錢、程式研發人員負責撰寫惡意木馬程
式、品管測試人員確保木馬程式正常運作。
至於尚未浮出檯面的犯罪企業,不勝枚舉,
其以利益為優先而罔顧道德,駭客價值由此
而來。惡意攻擊皆有共同公式,攻擊 (Attack)
= 動機 ( Motive ) + 方法 ( Method ) + 弱點
(Vulnerability),對於動機我們無法防範,只
要有心人人皆可成為駭客,但弱點則可盡力避
免,透過源碼工具檢測、人工滲透測試,減少
系統弱點,縱深防禦,有效降低惡意攻擊。
對岸網軍曾多次入侵國內諸多單位,該
等受國家級專業訓練之駭客更是不能忽視,
戰爭早已非屬實體面,係數位戰爭 ( Cyber
War ) 之局。此類運作仰賴 1983 年 ARPA
( Advanced Research Projects Agency )
所研發的 TCP/IP 架構,初始設計時並未
料及遭惡意運用,故 OSI ( Open System
Interconnection Reference Model ) 7層架構
設計上並未包含資安保護機制,因此攻擊者便
可利用此特點竊取資料,並將所竊取之封包切
割傳輸,確保低流量運作躲避特徵辨識防禦設
備之偵測阻擋,直至蒐集完成後再重新組裝還
原封包,進一步竊取機密資訊。
2013 年 4 月 23 日下午敘利亞電子軍
(Syrian Electronic Army,SEA) 藉 由 Twitter
發布假消息:「白宮發生兩次爆炸,歐巴馬受
傷!」,瞬間造成美國股市暴跌,短短幾分鐘
內市值蒸發數億美元,股市交易如此快速反
應,不外乎交易系統蒐集並分析所有相關新聞
資料,透過語意分析、人工智慧決策演算法及
FinTech進行買賣交易媒合,造成大量賣出。
很難想像透過一則假消息,即造成比戰爭更可
怕之經濟損失!
三、 由 SSDLC著手之資安觀念
正如孫子兵法所云「知己知彼,百戰不
殆;不知彼知己,一勝一負,不知彼不知己,
每戰必殆」,為達目的,攻擊手一定竭盡所能
找出系統所有脆弱點,如何減少弱點即成戰役
勝出之關鍵要素,因此,於軟體開發生命週期
即須將安全元素融入;Cigital機構所提出之軟
體安全開發生命週期架構 SSDLC ( Software
Security Develop Life Cycle )如圖 1所示。
圖 1 Cigital SSDLC
www.fisc.com.tw ■ 17
淺談應用系統開發之安全強化〡本期企劃
(一 ) 需求面
首應探討相關資安需求,除對外界接服務
須透過加密傳輸,遵循單一登入準則 ( Single
Sign-On,SSO )外,同時更須加入一些惡意
使用情境 ( Abuse Cases ),如圖 2所示,係以
駭客角度使用系統分析可能造成問題之環節。
圖 2 Abuse Case
(二 ) 架構及設計面
嗣須瞭解及研議系統架構使用哪些底層關
鍵技術,以現今網頁開發而言,最新技術架構
為 MVC ( Model、View、Control ),對外服務
採用Web API;技術架構須考量威脅來源,亦
即誰來使用Web API?爰此,為防範不法,
使用時須先登記註冊,並加以記錄稽核軌跡。
(三 ) 測試計畫
測試就軟體開發而言,係程式偵錯及確
保品質不可或缺之程序,因此,審慎撰擬測
試計畫,除針對每項功能進行單元測試外,並
依據惡意情境傳入測試資料,以檢視系統是否
受影響,乃絕對必要的;如 SQL Injection、
Command Injection、Cross Site Scripting 測
試腳本。
(四 ) 撰寫程式
程式撰寫過程中,透過源碼檢測工具 (如
圖 3所示 )隨時進行 Code Review,藉由工具
舉報弱點程式碼,如此可讓開發人員於開發過
程中,及早處理資安相關問題程式碼。
18 ■ 財金資訊季刊 / No.88 / 2017.03
本期企劃〡淺談應用系統開發之安全強化
圖 3 源碼檢測工具
(五 ) 測試及其結果
依據測試計畫針對已完成之功能執行測試
作業,其中包含單元測試及整合測試或滲透測
試,並提報測試結果。由於滲透測試須由專業
資安人員長時間執行,爰此,為考量成本及作
業時間,通常安排於系統功能完備後始進行滲
透測試。
(六 ) 回饋相關資安弱點
於軟體安全開發生命週期中,開發人員
依據測試人員所回報之測試結果進行後續修
正後,再送請測試,測試結果若不如預期,
則再修正後送測,如此反覆循環,弱點數量
也隨之持續減少,現今可透過 CI ( Continue
Integration )工具整合自動化作業,減少人工
負荷,藉由 SSDLC紮實導入,有效減少系統
弱點。
四、 從 OWASP TOP 10談安全程式教戰守則
OWASP係專門研究網站應用程式弱點之
國際組織,歸納開發人員常犯之前十大弱點,
本章節以 .NET程式為範本說明之。
1. A1. Injection
即注入式弱點;包含 SQL Injection、
Command Injection、XML Injection、
LDAP ( Lightweight Directory Access
Protocol ) Injection等注入式攻擊手法,
SQL Injection簡言之,即程式碼 SQL語
法字串將傳入之變數作為條件組合引發問
題,以登入網頁為例,輸入使用者帳號及
密碼,並傳入 SQL語法組合,如圖 4所
示。
www.fisc.com.tw ■ 19
淺談應用系統開發之安全強化〡本期企劃
由於輸入介面上並無任何驗證處理,當
攻擊者發現此弱點,即輸入一串不當資料,
如圖 5所示,於使用者帳號欄輸入 「John' or
'1'='1」字串,組合結果 SQL命令為可執行恆
圖 4 SQL程式碼
等式成立 ( '1'='1' )語法,此情形下即使密碼
輸入錯誤,也可正常登入運作,避開帳號密碼
驗證程序。
圖 5 SQL Injection程式碼
續行進階攻擊,利用 Second Order SQL
Injection取得權限提升或變更系統管理者密
碼,甚至摧毀資料庫造成重大影響。對於程式
開發者而言,處理 SQL Injection有多種作法
可選用,如:參數化查詢、濾除 SQL溢出字
元等皆可避免此弱點,至於其他 Injection處
理方式,亦勿輕信資料來源,可使用白名單或
黑名單方式進行過濾驗證。
2. A2. Broken Authentication and Session
Management
此謂身分驗證及 Session管理缺失;
早期設計為防忘記密碼,可以提示方式告
知,即系統要求使用者輸入最喜愛的「臺
20 ■ 財金資訊季刊 / No.88 / 2017.03
本期企劃〡淺談應用系統開發之安全強化
灣城市」,由於臺灣城市屈指可數,無論
輸入何者,皆極易猜得提示答案,並取
得正確密碼,造成身分驗證之缺失弱點,
因此建議採用 two factor authentication
(2FA) 加強驗證安全,亦即至少包含以下
任兩種認證因子:
• Something you know:身分證字號、密
碼、出生地及使用者所知道的其他事項。
• Something you have:動態密碼鎖、鑰匙、
晶片卡及使用者所擁有的其他事物。
• Something you are:性別、指紋、視網
膜及使用者天生的其他特徵。
密碼存入資料庫須以雜湊 ( Hash )單向加
密方式儲存,確保密碼隱密性不可被破解,通
常開發人員易於忽略雜湊加密須加 Salt (特定
字串 ),如圖 6所示,經過 Salt變化即使輸入
密碼都是廣泛適用之 bob,但雜湊後的結果卻
不同,避免駭客使用字典檔方式破解密碼。
圖 6 Hash with salt
Session 用以記錄有關網頁之狀態資
訊,當登入系統後,Session ID 即記錄於
Cookie中,如登入系統後 Session ID維持
不變,攻擊者可透過釣魚網站方式誘騙使用
者連入,藉此透過 Script抓取 Cookie並取
得受害者 Session ID,如圖 7所示,攻擊者
即利用固定 Session ID ( Session Fixation )
成功進入系統。因此,程式開發者須嚴加保
護 Cookie,可使用調整系統設定檔 ( web.
config )將 httpOnlyCookies設定為 true之方
式,讓 JavaScript無法讀取 Cookie,避免遭
釣魚網站竊取。此外,可於 Cookie傳輸過程
將 RequireSSL設定為 true,並設定 Session
timeout時間 (建議以 15分鐘為上限 ),在使
用者登入成功後,立即更換 Session ID以避
免固定值問題,如圖 8範本程式碼。
圖 7 固定之 Session ID造成問題
www.fisc.com.tw ■ 21
淺談應用系統開發之安全強化〡本期企劃
3. A3. Corss Site Scripting (XSS)
即跨網站腳本攻擊;只要是網站型應用
系統,大都會發生此弱點。由於執行攻擊者
已先於具此弱點之網站注入惡意腳本程式碼
(Script ),通常為 JavaScript語言,當使用者
造訪是類網站時,瀏覽器即讀取惡意腳本程式
碼執行,竊取用戶的 cookie。前曾提及若允
許 JavaScript存取 cookie,則 Session ID易
被抓取致使用者身分遭冒用,甚至可利用鍵盤
側錄 ( key log )將重要輸入資料記下,該弱點
可分為下列兩種類型:
(1) Reflected XSS
當直接於畫面輸入腳本程式碼,網頁立
即受影響,例如:「全文檢索」為供輸入之
文字框,當輸入資料為 <script>alert ( 'XSS
Testing' )</script>,具 XSS弱點之網站即直
接顯示對話框XSS Testing訊息,如圖9所示,
再進一步檢視網頁原始碼,即可發現所輸入之
內容被嵌入程式碼,如圖 10所示。
圖 9 引發 XSS弱點測試
圖 8 登入後更換 Session ID
22 ■ 財金資訊季刊 / No.88 / 2017.03
本期企劃〡淺談應用系統開發之安全強化
(2) Stored XSS 或稱 Persistent XSS
腳本程式碼透過資料庫或檔案進行儲存,
後經存取進行攻擊,例如:留言板功能,或是
部落格之類的網站,其資料來源為資料庫,攻
圖 10 檢視原始碼內容顯示 JavaScript程式碼
擊者若利用惡意腳本內容,如圖 11所示,並
存入資料庫,當使用者觀看留言板時,自資料
庫所讀取者即惡意程式碼,肇致使用者執行惡
意程式碼。
圖 11 於留言板上注入鍵盤側錄惡意腳本程式
www.fisc.com.tw ■ 23
淺談應用系統開發之安全強化〡本期企劃
4. A4. Insecure Direct Object References
即不安全的物件參考;當設計上傳檔案功
能的網頁時,如不限定其上傳檔案類型,攻擊
者易將惡意程式傳入系統,並透過釣魚信件方
圖 12 微軟內附 AntiXSS
式將此惡意 URL ( Uniform Resource Locator)
提供予受害者 (如圖 13所示 ),若受害者未注
意信件的連結網址是惡意程式,一旦執行即遭
攻擊。
圖 13 不安全的物件參考惡意程式
另一類常犯問題為下載路徑參照,提供
下載檔案頁面並以參數設定路徑及下載檔
案, 例 如 http://mywebsite.com/download.
aspx?fn=userguide.pdf,對攻擊手而言,將
fn參數改為 http://mywebsite.com/download.
aspx?fn= /web.config,即可操控路徑 ( Path
Traversal )回至根目錄下抓取系統設定檔案,
竊取設定檔的資料庫連線密碼、帳號等資訊。
5. A5. Security Mis-configuration
即安全上設定錯誤;一般而言,系統出廠
皆附有系統設定頁面且其為「預設值」,然使
由此可見,不論何種類型之 XSS都須
加以防範,對開發者而言,僅須懂得其中原
理即易於解決,以 .NET開發平台為例,微
軟公司提供「AntiXSS處理」以對應 XSS
問 題 ( 如 圖 12 所 示 ), 如:HtmlEncode、
JavaScriptEncode、⋯等,其中 HtmlEncode
即將「<」字元轉換為「<」;以及使用其他
字源轉換,避免惡意腳本程式碼之輸入。
24 ■ 財金資訊季刊 / No.88 / 2017.03
本期企劃〡淺談應用系統開發之安全強化
6. A6. Sensitive Data Exposure
是謂機敏資料暴露;正如於 A5所述,將
系統錯誤訊息包含資料表結構呈現於畫面上,
以及密碼在傳輸過程中使用明碼方式傳遞時,
駭客透過封包竊聽,造成機敏資料外洩。使
用者一旦經由手機 App同意使用條款,App
即存取其定位資訊、Gmail以及 Google doc
的資料給予廣告商,開發商利用使用者安全
意識薄弱,即可輕易獲得個人重要機敏資料。
然而,大多數人尚不理解該等無價資料最後
「一定」遭洩漏,因此,對於定位資訊及個
資須加以保護,避免自主性外流,對開發者
而言,該等敏感的機密資料須以加密、資料
遮罩、去識別化方式予以保護,尤其現行處
於大數據 (Big Data)環繞的世界,更須謹慎
處理個資相關事項。
7. A7. Missing Function Level Access Control
此即缺乏功能層級的存取控管;是項弱點
對於駭客而言乃自動上門之最佳良機,無須繁
雜耗時破密分析,即可直接獲取權限提升。例
如,本應為提供予具系統管理權限者之管理頁
面,因未驗證使用者角色,只須透過 URL即
可進入,此為 Forced Browsing,上述所提及
web.config透過操控 path即可進行存取,亦
屬相同問題。
圖 14 未配置錯誤處理頁面呈現系統錯誤資訊
用者通常會忽略而未予修改。以路由器或網路
監視器為例,設備出廠之預設帳號及密碼皆是
admin,若使用者未更換密碼,極易被猜中,
再加上大多設備都未要求使用者第一次登入時
必須更改預設密碼,真可謂門戶洞開,或許直
至網路監視器鏡頭隨意移動時才發現大事不
妙!網站應用伺服器常犯的失誤是將錯誤訊息
顯示在畫面上,對開發人員而言雖為極佳除錯
方式,然未配置錯誤訊息對應頁面,導致錯得
越多駭客即獲取越多資訊,其中包含資料表的
名稱及結構,如圖 14所示。
www.fisc.com.tw ■ 25
淺談應用系統開發之安全強化〡本期企劃
圖 15 跨網站偽造請求轉帳風險
顯然攻擊者已先研究妥網銀轉帳所需具備
的參數值,才有機會下手,為防範不法,現今
網銀都已增加幾道防禦措施,包括:使用圖形
驗證碼並要求使用者再次輸入密碼,再加上
輸入 OTP簡訊動態密碼以為驗證。ASP.NET
MVC架構已提供 Html.AntiForgeryToken方法
可防禦此類攻擊,但前提是網站沒有 XSS弱
點且 Token不可被窺及,若發生具 XSS弱點
之系統產生隱藏欄位,Token值仍會被竊取,
造成防禦上失效。
9. A9. Using Components with Known
Vulnerabilities
此係使用已知弱點的元件;對開發者而
言,使用 Open Source (開放源碼 ) 可利用已
撰妥之現成程式碼,減少開發時程,但使用前
卻忽略思考下列事項:該等 Open Source本
身是否為 CVE ( Common Vulnerabilities and
8. A8. Cross-Site Request Forgery (CSRF)
即跨網站偽造請求;早期網銀轉帳交
易設計通常包含 3個重要參數:轉出帳戶
(Account)、金額 ( Amount )及轉入帳戶 ( To ),
如其 URL為 http://RichBank.com/Transfer.as
px?Account=User1&Amount=10,000&To=Us
er2 即完成一筆轉帳交易,駭客若知此三個關
鍵參數之運作原理,且若使用者尚未登出網
銀,駭客只要發送內含圖示標籤為 <img src="
http://RichBank.com/Transfer.aspx?Account=
User1&Amount=10,000&To=hacker"> 之釣魚
信件給受害者,當使用者一開啟信件,網銀即
進行轉帳給 hacker,如圖 15所示。
26 ■ 財金資訊季刊 / No.88 / 2017.03
Exposures ) 網站公告之弱點?是否提供更
新?甚至,是否提供維護?如其開發商仍持續
維護並定期更新修復弱點之版本,則尚可考慮
使用,天下沒有白吃的午餐,使用前最好透過
源碼檢測工具再次掃描,以確保安全。
10. A10. Unvalidated Redirects and Forwards
即未經驗證導向;網站系統常使用
Redirect或 Forward到其他頁面或至其他網
站,且可能透過參數控制進行導址動作,譬如
某系統原設計以 Email提醒客戶定期更換密
碼,其連結 URL 為 http://xyz.com/Account/
logon.aspx? returnUrl =update.aspx,而攻擊
者依樣偽造一封提醒使用者定期更換密碼之郵
件,但 returnUrl之連結網址被修改為 http://
xyz.com/Account/logon.aspx? returnUrl=
http://hacker.com/loguserinfo.aspx, 使 用 者
一旦登入後,即被轉到駭客網站中,攻擊者可
藉此蒐集使用者之敏感資訊,因此在開發及設
計上,儘量避免使用 Redirect及 Forward,並
建立一份允許範圍內之驗證轉址URL白名單。
五、 結語
撰寫一套系統是件不簡單的事情,以國內
仍為不健全的軟體開發環境為例,大多數開發
人員早就過勞,又因責任制、薪資少、一人當
多人使用,種種不優的條件束縛下,系統能
如期上線已屬萬幸。至於資安上的議題,則完
全缺乏足夠的時間、充沛的精力或清晰的腦力
可加以思索,時有漏洞百出之憾,且直至透過
工具檢測發現時,通常已接近完工上線階段,
其後續資安問題之修正更是棘手、費心思,輕
者只須加入安全函式,重者甚且須重新打造。
以網路銀行為例,動輒幾百萬行的程式碼,須
顧及每行都完美不出錯,最後修正缺漏所花的
人力成本實難以估算。然,「只要是軟體就可
能出錯」乃眾所周知,所謂系統須達零問題、
零風險始得上線的思考方式,已難容於現實,
畢竟系統是「人造」的,「無懈可擊」是理
想,因此,任何企業或單位對於安全軟體開
發,務求從本質著手,儘量減少先天上的漏
洞,藉由於軟體開發生命週期即將安全納入考
量,以及透過教育訓練將資安觀念灌輸給系統
開發人員,資安訓練相關國際機構,包含 EC-
Council、ISC²、SGS等,皆備有課程供參與;
嗣於開發過程中,透過工具檢測及早發現瑕
疵,予以修正,如此方為強化應用系統安全之
最佳實務。
※參考文獻 /資料來源:1. Building Security Into the SDLC
Without Impacting Velocity,https://www.cigi ta l .com/blog/bui ld ing-security-into-the-sdlc/。
2. AP Twitter account hacked, makes false claim of explosions at White H o u s e, h t t p : / / w w w. t h e v e r g e .com/2013/4/23/4257392/ap-twitter-hacked-claims-explosions-white-house-president-injured。
3. OWASP Top-10 2013,https://www.owasp.org/index.php/Top_10_2013-Top_10。
4. EC-Council CEH V9教材。5. 金融機構辦理電腦系統資訊安全評估辦法,銀行公會。
6. Marc Goodman著,林俊宏譯 (2015),未來犯罪:當萬物都可駭,我們該如何
面對,木馬文化事業股份有限公司。
本期企劃〡淺談應用系統開發之安全強化