最近讀了一篇文章,談論到QADevelopers通常由於時程上的壓力以及沒有得到管理階層下達應用程式必需確保安全性的指令,常常將安全性議題延置在上線後有需要才進行補救,但應用程式安全應該要做到在一個app開始開發之前便開始積極考慮,於是文章提出十件事告訴我們在專案開始到上線有哪些關於應用程式安全的事情可以去做。

 

  1. 在專案開始時建立Threat Modeling:在程式開始開發之前,我們應該思考一個attacker可能會有哪些不同的攻擊app方式,通常,我們會用圖形化的方式把資料流以及資料儲存方式等等系統流程與特性表現出來,然後從中思考會有哪些threat,例如:我是攻擊者在看到這資料流之後要如何破壞它?要儒何可以偷取資料?透過這圖形化的Threat Modeling,可以預先考慮到一些可能的app潛在安全威脅。
  2. 定義基本安全需求:開發時必需考慮基本的應用程式安全項目,包括:Role Management, authentication 以及password-based access control。其中"角色管理"是指定義使用者可以看到哪些資訊,對於他們可看到的資訊又應該可進行哪些操作。在定義好這些基本需求之後,便必需為其設計架構以及在程式開發過程被包含。而針對使用者又會遇到一些權限不同的狀況,此時我們採取的策略應該是"instill a philosophy of least privilege",也就是我們在設計各角色權限之初,必需假定所有角色都是一律平等,沒有特權(privilege),只有當遇到某角色需要被開放哪些必要權限時才開放給他,不能多給,但也不能不給,這是在定義角色的時候的一個安全原則。
  3. 找出應用程式可能被誤用的所有Abuse Cases(濫用案例):在我們與使用者談應用需求之初,通常我們都只列出所謂應該要做到APP中的需求清單,但其實還有另一個重要清單是"因為安全性而不能做到APP的限制清單",後面這一個卻往往都被忽略。為了找出這樣的清單,我們應該考慮在要做需求清單中,有哪些Use CaseScenario可能會被濫用或誤用而造成應用程式的安全漏洞,這一類的scenario即是所謂的Abuse Cases,也就是當我們要幫使用者做一個功能時,同時要考慮這個功能是否可能會被濫用,若發現會有安全上風險,則必需列出限制條件以防止出現安全問題。例如:主管想從HR系統"看到自己的部屬"的基本資料,但"不應該能看到其他主管之下的部屬",後者即是考慮安全性而加上的限制。
  4. 定義驗證輸入的規則:定義一些規則防止一些不合法的輸入造成系統崩潰或出錯。
  5. 使用Source Code Analyzers: 我們可以在程式寫好時使用原始碼分析器去找出是否程式中存在某些弱點會造成資料被偷竊。
  6. 引導Developers寫出安全的程式碼:其實不是每個Developers都有安全性的概念或知識,因此我們可以透過提供Common Secure LibrariesDevelopers使用共用的安全性功能實現公司的基本應用程式安全需求並且提供功能的一致性。
  7. 使用Dynamic Scanner來模擬程式遭攻擊Dynamic可找出程式中任何可能被attacker用來攻擊的弱點跟方式,例如是否存在SQL Injection的威脅。
  8. 測試的環境應該盡量接近Production:如果在該測試環境中資料存取是安全的,那在production便應該是安全的。
  9. 測試程式的回復能力:找出程式任何可能造成系統中斷的點,並測試是否程式可以主動修復這類錯誤。如:程式發生網路中斷,是否可以自行回復?
  10. 在基礎原則上持續測試程式安全性:即使程式已經上線,仍然要在既有安全性的基礎上進行測試,因為”New security vulnerability come up all the time”。

 

  以上十點是我在看過那篇"Ten Ways to Build In Sevurity From the Start"文章後用自己的話所寫下來的描述。這些項目基本上揭視了一些加強應用程式安全性的方法在整個程式專案之中,這其實也似乎並沒有想像中地高門檻,當我們思考一些安全性問題時。

 

  其中也有一些很有趣的觀念應該注意,包括Role Management以及Abuse Cases,這些都有助於幫助我們找到真正觀鍵的安全問題,而其不足之處,或可再透過Source Code AnalyzersDynamic Scanner找出技術上的盲點,後面8.9.10三點則是透過測試的觀點達成App的可靠度,使程式更加穩定。

 

2014618日星期三 12:26 PM

 

arrow
arrow

    jackterrylau 發表在 痞客邦 留言(0) 人氣()