Categories
程式開發

聊聊軟件的安全問題


聊聊軟件的安全問題 1

現狀:過多的“馬後砲”

當前,關於計算機系統的安全討論很熱,無論是數據洩露,還是DDoS攻擊,亦或是system hijacks等都為這個話題貢獻了熱度。與之相應,宣傳銷售間諜程序、防火牆等相關的安全公司在增多,並且,對“網絡安全專業人士”的需求也在不斷上漲。

雖然這些安全防護措施或許“物超所值”,但仍有不足:很大一部分的安全防護是在系統搭建完成後才添加的。如果服務易受攻擊?沒問題,加一個入侵檢測系統來識別和過濾那些企圖利用漏洞入侵的網絡數據包。

無疑,這種做法很有吸引力,但可惜沒啥作用。

正如計算機安全專家在60年代強調的,真正的安全要從系統設計構建時就開始考慮。等到系統部署完成後,這時才添加的安全措施有點像“馬後砲”。

讓安全成為軟件開發必需的一部分

從開始就融入安全考量,現在有很多方法,例如“BSIMM(軟件安全構建成熟度模型)”。 Synopsys和Veracode提供能篩查安全漏洞的代碼分析產品。微軟的“安全開發生命週期”、Gray McGraw的《軟件安全:讓安全成為軟件開發必需的部分》和Sami Saydjari發布的《可信系統工程》,這些指南均為如何設計、開發更好的系統指明道路。

這些方案都很不錯,但還需要更重視軟件開發過程中的安全性。

因此,我們需要更好的教育和訓練。

聊聊軟件的安全問題 2

今天,很多人重視性能,但仔細想想,安全難道和性能表現不是同等重要嗎?

越來越多方便上手的腳本語言證明運行表現的重要性,而安全的重要性或將在日後得到證明。不可否認,很多安全漏洞本意是為良性環境編寫的代碼,最終卻被應用到易被攻擊的敏感環境中。因此,在討論如何提升代碼效率的同時也應經常提到代碼的安全性。

一種可行的思路是,當開發者關注程序正確性和有效性的同時,應嘗試在目標環境中編寫程序。但這樣還稱不上安全,開發者寫的代碼必須能在所有環境中安全運行。

因此,無論是學生,還是普通的開發者都要搞清楚:程序中的bug如何被當做安全漏洞實施攻擊,以及如何阻止類似漏洞產生。

安全漏洞

緩衝區溢出,它指當計算機向緩衝區內填充數據位數時超過緩衝區本身的容量,溢出的數據覆蓋在合法數據上,以及因此帶來的棧緩衝區溢出攻擊(smashing the stack)。

這類攻擊包括緩衝區溢出攻擊和命令注入攻擊(command injection)。它們都具備的一大特點是:

黑客欺騙程序將本應做為數據的輸入當作是代碼,並進一步執行這些惡意代碼。

針對網頁程序的弱點和對應的攻擊方式,包括SQL注入攻擊、跨站腳本攻擊(XSS)、跨站請求偽造(CSRF)。

這類攻擊的共同點和之前一樣,都是黑客通過誘騙易受攻擊的程序,將有問題的數據當作代碼。這些代碼可被用於劫持程序,盜竊機密,或是破壞重要信息。

代碼防護

現在,關於大部分類似漏洞的防護措施都是針對“ a high level”。例如,在使用任何不被信任的輸入前進行驗證,確保輸入數據的大小不會超過緩衝區容量,以此保證程序安全。

對前文提到的其他四種攻擊,存在漏洞的程序會在piecing另一程序時一併執行惡意命令代碼。舉個例子,假設有個應用程序想得到用戶的用戶名和密碼作為輸入,然後splicing這些用戶名和密碼到一個SQL可查詢數據庫的模板程序裡。不過,某些用戶名或密碼可能包含SQL命令,導致程序執行與查詢本意不同的命令。

聊聊軟件的安全問題 3

這種情況在構造shell命令或JavaScript或HTML程序(跨站腳本攻擊)時都會遇到。這些攻擊的防範措施同樣針對“ a high level”,例如過濾潛在危險數據。

本文作者提到:目前,大多數計算機安全課程都會側重漏洞利用,但重點可能在於如何修復應用程序中的安全漏洞。他用了這樣的方法:給學生一款Ruby編寫的有多個漏洞的Web應用程序,學生要在不破壞其核心功能的情況下修復這些漏洞。然後,根據自動評分系統對這些修復方案的功能性和安全性評分,並測試原有漏洞是否被修復。學生必須通過修改程序使其通過測試。

底層控制的安全

事實上,最危險的漏洞類型莫過於遠程代碼執行漏洞(ACE),它允許攻擊者在目標系統上執行任何代碼。類型不安全的語言(C/C++)中薄弱的內存管理機制會導致很多漏洞,諸如ACE、釋放後重引用(UAF)、二次釋放和緩衝區溢出。

根據MITRE的通用弱點枚舉(CWE)數據庫,緩衝區溢出漏洞仍然是當今最大的漏洞類別

用類型安全的語言(如Java)編寫的程序不會受到這類內存錯誤的影響,因此消除了很多漏洞。

注:這一點並不完全對,因為用Ruby或Rust編寫的程序仍有部分是通過調用C/C++的外部函數接口實現的。儘管如此,不使用C/C++作為日常編程語言仍可以減少被攻擊的可能性。

但是,這些類型安全的語言會使用抽像數據表現形式和Garbage Collection。這雖然讓編程變得更容易,消除底層控制,但同時也增加了有些“難以承受的開銷”。

儘管無法容忍the overhead 和缺乏控制,C/C++實質上仍是操作系統、設備驅動程序、嵌入式設備的唯一可選項。

現在,這些系統受到攻擊的概率和頻率不斷增加,我們應該做什麼呢?

Rust:不用GC的類型安全語言

2010年,Mozilla公司開始了一個野心勃勃的項目:開發一門針對高性能程序的安全編程語言。這個項目為我們帶來Rust。

Rust的開發始於2006年,但最初Mozilla並不支持Rust。

在Rust中,類型安全( type-safety)通過各種警告保證程序不會出現內存錯誤以及free of data races,而這種類型安全的保證不需要garbage collection(GC),在這一點上,其他任何的主流編程語言都做不到。

2019年2 月初,微軟一次演講中提到,70% 的安全漏洞都是內存安全問題。此後 7 月份,微軟安全響應中心(MSRC)發文表示:微軟需要更安全的系統編程語言。此後的系列文章中,微軟對自己為什麼認為 Rust 語言目前是業界的最佳選擇做了闡述。而在近日,微軟透露了使用 Rust 代替 C/C++ 編寫 Windows 組件的實驗感受,工程師們直言使用 Rust 語言的感受妙不可言。

我的任務是對Windows 代碼庫的一個低級別系統組件進行實驗性重寫(目前不能透露是哪個組件),雖然這個項目還沒有完成,但總的來說,在Rust 方面的試驗體驗是非常好(generally positive)。新的組件或現有的具有乾淨接口的組件移植到 Rust 是很容易的。

軟件安全必須作為開發的必需部分。同時,未來開發人員關於軟件安全性的教育培訓將為提高安全觀念邁出重要一步。

英文原文:

http://www.pl-enthusiast.net/2018/08/13/security-programming-languages-issue/