C安全編碼標準：開發安全、可靠、穩固係統的98條規則（原書第2版） 下載 mobi epub pdf 電子書 2024

☆☆☆☆☆
簡體網頁||繁體網頁



點擊這裡下載

類似圖書 點擊查看全場最低價

---

編輯推薦

　　C語言安全編程的難度可能超乎許多有經驗的程序員的想象。為瞭幫助編程人員編寫更安全的代碼，本書提供瞭CERT C安全編碼標準第二個正式發行版本的完整文檔。這個新版本中的規則有助於確保程序員的代碼完全遵循新的C11標準；它也處理早期版本（包括C99）的問題。
　　新標準列舉瞭當前C語言軟件漏洞的根源，按照嚴重性、利用的可能性和補救成本排定優先級。書中的98個指導方針都包含瞭不安全代碼和對應的C11相容安全實現。如果統一應用，這些指導方針將消除導緻緩衝區溢齣、格式字符串漏洞、整數溢齣和其他常見漏洞的嚴重編碼錯誤。

內容簡介

本書是業界最廣泛采納的編程指導原則匯編 ，它緊扣各個版本的C語言標準，分門彆類地介紹瞭各種可能引發可利用安全漏洞的未定義行為、未指定行為，提齣瞭安全編碼的規則和建議，在每條規則和建議上都用現實的相容及不相容代碼示例加以說明，本書是該標準文檔的第2版，加入瞭對最新的C11標準的支持，對於所有有誌於C語言軟件開發的技術人員來說，都是不可或缺的參考書。

全書共14章，包括98條編碼規則，每條規則都由一個標題、一段說明和不相容/相容的代碼示例組成。第1章講述與預處理器相關的規則；第2章介紹的規則與聲明和初始化相關；第3章介紹的是與錶達式相關的規則；第4~7章講述的規則分彆與整數、浮點數、數組及字符和字符串相關；第8章介紹與內存管理相關的規則；第9章講解的規則與輸入/輸齣相關；第10章介紹的規則與環境相關；第11~13章分彆講解與信號、錯誤處理和並發性有關的規則；第14章講述幾條雜項規則。最後提供3個附錄，分彆包括本書使用的詞匯錶、未定義行為和未指定行為。

作者簡介

Robert C. Seacord 是卡內基-梅隆大學軟件工程研究所（SEI）CERT計劃的安全編碼技術經理。CERT項目是運營相關網絡安全研究和對美國網絡安全挑戰創新/及時響應的可信提供商。安全編碼倡議和軟件開發人員及軟件開發組織閤作，在部署之前消除由於編碼錯誤造成的安全漏洞。Robert還是卡內-基梅隆大學計算機科學學院和信息網絡學院的副教授。他曾經撰寫過8本書籍，包括《Secure Coding in C and C++》第2版和《Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs》等。他還發錶過40篇軟件安全性、基於組件的軟件工程、基於Web係統設計、遺留係統現代化、組件儲存庫和搜索引擎以及用戶界麵設計和開發方麵的論文。

精彩書評

在Cisco，我們已經采用CERT C編碼標準作為所有C語言開發人員的內部安全編碼標準。它是我們的安全開發生命期的核心組成部分。本書描述的編碼標準將復雜的軟件安全主題分解為容易遵循的規則以及優秀的現實示例。這是任何希望編寫安全、有彈性軟件的C/C++開發人員必不可少的參考書。
——Edward D. Paradise，Cisco Systems工程、威脅響應、智能和開發副總裁

目錄

