密碼學與資訊安全 — 學習筆記之一
開發者是不是資訊安全的敵人？
最近在旁聽台大密碼學與資訊安全的課程，課程規定要看 10 篇指定文獻並撰寫心得，以此當作修課成績的其中一個評分指標，但是因為我是旁聽生，我沒辦法交作業，於是我決定把自己作業的報告寫在 Medium，一方面是統整上課重點，另一方面這週讀的文獻分享出來，因為讀完一篇以後覺得其實內容還蠻實用也不會太艱澀難懂，其實當作故事聽一聽還蠻有趣的，但如果要直接看文獻，用字有些還是蠻艱澀的，所以很多小細節我都會刪除。
The Developer is the Enemy
要解決的問題
一直以來，資安一直都是軟體開發 (Application Development) 相當重要的一環，之前，我們會對顧客行為做分析，這是因為他們把使用者 (user) 當作是資安問題的始作俑者，但是，我們覺得開發者 (developer) 才是資安問題需要解決的對象。
軟體使用流程可以分成三個角色，API (Application Programming Interface)開發者、App 開發者和使用者，現在的 App 開發者主要的任務就是把 API 提供的功能組裝起來，但是開發者不一定有資安相關的知識，因此，在使用 API 的同時，卻沒有辦法判別要選擇哪一種 API 會是比較安全的 (像是 AES 的加密模式)，而且有些 API 文件並沒有寫得很清楚，所以我們想，如果把資安這份功能，移到 API 開發者上，是不是就解決了這個問題？
這問題有很重要嗎？
安全性的問題是一定要解決的，但是 App 開發者通常不了解資安的問題，這邊舉 4 個例子。
- 要求新的 API 功能但是卻降低了安全性
有些開發者會要求取消 same-origin policy*，以用來跨網域存取資源，但卻降低了安全性。 - 選擇易用的套件和語言
常常在開發需求下，選擇好懂的或快速使用的套件跟語言，卻忽略安全性這一塊。 - 工作優先
在編譯的時候，通常為了把事情做完，而忽略或取消編譯工具提供的安全警告訊息。 - 不做弱點分析
花時間開發新功能跟花時間做弱點分析，App 開發者會直接忽略弱點分析這塊。
*same-origin policy 是指如果我想要跟後端要取資源，如果我們不是同個網域的話是不能存取的，也就是說，如果我的網域是 www.brady.com 是不能存取 www.paul.com 的資源，但是 www.brady.com/users 或是 www.brady.com/posts 是可以的。
提供的兩個稻草人*想法
- 資料標記(Data Tagging)
通常一個套件的 API 如果要考量到所有的情況，這個 API 可能會太過肥大，而且使用者可能不需要這麼多功能，所有如果我們把資料處理的時候，會附帶一些 tag 來註記這些資料需要的處理，舉例來說，有一些 template engine 會處理後端傳出來的資料，如果這個資料是需要自動轉譯 (autoescape )的，就會帶一個 escapehtml 的 tag。 - 不可壓制的警告訊息(Unsuppressible Warnings)
有些編譯器的安全警告訊息不應該要被壓制，我們建議可以把他改成 error 或者讓編譯器不會讓他執行來嚴格建立安全性機制。
*稻草人(straw-man)解法是指我把問題簡化或轉變成另一個問題，讓回答者更好回答或是反駁，有正面或負面的使用方式，這邊是正面的提出可能可以的解法。
結論
因為 App 開發者是負責 API 的組裝和呈現，關於資安的問題我們應該從更高層面下手，因為 App 開發者大部分不是資安專家，也就是說如果我們從基礎核心的 API 層面下手去解決資安的問題的話，可以把資安責任從 App 開發者中抽除，這樣不只可以降低 App 開發者的資安教育成本，也可以讓他們更專一的解決自己工作上需要處理的事情。
心得
這篇文章不得不說到我的感觸，因為我本身是功能傾向的開發者，有時候資安的問題是一個長期的效應，沒有辦法馬上給予開發者短期回饋，而我也不是資安專家，對於每一個功能需求背後的安全性並沒有直覺的了解，因此很容易忽略了資安的重要性。其中有一個質疑的點就是有些 API 開發者其實是 App 開發者來做的，也就是說如果 API 開發者自己也沒有資安觀念的話，其實做出來的 API 也是沒什麼安全性，但是文章中有提到他只會對很核心很通用的 API 進行增強，我認為如果由資安專家做個套件讓 API 開發者可以直接插入的話，就可以省下 API 開發者的負擔。
G. Wurster and P. C. van Oorschot, “The developer is the enemy,” in workshop on New security paradigms, 2008. & M. Green and M. Smith
Developers Are Not The Enemy! The need for usable security APIs
這篇的立場跟 The Developer is the Enemy 的立場是一樣的，都是希望把資安的責任分層往 API 端放，只是上一篇是希望大家以資安實踐面心態上去想，把責任放在 API 端會比較好，畢竟開發者有可能就是破壞資安的人！而這篇的想法是以資安心態來說，其實開發者不想把損害系統，但是有時候因為粗心和缺乏相關知識而犯了跟使用者一樣的錯誤，是另外一篇文獻 Users are not the enemy 的延續。
要解決的問題
想要解決因為 App 開發者的資安知識缺乏而造成的系統漏洞，根據文獻發現，開發者在遇到一個資安問題的時候，其實跟使用者一樣不知所措或不明就裡，造成了資安問題的產生。
這問題有很重要嗎？
有很多發布的應用程式雖然有使用加密套件，但是並沒有正確使用，造成系統 DoS (Denial of Service)或資安漏洞，非正確使用的例子像是
- 沒使用 TLS 認證
正常的情況會使用 TLS (Transport Layer Security) 協定來確保網站和後端服務的網路連線安全，TLS 是藉由認證來確保對方程式安全，然而大部分的應用程式並沒有通過認證，或是自己產生 TLS 驗證。 - 使用不安全的加密模式
有些加密模式是已經知道不安全了，但是因為缺乏相關知識，造成資訊外洩。 - 使用不安全的隨機數字產生器
通常要產生安全協定的時候，都會需要產生隨機號碼產生器，然而不是經過資訊安全-隨機產生碼是可能會有問題的。
提供加密 (crypto) API 的 10 個想法
- 直接整合加密 API 到標準 API，讓使用者不需要直接面對資安問題
- 盡量滿足有安全需求和沒需要安全需求的兩種 API
- 就算沒有資安背景也可以理解 API 的功用
- 不要讓開發者覺得 API 參數跟之前矛盾
- 就算沒有文件也可以很好理解
- 如果錯誤使用 API 會有明顯的錯誤警告
- 如果有預設值應該是安全的而且不能模稜兩可
- 測試環境如果要發佈時應該要警告
- 開發者的維護成本低
- 要給開發者建議錯誤發生如何解決問題
結論
此篇文獻跟上一篇站在相同立場，並提出更多明確的 10 個方法希望資安領域的人應該要如果去解決和時間現在軟體領域遇到的問題。
心得
我覺得這篇比上一片容易看多了，用字比較淺顯易懂，他的想法也合理，把資安問題往更高層面去解決，然而怎麼去驗證或統一全部的 API 讓他們擁有資安相關的防範還是需要蠻多心力的。
Green and M. Smith, “Developers are Not the Enemy! The Need for Usable Security APIs,” IEEE Secur. Priv., vol. 14, no. 5, pp. 40–46, 2016.
