安全軟體開發入門(教程)
阿新 • • 發佈:2018-12-31
軟體安全問題
有趣的《黑客帝國》終極解釋:
《黑客帝國》故事裡面的人物關係,就像電腦裡面的各種程式的關係一樣:
電腦裡面的系統程式:Matrix;
病毒程式:以Neo為首的人類;
防病毒軟體:Agent特工、機器章魚、先知(迷惑和引導病毒程式的);
以及出錯程式:Smith和Merovingian。
第一集:病毒程式入侵Matrix,喚醒被隔離的病毒原始碼Neo,並通過破壞Agent特工這些防毒軟體取得控制部分機器系統的勝利。
第二集:講述Matrix系統通過蒙騙的方法將Neo等病毒程式碼或受感染的程式收集引導到一個Zion區域,進行防毒,結果在片尾,病毒程式Neo意識到了這一點。
第三集:Matrix系統軟體通過利用Agent防病毒軟體和Smith出錯程式來對付Neo這些病毒程式,並且成功地消滅了這兩方,達到系統防禦能力升級。
其實故事一開頭就註定了Neo的悲劇結局和人類的失敗。因為病毒如果最後導致系統崩潰,病毒也將被消滅。所以病毒要不被系統消滅,要不導致系統崩潰,和系統一起滅亡。
軟體安全問題的根源:
內因:軟體有錯誤
* 脆弱點
* 缺陷(設計層)
* Bug(實現層)
* 軟體開發方法存在問題
外因:軟體的執行環境
* 網路對軟體的發展產生了巨大的影響(負面居多)
外部環境:黑客、惡意程式碼
內部環境:誤操作、報復、經濟犯罪
7+1的軟體安全問題領域:
1.輸入驗證和表示法
2.濫用API
3.安全特性
4.時間和狀態
5.錯誤處理
6.程式碼質量
7.封裝
*.環境
1.輸入驗證和表示法
輸入驗證和表示問題由元字元、替換編碼、數字表示法引起。如果選擇使用輸入驗證,那麼就要使用白列表、而不是黑列表。
由於輕信輸入而造成的大問題包括:緩衝區溢位、跨站指令碼攻擊、SQL注入、快取毒藥和其它指令碼小子們非常輕易吃到的“低掛的果實”(這裡只安全性較低的軟體設計)。
2.濫用API
API規定了呼叫者和被呼叫程式之間的使用約定。濫用API的常見模式是由呼叫者錯誤地信任被呼叫方造成的。例如,呼叫者希望從被呼叫程式那裡返回獲取使用者資訊,而被呼叫程式並沒有任何的安全性保證其資訊的可靠性。於是呼叫者就假定了呼叫程式返回資料的正確性和安全性。當然,也存在“壞人”有意破壞呼叫者-呼叫程式之間約定的行為。
3.安全特性
軟體安全不是安全軟體。世界上所有的加密演算法都不能滿足真正的安全需要。儘管使用SSL保護網路流量的手段,而認證、訪問控制、機密性保障、加密演算法、許可權管理等都可能存在著安全缺陷。
4.時間與狀態
分散式計算與時間和狀態相關。為了使多個元件進行通訊,狀態必須在元件之間共享,而所有這些都需要花費時間。因此在時間和狀態之間可能存在著巨大的、未發現的天然攻擊資源。
多數開發者人格化了他們的工作(將程式看作“它”的單體)。他們自以為單一、全能的控制執行緒能夠孜孜不倦地日夜工作,以同一種方式支撐整個應用。而現代計算機在任務之間切換速度與日俱增,並且多核、多CPU或者分散式系統的應用使兩件事情完全可以在同一時間發生。因此缺陷便出現在開發者所設想的程式執行模型和實際情況之間的差異中。這些缺陷與線上程、程序、時間和資訊之間的無法預期的互動相關。而這些互動往往通過共享狀態發生:訊號、變數、檔案系統、全域性資訊等。
5.錯誤處理
如果想破壞軟體,那麼就讓它丟擲一下垃圾資料,並看看你導致了哪些錯誤。在現代面向對系統中,異常的想法取代了被禁止的goto概念。
與錯誤處理相關的安全缺陷在開發中很常見。在API被濫用的情況下,安全缺陷主要存在於兩種方式:第一,開發者忘記處理錯誤或者粗略得處理錯誤;第二,在產生錯誤時要麼給出過於詳細的資訊,要麼錯誤過於太具放射性以至於沒有可處理它們的方式。
6.程式碼質量
安全是可靠性的子集。如果可以完整地描述你的系統和其存在的正面、負面的安全可能性,那麼安全成為了可靠性的子集。劣質程式碼將導致無法預期的行為,從軟體使用者的觀點,它將被認為是很差的可用性;而從攻擊者的視角看,糟糕的程式碼將提供給系統施壓的可乘之機。
7.封裝
封裝是指在事物之間的邊界和它們之間建立的界限。在web瀏覽器中,它確保了移動程式碼不能夠強行我們的硬碟攻擊。在web服務端,它意味著在經過認證的有效資料和私密資料之間的差別。這裡的邊界非常重要,如今在類之間的一些方法構成了重要的邊界,因此信任模式需要謹慎的設定。
8.環境
這是上面七種領域的外部領域,它包括在程式碼外部的所有東西,並對於我們建立的軟體安全同樣重要。
十大web安全問題:
1.未驗證輸入
問題描述:web 請求資訊在被Web應用使用之前都是未驗證的,攻擊者能夠利用其中的弱點攻擊伺服器;攻擊者通過偽造HTTP請求的各個部分,例如URL,查詢字串,頭,cookies,表單域,隱藏域等繞過站點的安全機制。
這些常見的偽造輸入攻擊通常包括:強制瀏覽,命令插入,跨站指令碼,緩衝區溢位,格式化字串,SQL注入,cookie中毒,隱藏域操作等等。
保護方法:過濾惡意輸入;客戶端輸入驗證、伺服器端驗證。
2.破壞訪問控制
問題描述:對認證使用者能夠進行的操作缺乏合理的限制。攻擊者利用其中的缺陷訪問其他使用者的賬戶,瀏覽敏感檔案,或使用未授權的功能。
保護方法:
加強對會話的保護(會話ID);
防止暴力瀏覽繞過訪問控制檢查;
合理設定訪問許可權;
禁止客戶端快取。
3.破壞認證和會話管理
問題描述:賬戶信用和會話令牌沒有被合理保護,攻擊者能夠危及密碼、金鑰、會話cookies或其他限制而冒用他人的賬戶
保護方法:
加強密碼強度;
限制登入次數;
使用SSL保護傳輸中的認證資訊;
使用SSL保護會話ID;
禁止客戶端快取。
4.跨站指令碼缺陷
問題描述:web應用能被利用將攻擊轉送到端使用者的瀏覽器。成功的跨站攻擊能夠暴露使用者的會話令牌,攻擊本地計算機或者用虛假資訊欺騙使用者。
保護方法:
對使用者提供的輸出進行編碼;
根據白列表,嚴格驗證查詢字串;
過濾、清除頁面請求中的活動內容。
5.緩衝區溢位漏洞
問題描述:Web應用元件可能存在緩衝區溢位漏洞,對它的攻擊會造成嚴重的攻擊後果。這種漏洞是由於CGI,庫函式,驅動程式、應用伺服器元件等沒有合理地驗證輸入。
保護方法:
密切跟蹤Web應用產品的最新錯誤報告,及時打補丁;
使用漏洞掃描工具定期對系統進行緩衝區溢位漏洞掃描;
嚴格審查Web應用程式中從使用者請求接收資料的程式碼,確保對緩衝區長度進行了檢查。
6.注入缺陷
問題描述:Web應用在訪問外部系統或本地作業系統時需要傳遞引數,這些引數可能會被攻擊者利用嵌入惡意程式碼,這樣導致外部系統能以應用伺服器的許可權執行系統命令。
保護方法:
避免使用外部直譯器;
對於涉及到的後臺資料庫呼叫,應對資料進行嚴格驗證;
將Web應用程式設定為能滿足需要的最小許可權執行;
不得不使用外部命令時進行嚴格檢查;
應該檢查呼叫的所有輸出、返回程式碼和錯誤程式碼,最低限度要能確定何時發生了錯誤。
7.不合理的錯誤處理
問題描述:正常操作中的錯誤條件沒能合理處理,如果攻擊者使Web應用產生未作處理的錯誤,就能得到具體系統資訊,使安全機制失效,使伺服器崩潰。
保護方法:
設計合理的錯誤處理策略並作好文件,包括要處理的錯誤型別、錯誤提示資訊、日誌需記錄的資訊;
處理所有可能的錯誤,但不暴露不該暴露的細節;
遇到重複的錯誤嘗試時發出警告。
8.不安全儲存
問題描述:Web應用經常使用加密函式保護資訊和身份證明,這些函式和保護其完整性的程式碼很難完全正確地實現,從而導致弱保護問題。
保護方法
除非必要,儘量少儲存資料;
儲存密碼的摘要(例如SHA-1)而非加密的密碼;
必須使用加密演算法時,儘量採用公開的密碼演算法庫。並妥善儲存祕密資訊,如金鑰、證書、密碼等。
9.拒絕服務
問題描述:攻擊者能夠消耗Web應用的資源,使其無法正確為合法使用者服務,或封閉使用者賬戶甚至使服務癱瘓。
保護方法:
限定分配給每個使用者最少量的資源;
限制每個合法使用者僅有一個連線,並採用適當的丟棄部分請求的策略;
避免非認證使用者對資料庫或其他關鍵資源的非必要訪問;
使用內容快取的方法減少對資料庫的訪問。
10.不安全配置管理
問題描述:對伺服器合理配置是實現安全性的重要因素,伺服器通常都有損害安全性的不合理配置。
保護方法:
為特定伺服器和Web伺服器建立強化安全配置策略,關閉無用服務,建立角色、許可權和賬戶,使用日誌和告警措施;
始終維護伺服器的安全配置,跟蹤最新安全漏洞,應用最新補丁,升級安全設定,定期漏洞掃描,定期進行內部審查。
兩種安全模型:
微軟的安全軟體開發模型:
1.安全開發生命週期(SDL):
SDL總計為四步:
第一步:安全教育,通過教育才能提高安全意識。
設計人員:學會分析威脅
開發人員:跟蹤程式碼中每位元組資料、質疑所有關於資料的假設
測試人員:關注資料的變化
第二步:設計階段,利用威脅建模技術建立系統模型。
第三步:開發階段,編碼與測試並行。
第四步:發行與維護階段,使用標準的修復機制修復安全缺陷。
2.威脅建模:
威脅模型是一種基於安全的分析,有助於人們確定給產品造成的最高級別的安全風險,以及攻擊是如何表現出來的。
其目標是確定需要緩和哪些威脅,如何來緩和這些威脅。
主要分為四個步驟:
第一步:分解應用程式。使用DFD(資料流圖)或者UML(統一建模語言)描述威脅模型,作為分析應用程式的重要組成部分。對應用程式進行形式化分解,自頂向下,逐層細化,在分解過程中關注過程之間的資料流。
例如:
第二步:確定系統面臨的威脅。按照“STRIDE”威脅模型:
S:身份欺騙(Spoofing identity),造成冒充合法使用者、伺服器欺騙(DNS 欺騙,DNS快取中毒)。
T:篡改資料(Tampering with data)。
R:否認(Repudiation)、。
I:資訊洩露(Information disclosure)。
D:拒絕服務(Denial of service, DOS)。
E:特權提升(Elevation of privilege)。
第三步:威脅評估。按照“DREAD”演算法為威脅分級,並建立攻擊樹:
D:潛在的破壞性(damage potential)
R:再現性(reproducibility)
E:可利用性(exploitability)
A:受影響的使用者(affected users)
D:可發現性(discoverability)
例如:
Threat #1: 惡意使用者瀏覽網路上的祕密工資資料
潛在的破壞性: 讀取他人的私密工資並不是開玩笑的事。——風險值為8
再現性:100%可再現。——風險值為10
可利用性: 必須處於同一子網或者處於同一路由器下。——風險值為7
受影響的使用者: 每個人都將受到影響。——風險值為10
可發現性: 讓我們假設它已經發生。——風險值為10
計算風險DREAD: (8+10+7+10+10) / 5 = 9
攻擊樹描述了攻擊者利用系統漏洞破壞各元件,對威脅目標進行攻擊所經歷的決策過程。建立攻擊樹需要考慮的幾個方面:
安全威脅:潛在的事件,當攻擊有動機並付諸實施時,威脅轉變為攻擊事件。
安全漏洞:系統中的弱點。
資源:受威脅(或攻擊)的目標。
例如:
對Threat #1的威脅描述表格:
Threat #1的攻擊樹:
第四步:建立緩和方案,選擇適當的安全技術。
接觸點開發模型:
根據有效性排列的接觸點:
程式碼審查(Code review)
架構風險分析(Architectural risk analysis )
滲透測試(Penetration testing )
基於風險的安全測試(Risk-based security tests )
濫用用例(Abuse cases )
安全需求(Security requirements )
安全操作(Security operations )
1.程式碼審查
程式碼審查的目標是找到bug,架構風險分析的目標是找到缺陷。在很多情況下,這兩個主要的接觸點的執行順序能夠交換。
靜態分析工具:
靜態分析工具在程式碼中查詢固定的模式或規則集合。
靜態分析工具的輸出仍然需要人為判斷。
錯報(false negatives)問題,程式中含有bug但工具沒有報告。
誤報(false positives)問題,工具報出的bugs程式中不存在。
動態分析工具:
執行程式、錯誤注入。
二進位制分析:
反彙編和反編譯都是攻擊者最常用的黑客工具。
例如:Fortify Source Code Analysis Suite
2.架構風險分析
架構風險分析的主要活動是從適當的高度建立一個目標系統的檢視,避免“只見樹林不見森林”,提倡一頁紙的總覽, “forest-level”檢視。
例如:
在forest-level檢視中主要分析以下幾個方面:
威脅(誰可能攻擊系統)、每一層環境中的風險、每個元件和資料流中可能存在的漏洞、技術風險可能造成的商業破壞、風險被實現的可能性、任何在每一層能夠實現的可行對策、考慮整個系統範圍內的可用保護機制。
3.滲透測試
滲透測試,針對系統威脅嘗試對系統進行滲透,包括:積極(正向)測試,驗證軟體正常執行了規定的任務;消極(負向)測試,安全測試人員必須深入研究安全風險(可能由濫用用例和體系風險驅動)以便確定系統在攻擊之下如何反應。
測試工具:
錯誤注入工具。
其他工具:Fortify Software, CANVAS。
攻擊者的工具包。
4.基於風險的安全測試
此測試旨在揭示可能的軟體風險和潛在攻擊。
實施人員:
使用傳統方式的標準測試組織可以執行功能安全測試;
基於風險的安全測試更依賴於專門技術和經驗,而不是測試經驗和安全經驗;
教會測試專業人員學會在測試時如何象一個攻擊者一樣思考。
實施方式:
有原始碼:白盒測試,靜態分析--發現程式中的錯誤;
根據基於對軟體體系深入的理解而進行的風險分析的結論,進行白盒測試;
無原始碼:黑盒測試,執行程式--惡意輸入。
5.濫用用例
濫用用例指軟體開發人員需要在正常特性之外思考軟體系統的固有特性,如可靠性、安全和效能。
實施方式:
對系統的異常行為必須事先有所預期;
象攻擊者一樣思考你的系統,利用“反需求”嘗試出錯點。
例如:你的系統有一個使用加密保護通過序列化將關鍵資料寫到磁碟上的安全需求,與這個需求對應的反需求就是要確定當缺少加密的時候會發什麼情況。
6.安全需求
設計系統的安全需求。
7.安全操作
注重配置管理的安全性,由於配置的改變是必然的,因此我們在開發和維護過程中需要控制配置的改變,建立開發活動(程式、資料、文件)的快照,驗證配置的任何修改,防止惡意修改配置。
常用工具:
Rational ClearCase,MS Visual SourceSafe等。
實用的安全Web開發“藥方”
規劃體系結構和設計解決方案時:
識別和評估威脅:使用威脅建模系統地識別威脅,而不是以任意的方式應用安全性。接著,根據攻擊或安全損害產生的風險和可能造成的潛在損失,對威脅進行評價。這樣就可以適當的次序對威脅進行處理。
建立安全的設計:使用嘗試或檢驗過的設計原則。集中處理關鍵區域,在這些區域,方法正確是必須的,而且經常會出現錯誤。這裡將它們稱為應用程式缺陷類別。其中包括輸入驗證、身份驗證、授權、配置管理、敏感資料保護、會話管理、密碼系統、引數處理、異常管理和稽核與日誌記錄各項。要特別注意部署問題,包括拓撲、網路基礎設施、安全策略和步驟。
執行體系結構和設計複查:應用程式設計的複查與目標部署環境和相關的安全策略有關。需要考慮底層基礎設施層安全性(包括邊界網路、防火牆、遠端應用程式伺服器等)帶來的限制。使用應用程式缺陷類別幫助我們對應用程式進行分類,並分析適合於每個領域的方法。
進行應用開發時:
開發工具的安全性:充分了解開發工具(包括語言、虛擬機器、IDE環境、引用的第三方工具包),最好選擇開放原始碼的開發工具,這樣以便仔細稽核其安全性。檢查開發工具是否提供了使用者和程式碼安全模型,是否允許對使用者和程式碼可以執行的操作進行限制。如果開發中涉及公開對稱和不對稱的加密與解密、雜湊、隨機數生成、數字簽名支援等演算法,最好選用可靠的公開演算法,避免自己炮製演算法。
編寫安全程式碼庫:對程式集進行數字簽名,使它們不能隨意改動。通過遵守面向物件設計原理,減小程式集受攻擊面,然後使用程式碼訪問安全性,進一步限制哪些程式碼可以呼叫您的程式碼。使用結構化的異常處理方法防止敏感資訊蔓延到當前信任邊界之外,並開發更加可靠的程式碼。避免常規問題,特別是輸入檔名和 URL 的問題。
安全地處理異常:不要顯示內部系統或應用程式的詳細資訊,如堆疊跟蹤、SQL 語句片斷等。確保這類資訊不被允許蔓延到終端使用者或當前信任邊界以外。在異常事件中安全地“失敗”,確保應用程式拒絕非法訪問,而且沒有停留在不安全的狀態下。不記錄敏感或私有資料,如密碼,以免造成危害。在記錄或報告異常時,如果使用者的輸入包括在異常訊息中,對其進行驗證或清理。例如,如果返回一個HTML錯誤訊息,那麼應該對輸出進行編碼,以避免指令碼注入。
執行第三方程式碼的安全複查:使用分析工具分析二進位制程式集,確保它們符合安全設計準則,並修復分析工具識別出的所有安全缺陷。複查具體的應用程式元素,包括 Web 頁面和控制元件、資料訪問程式碼、Web 服務、服務元件等。要特別注意 SQL 注入和跨站點指令碼編寫缺陷。
保證開發人員工作站的安全性:使用一套方法保證工作站的安全性。保證帳戶、協議、埠、服務、共享、檔案與目 錄和登錄檔的安全。最重要的是,保持工作站具有當前最新的補丁與更新。例如如果在 Microsoft Windows_ XP 或 Windows 2000 上執行 Internet 資訊服務 (IIS),則執行IISLockdown。IISLockdown 應用安全的IIS配置,並安裝URLScan Internet 安全應用程式程式設計介面 (ISAPI) 篩選器,該篩選器用於檢測和拒絕潛在的惡意 HTTP 請求。
編寫具有最低許可權的程式碼:可以限制程式碼能夠執行的操作,這與執行該程式碼所使用的帳戶無關。通過配置策略或編寫程式碼,可以使用程式碼訪問安全性控制來限制程式碼允許被訪問的資源和操作。如果程式碼不需要訪問某種資源或執行某種敏感操作,可以安全性配置/控制來確保程式碼不會被授予這種許可權。
防止SQL注入:使用資料訪問的引數化儲存過程。使用引數要確保輸入值的型別和長度都 得到檢查。將引數視作安全文字值和資料庫內的不可執行程式碼。如果不能使用儲存過程,也可以使用帶有引數的SQL語句。但不要通過連線SQL命令和輸入值來構建 SQL 語句。還要確保應用程式使用具有最低許可權的資料庫登入,以限制它在資料庫中的功能。
防止跨站點指令碼編寫:對輸入型別、長度、格式和範圍進行驗證,並對輸出進行編碼。如果輸出包括輸入(包括 Web 輸入),則對輸出進行編碼。例如,對窗體欄位、查詢字串引數、cookie等進行編碼,以及對從無法確定其資料是安全的資料庫(特別是共享資料庫)中讀取的輸入進行編碼。對需要以HTML返回客戶端的自由格式的輸入欄位,對輸出進行編碼,然後選擇性地清除在許可元素(如用於格式化的 <b> 或 標記)上的編碼。
管理機密:最好尋找避免儲存機密的替代方法。如果必須儲存它們,則不要在原始碼或配置檔案中以明文的方式儲存。
安全地呼叫程式碼介面:特別注意傳遞給介面和介面返回的引數,防止潛在的緩衝區溢位。驗證輸入和輸出字串引數的長度,檢查陣列邊界,並特別小心檔案路徑的長度。
執行安全的輸入驗證:對輸入進行限制、拒絕和清理,因為驗證已知有效型別、模式和範圍的資料要比通過查詢已知錯誤字元來 驗證資料容易得多。驗證資料的型別、長度、格式和範圍。對字串輸入,請使用正則表示式。有時候可能需要對輸入進行清理。一個例子是在對資料編碼後清理編碼元資料,以保證其安全性。
保證頁面訪問身份驗證的安全性:安全地劃分Web站點,隔離匿名使用者可以訪問的公共可訪問頁面和需要身份驗證訪問的限制性頁面。使用安全套接字層 (SSL) 來保護窗體身份驗證憑據和窗體身份驗證 cookie。限制會話生存時間和確保身份驗證 cookie 只在 HTTPS 上傳輸。對身份驗證 cookie 加密,不要在客戶端計算機上保留它,也不要將其用於個性化目的;對個性化使用單獨的 cookie。
管理和維護系統時:
實現補丁管理:針對Microsoft平臺,那麼可以使用 Microsoft Baseline Security Analyzer (MBSA) 檢查當前安裝可能漏掉的補丁和更新。定期執行該操作,保持伺服器當前安裝有最新的補丁和更新。在應用補丁前,對伺服器資料進行備份;在將補丁安裝在生產伺服器上之前,先在測試伺服器上進行測試。還要使用 Microsoft 提供的安全通知服務,並訂閱通過電子郵件接收安全佈告。針對Unix/Linux平臺,可以 訂閱有關漏洞及補丁的郵件列表,定期使用工具,檢查伺服器上安裝的補丁是否與Unix/Linux廠商釋出的最新補丁列表相一致。
保證Web伺服器的安全性:針對Microsoft平臺上執行的IIS服務,可以使用IISLockdown應用安全的IIS配置,並安裝URLScan Internet 安全應用程式程式設計介面 (ISAPI) 篩選器,該篩選器用於檢測和拒絕潛在的惡意 HTTP 請求。針對Unix/Linux平臺上執行的Apache服務,可以採用選擇性訪問控制(DAC)和強制性訪問控制(MAC)的安全策略,或者安裝安全相關的modules。針對WebService常用的協議(如soap),可以使用 XML 加密以確保敏感資料保持其私有性。使用數字簽名保證訊息的完整性,尤其重要的資料應使用SSL加密。最重要的是,保持伺服器安裝了當前最新的補丁和更新,並使其按照最小許可權執行。
保證資料庫伺服器的安全性:應用一種常見方法評估帳戶、協議、埠、服務、共享、檔案與目錄和登錄檔。還要評估 SQL Server的安全設定,如身份驗證模式和稽核配置。評估身份驗證方法和 SQL Server登入、使用者與角色的使用。確保安裝最新的服務包,定期監測作業系統和 SQL Server 補丁與更新。
防止拒絕服務攻擊:確保加強了伺服器上的 TCP/IP 堆疊配置,以應對如 SYN flood 這樣的攻擊。對web服務的配置做適當的修改以限制接受的 POST 請求的規模,並對請求的執行時間做出限制。
限制檔案 I/O:可以配置程式碼訪問安全策略,以確保限制單個程式集或整個 Web 應用程式只能訪問檔案系統。例如,通過配置執行在媒體信任級上的 Web 應用程式,可以防止應用程式訪問其虛擬目錄層次結構以外的檔案。同時,通過為特定程式集授予受限的檔案 I/O 許可權,可以精確控制哪些檔案可以被訪問以及應該如何訪問它們。
執行遠端管理:針對Microsoft平臺,其終端服務提供了一種專用的協議 (RDP)。它支援身份驗證,並可以提供加密。如果需要檔案傳輸工具,可以從 Windows 2000 Server 資源包中安裝檔案複製實用工具。建議不要使用 IIS Web 管理,如果執行 IISLockdown 該選項將被清除。應該考慮提供一個加密的通訊通道,並使用 IPSec 限制可以用於遠端管理您的伺服器的計算機。還應該限制管理帳戶的數量。針對Unix/Linux平臺,建議採用SSH進行遠端管理,檔案傳輸使用SFTP。
參考資源:
Microsoft Corporation的《編寫安全的程式碼》第二版
Gary McGraw編寫的《Software Security: Building Security In》
微軟Web安全解決方案一覽