淺談應用系統開發之安全強化 - fisc...16 財金資訊季刊 / no.88 / 2017.03...

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



(一 ) 需求面

首應探討相關資安需求，除對外界接服務

須透過加密傳輸，遵循單一登入準則 ( 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所

示。



由於輸入介面上並無任何驗證處理，當

攻擊者發現此弱點，即輸入一串不當資料，

如圖 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造成問題



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　於留言板上注入鍵盤側錄惡意腳本程式



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

即將「<」字元轉換為「&lt」；以及使用其他

字源轉換，避免惡意腳本程式碼之輸入。

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所示。



圖 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)，未來犯罪：當萬物都可駭，我們該如何

面對，木馬文化事業股份有限公司。


淺談應用系統開發之安全強化 - fisc...16 財金資訊季刊 / no.88 / 2017.03...

Documents