cleverpig 發表于 2007-07-03 17:22:58
作者:cleverpig 來源:Matrix
安全軟件開發入門
作者:cleverpig
軟件安全問題有趣的《黑客帝國》終極解釋:
《黑客帝國》故事里面的人物關系,就像電腦里面的各種程序的關系一樣:
電腦里面的系統程序: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.濫用APIAPI規定了調用者和被調用程序之間的使用約定。濫用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安全解決方案一覽使用Yassp工具包安裝安全的Solaris系統微軟IIS Lockdown Tooljwebee
我的個人網站
posted on 2007-07-08 14:49
周行 閱讀(1262)
評論(0) 編輯 收藏