譯者序
前言
貢獻者簡介
第1章　預處理器（PRE）
1.1　PRE30-C. 不要通過連接創建通用字符名稱
1.2　PRE31-C. 避免不安全宏參數的副作用
1.3　PRE32-C. 不要在類函數的宏調用中使用預處理器指令
第2章　聲明和初始化（DCL）
2.1　DCL30-C. 聲明具有正確存儲持續期的對象
2.2　DCL31-C. 在使用前聲明標識符
2.3　DCL36-C. 不要聲明具有衝突鏈接類彆的標識符
2.4　DCL37-C. 不要聲明或者定義保留標識符
2.5　DCL38-C. 使用正確語法聲明靈活數組成員
2.6　DCL39-C. 避免在結構填充中泄露信息
2.7　DCL40-C. 不要創建相同函數或者對象的不兼容聲明
2.8　DCL41-C. 不要在switch語句第一個條件標簽之前聲明變量
第3章　錶達式（EXP）
3.1　EXP30-C. 不要依賴求值順序以避免副作用
3.2　EXP32-C. 不要通過非易失性引用訪問易失性對象
3.3　EXP33-C. 不要讀取未初始化的內存
3.4　EXP34-C. 不要對null指針進行解引用
3.5　EXP35-C. 不要修改具有臨時生命期的對象
3.6　EXP36-C. 不要將指針轉換為更嚴格對齊的指針類型
3.7　EXP37-C. 用正確數量和類型的參數調用函數
3.8　EXP39-C. 不要通過不兼容類型的指針訪問變量
3.9　EXP40-C. 不要修改常量對象
3.10　EXP42-C. 不要比較填充數據
3.11　EXP43-C. 使用restrict限定的指針時避免未定義行為
3.12　EXP44-C. 不要嚮sizeof、_Alignof或者_Generic傳遞有副作用的操作數
3.13　EXP45-C. 不要在選擇語句中執行賦值
第4章　整數（INT）
4.1　INT30-C. 確保無符號整數運算不産生迴繞
4.2　INT31-C. 確保整數轉換不會造成數據丟失或者錯誤解釋
4.3　INT32-C. 確保有符號整數的運算不造成溢齣
4.4　INT33-C. 確保除法和餘數運算不會造成0除數錯誤
4.5　INT34-C. 不要用負數或者不小於操作數位數的位數對錶達式進行移位
4.6　INT35-C. 使用正確的整數精度
4.7　INT36-C. 將指針轉換為整數或者將整數轉換為指針
第5章　浮點數（FLP）
5.1　FLP30-C. 不要使用浮點變量作為循環計數器
5.2　FLP32-C. 避免或者檢測數學函數中的定義域和值域錯誤
5.3　FLP34-C. 確保浮點數轉換在新類型的範圍內
5.4　FLP36-C. 將整數值轉換為浮點指針類型時保持精度
第6章　數組（ARR）
6.1　ARR30-C. 不要形成或者使用超限的指針或者數組下標
6.2　ARR32-C. 確保變長數組的大小參數在有效範圍內
6.3　ARR36-C. 不要進行兩個不引用相同數組的指針之間的減法或者比較
6.4　ARR37-C. 不要在指嚮非數組對象的指針上加或者減一個整數
6.5　ARR38-C. 保證庫函數不形成無效指針
6.6　ARR39-C. 不要在指針上加或者減一個按比例調整的整數
第7章　字符和字符串（STR）
7.1　STR30-C. 不要企圖修改字符串字麵量
7.2　STR31-C. 保證字符串存儲有足夠的空間容納字符數據和null結束符
7.3　STR32-C. 不要嚮要求字符串參數的庫函數傳遞非null結束字符序列
7.4　STR34-C. 在轉換為更大的整數尺寸之前將字符轉換為unsigned char類型
7.5　STR37-C. 字符串處理函數的實參必須可以錶示為unsigned char
7.6　STR38-C. 不要混淆窄和寬字符串及函數
第8章　內存管理（MEM）
8.1　MEM30-C. 不要訪問已釋放內存
8.2　MEM31-C. 在不再需要時釋放動態分配的內存
8.3　MEM33-C. 動態分配和復製包含靈活數組成員的結構
8.4　MEM34-C. 隻釋放動態分配的內存
8.5　MEM35-C. 為對象分配足夠的內存
8.6　MEM36-C. 不要通過調用realloc()修改對象的對齊方式
第9章　輸入/輸齣（FIO）
9.1　FIO30-C. 從格式字符串中排除用戶輸入
9.2　FIO31-C. 不要打開已經打開的文件
9.3　FIO32-C. 不要在隻適閤文件的設備上執行操作
9.4　FIO34-C. 區分從文件讀入的字符和EOF/WEOF
9.5　FIO37-C. 不要假定fgets()或者fgetws()在成功時返迴非空字符串
9.6　FIO38-C. 不要復製FILE對象
9.7　FIO39-C. 不要在沒有中間刷新或者定位調用的情況下在一個流中交替輸入和輸齣
9.8　FIO40-C. 在fgets()或者fgetws()失敗時重置字符串
9.9　FIO41-C. 不要用有副作用的流作為實參調用getc()、putc()、getwc()或者putwc()
9.10　FIO42-C. 在不再需要時關閉文件
9.11　FIO44-C. 對fsetpos()隻使用fgetpos()返迴的值
9.12　FIO45-C. 避免訪問文件時齣現TOCTOU競爭條件
9.13　FIO46-C. 不要訪問已關閉文件
9.14　FIO47-C. 使用有效格式字符串

前言/序言

　　Preface　前　　言本書為C語言編碼提供瞭規則。這些規則的目標是開發安全、可靠和穩固的係統，例如，消除可能導緻程序意外行為和可利用漏洞的未定義行為。遵循本標準定義的編碼規則是確保C語言開發的軟件係統安全、可靠、穩固的必要條件（但不是充分條件）。安全和穩固的設計也是必要的，安全性關鍵係統通常會提齣比編碼標準更嚴格的要求，例如，要求所有內存都是靜態分配的。然而，應用本編碼標準將産生高質量的係統，這些係統可靠、健壯並且能夠抵禦攻擊。
　　每條規則都由一個標題、一段說明和不相容/相容的代碼示例組成。標題是規則的簡潔描述，但是有時候不夠精確。說明提齣瞭規則的規範要求。不相容代碼示例是違反規則的代碼示例。搭配的相容解決方案展示瞭等價的代碼，這些代碼不違反該規則或者該編碼標準中的任何其他規則。
　　具有良好文檔、可以實施的編碼標準是C語言編碼必不可少的要素。編碼標準鼓勵程序員遵循由項目需求和組織確定的一組統一規則，而不是簡單地采用程序員熟悉的方法。一旦確定，這些標準可以作為評估源代碼（使用人工或者自動化過程）的指標。
　　CERT編碼規則為業界廣泛采納。Cisco係統公司在2011年10月的Cisco年度SecCon會議上宣布在其産品開發中采用CERT C安全編碼標準作為基準編程標準。最近，Oracle將所有CERT安全編碼標準整閤到現有的安全編碼標準中。注意，這是長期協作中的最新步驟：CERT和Oracle以前閤作編寫瞭《The CERT Oracle Secure Coding Standard for Java》（Addison-Wesley，2011）。
　　範圍本書是為如下標準中定義的C語言版本開發的：
　　ISO/IEC 9899: 2011，Programming Languages-C, Third Edition [ISO/IEC 9899: 2011]ISO/IEC 9899: 2011/Cor.1: 2012，Technical Corrigendum 1本書在第1版的基礎進行更新或替換（Addison-Wesley，2008）。本書第1版的範圍是C99（C語言標準第2版）[ISO/IEC 9899: 1999]。雖然本書中的規則是為C11開發的，但是它們也適用於C編程語言的較早版本（包括C99）。在C語言標準各版本之間的差異影響這些規則的正常應用時，本書將在閤適的地方進行標注。
　　大部分規則都有一個不相容代碼示例程序與C11兼容，以確保規則所識彆的問題在標準範圍內。但是，編碼問題的最佳解決方案往往與平颱相關。在許多情況下，本標準提供兼容POSIX和Windows操作係統的相應解決方案。以ISO/IEC技術報告或者技術規範形式發布的語言和程序庫擴展常常優先使用，例如ISO/IEC TR 24731-2《Extensions to the C Library-Part II: Dynamic Allocation Functions》[ISO/IEC TR 24731-2: 2010]描述的擴展。在許多情況下，還有為Linux或者OpenBSD等平颱提供的兼容解決方案。我們偶爾還會描述有趣或者直觀的特定實現行為。
　　原理C語言編碼標準專注於C語言標準（C11）和C11之後的相關技術報告，可以在最長的時期內創造最高的價值。
　　C語言標準盡可能記錄現有的實踐方法。也就是說，大部分功能必須先在某個實現中測試，纔能包含在標準中。本書有不同目的：確定一組最佳實踐，有時候需要介紹尚未廣為人知或者在現有方法無能為力時使用的新方法。換一種說法，本書試圖推動變化，而不隻是記錄它們。
　　例如，C11中引入瞭可選而規範的附件K“Bounds-Checking Interfaces”（邊界檢查接口），對它的支持正在日益增加，但是目前隻有少數供應商實現瞭這一接口。該接口引入瞭memcpy_s()等函數，目的是為API添加目標緩衝區大小，提供安全性服務。這一文檔具有前瞻性，沒有道理僅因為這些函數沒有廣泛實現而忽略它們。基本C語言標準的實現比附件K更廣泛，盡管附件K還沒有廣泛實現，但它是行業發展的方嚮。新型C語言代碼的開發人員尤其需要這樣一本指南，指導他們使用正在開發的編譯器和工具，從而最大限度地利用其能力。
　　有些供應商對C進行瞭擴展，有些則隻實現瞭C語言標準的一部分便停止開發。因此，不可能倒退迴去僅討論C99、C95或者C90。供應商的支持方程非常復雜，無法確定一條基綫，聲稱某個編譯器具體支持某個標準。不管選擇哪個分隔點，不同的編譯器對於該語言的不同部分都可能齣現相反的結果。要支持所有可能性，就必須對每個産品測試語言的每個特性。因此，我們選擇瞭最近的一個分隔點，使標準定義的規則適用時間盡可能長。由於支持的種類不同，當程序員隻使用C99規定的功能時，源代碼的可移植性得到加強。這是C語言編程固有的安全性/可移植性之間的權衡。
　　前瞻性信息的價值隨著時間的推移而提高，之後開始下降。而迴溯性信息的價值從一開始就立刻下降。
　　由於以上這些原因，本書首先支持使用尚未加入C語言標準的C11及C11之後的技術報告進行的新代碼開發。其次支持對C99舊代碼及技術報告的糾正。
　　在效果顯著且不會影響其他優先事項的時候，本書將為支持舊編譯器做齣貢獻。這樣做的目的不是捕捉所有偏離C語言標準的情況，而是捕捉少數幾種重要的情況。
　　沒有解決的問題對於一些問題，本書沒有提供解決方案。
　　編碼風格：編碼風格是一個主觀的問題，實踐證明，無法開發公認的正確風格指南。因此，本標準對於具體采用哪一種風格不作要求，隻建議開發組織定義或者采用風格指南，並一緻地應用這些方針。一緻地應用某種編碼風格的最簡方法是使用代碼格式化工具。許多交互式開發環境（Interactive Development Environment，IDE）都提供這種功能。
　　有爭議的規則：一般來說，CERT編碼標準試圖避免包含缺乏廣泛共識的爭議規則。
　　本書的讀者本書主要是為C語言程序開發人員而編寫的，但是也可以供軟件采購者使用，以定義定製軟件的需求。本書特彆有利於對構造可靠、健壯、可以抵禦攻擊的高質量係統感興趣的程序員。
　　本書雖然不是專門針對C++程序員的，但是對他們仍然有一定的價值，因為C語言程序的大部分問題在C++程序中也存在，不過在許多情況下，兩者的解決方案不同。
　　曆史CERT安全編碼標準的思路起源於C語言標準委員會（更正式的叫法是ISO/IEC JTC1/SC22/WG14）在德國柏林召開的2006春季會議[Seacord 2013a]。C語言標準是權威文檔，但其受眾主要是編譯器實現者，而且，許多人注意到，它的語言模糊，往往很費解。安全編碼標準主要針對C語言程序員，為使用該語言安全編碼提供實用指南。
　　CERT C安全編碼標準在CERT安全編碼wiki（http://www.securecoding.cert.org）上，按照基於社區的開發過程開發。來自該社區的專傢（包括WG14 C語言標準委員會成員）應邀投稿，並且得到wiki的編輯特權。社區成員可以在wiki上注冊一個免費賬號，對編碼標準和單獨的規則做齣評論。提供高質量評論的審核者常常得到編輯特權，可以直接為編碼標準的開發和發展做齣貢獻。目前，CERT安全編碼wiki有1576名注冊的貢獻者。
　　基於社區的開發過程有許多好處。最重要的是，它廣泛吸引專傢，並讓他們對規則的內容形成一緻的意見。在wiki上開發安全編碼標準的主要缺點是內容不斷演化。如果你需要最新信息，願意接受尚未全麵核查的變化，那麼這種不穩定性是可以接受的。然而，許多軟件開發組織想要一組靜態的規則和建議，以便作為軟件開發過程的需求。為此，在社區開發兩年半之後，我們齣版瞭本書第1版。隨著2008年6月該書手稿的製作，書籍的1.0版本和安全編碼標準的wiki版本開始分道揚鑣。
　　在2007年4月的倫敦會議上首次提交CERT C安全編碼指南給WG14審核，2007年8月在夏威夷可納的會議上再次審核。
　　根據報道，2008年4月15日召開的J11/U.S. TAG會議討論瞭INCITS PL22.11是否應該將CERT C安全編碼標準提交給WG14，作為2類或者3類技術報告候選的問題。J11現在成為PL22.11 C語言編程任務組，這個技術委員會是ISO/IEC JTC1 SC22/WG14的美國技術顧問小組。我們就“誰有時間承擔這一項目”這個問題進行瞭一次民意測驗，贊成者（有時間）有4人，反對者（沒有時間）有12人。之後，我們接收到的反饋是，雖然CERT C安全編碼標準是一組強大的指導方針，開發時得到瞭WG14的許多技術專傢的意見，並且已經由WG14審核多次，但是WG14通常不負責將指南“賜予”程序員，而負責定義編譯器等工具的規範需求。
　　瞭解瞭這一點之後，我們提議WG14建立一個研究小組，考慮為C語言製作可分析安全編碼指南的問題。這個研究小組於2009年10月27日第一次召開會議，CERT嚮ISO/IEC貢獻瞭C安全編碼規則的一個可自動實施子集，用於標準化進程。
　　研究小組的參與者包括分析程序供應商（如Coverity、Fortify、GammaTech、Gimpel、Klocwork和LDRA）、安全性專傢、語言專傢和消費者。2012年3月，WG14批準開發和發錶ISO/IEC TS 17961—C語言編碼規則的新工作項目，研究小組工作結束。意大利國傢分委員會在WG14的代錶Roberto Bagnara後來加入瞭WG14編輯委員會。2013年11月，ISO/IEC TS 17961: 2013（E）《信息技術—編程語言、環境和係統軟件接口—C安全編碼規則》[ISO /IEC TS 17961:2013]正式發錶，可以在ISO商店（http://www.iso.org/iso/catalogue_detail.htm?csnumber=61134）訂購。
　　ISO/IEC TS 17961 C語言安全編碼規則ISO/IEC TS 17961的目的是建立一組分析程序（包括靜態分析工具和C語言編譯器）的需求基準，供希望診斷超齣語言標準需求的不安全代碼的供應商應用。所有規則都可以通過靜態分析實施。選擇這些規則的標準是，實施這些規則的分析程序必須能夠有效地發現安全編碼錯誤，不會産生過量的假陽性。
　　目前，不同供應商已經以特殊的方式將靜態分析應用到安全保障上，造成重要安全保障問題的覆蓋麵不統一。ISO/IEC TS 17961列舉瞭安全編碼規則，需要分析引擎診斷這些規則的違背情況，作為規範相容性的指標。這些規則能夠以實現相關的方式進行擴展，為任何相容靜態分析實現的客戶提供最小覆蓋保證。
　　ISO/IEC TS 17961指定瞭C語言中安全編碼的規則，包含每條規則的代碼示例。不相容的代碼示例闡述瞭具有潛在可利用安全性弱點的語言結構；這些例子預計會引起相容分析程序對受影響的語言結構的診斷。相容的例子預計不會引起診斷。ISO/IEC TS 17961不指定實施這些規則的機製和任何特殊的編碼風格。
　　錶P-1展示瞭ISO/IEC TS 17961與其他標準和方針的關聯性。在已有的齣版物中，ISO/IEC TS 17961是唯一以分析程序而非開發人員為直接受眾的。
　　錶P-1　ISO/IEC TS 17961與其他標準的比較編碼標準C語言標準安全保障標準安全性標準國際化標準完整語言CWE無/全部是否否—MISRA C2C89否是否否MISRA C3C99否是否否CERT C99C99是否否 C安全編碼標準：開發安全、可靠、穩固係統的98條規則（原書第2版） 下載 mobi epub pdf txt 電子書 格式

評分☆☆☆☆☆

應該還可以，待細看！

評分☆☆☆☆☆

打摺買的，京東的書還是很不錯的。

評分☆☆☆☆☆

京東活動買的，看起來還不錯

評分☆☆☆☆☆

挺不錯的一本書，部門集體買的

評分☆☆☆☆☆

正品推薦購買。正品推薦購買。正品推薦購買。正品推薦購買。正品推薦購買。

評分☆☆☆☆☆

很不錯的書，很有參考意義

評分☆☆☆☆☆

很不錯的一本書，對工作有幫助

評分☆☆☆☆☆

應該會是很棒的閱讀體驗。

評分☆☆☆☆☆

和第一版相比，少瞭很多條款。

類似圖書 點擊查看全場最低價