C和C++安全编程实战指南

需积分: 9 84 浏览量更新于2024-07-22 收藏 4.29MB PDF 举报

"Secure Programming Cookbook for C and C++ (2003)" 本书《Secure Programming Cookbook for C and C++》是2003年出版的一本关于计算机安全编程的专业指南，专注于C和C++编程语言。它旨在帮助开发者理解和避免在编写代码时可能导致安全漏洞的常见错误，从而提高软件的安全性。书中的内容涵盖了多种与安全相关的主题，包括内存管理、输入验证、缓冲区溢出、指针安全、网络通信安全等方面。在C和C++编程中，安全问题往往是由于程序员对底层机制的理解不足或编程习惯不良导致的。书中可能涉及以下几个关键知识点： 1. **内存管理**：讨论如何正确地分配和释放内存，避免内存泄漏和悬挂指针。它会讲解如何使用`malloc`, `calloc`, `free`等函数，以及如何处理内存越界和双重释放等问题。 2. **缓冲区溢出**：介绍如何防止缓冲区溢出攻击，这是许多严重安全漏洞的根源。这包括了解栈溢出和堆溢出，以及使用安全的字符串操作函数如`strncpy`和`snprintf`代替不安全的`strcpy`和`sprintf`。 3. **输入验证**：强调在处理用户输入时进行严格的验证，以防止注入攻击。这可能包括学习正则表达式、边界检查和类型转换的安全实践。 4. **指针安全**：探讨如何避免空指针解引用和未初始化的指针使用，确保指针的有效性和安全性。 5. **网络通信安全**：讲述在C和C++中处理网络数据时的加密和安全协议，如使用SSL/TLS进行安全套接层传输，以及处理潜在的网络攻击。 6. **编译器和链接器选项**：介绍如何利用编译器的特定选项来增强代码的安全性，如启用堆栈保护和地址空间布局随机化（ASLR）。 7. **安全编程原则和实践**：书中可能会列出一系列安全编码的最佳实践，以帮助开发者形成良好的安全编程习惯。 8. **调试和测试**：讨论如何有效地发现和修复安全漏洞，包括使用静态分析工具和动态测试方法。除了这些核心主题，书中还可能包含其他相关资源的链接，如O'Reilly出版的其他计算机安全书籍，以及网络安全、操作系统安全、Java安全和数据库安全等领域的参考资料。O'Reilly的网站提供样章、代码示例和最新的安全技术信息，是开发者深入学习和研究安全编程的重要资源库。《Secure Programming Cookbook for C and C++》是C和C++开发者不可或缺的参考书籍，它不仅提供了详尽的指导，还帮助开发者构建起牢固的安全编程意识，从而降低软件安全风险。

This is the Title of the Book, eMatter Edition

xiv

Foreword

they are in the top 50% of safe drivers. Being an objective judge of one’s own abili-

ties is not always possible.

What compounds the problem for us all is that programmers are especially unlikely

to realize (or are unwilling to admit) their limits. There are levels and degrees of com-

plexity when working with computers and software that few people completely

understand. However, programmers generally hold a world view that they can write

correct code all the time, and only occasionally do mistakes occur, when in reality

mistakes are commonplace in nearly everyone’s code. As with the four categories, or

the drivers, or any other domain where skill and training are required, the experts

with real ability are fewer in number than those who believe they are expert. The

result is software that may be subtly—or catastrophically—incorrect.

A program with serious flaws may compile properly, and work with obvious inputs.

This helps reinforce the view that the code is correct. If something later exposes a

flaw, many programmers will say that a “bug” somehow “got into the code.” Or

maybe “it’s a computer problem.” Neither is candid. Instead, whoever designed and

built the system made mistakes. As a profession, we are unwilling to take responsi-

bility when we code things incorrectly. Is it any wonder that a recent NIST study

estimated that industry in the United States alone is spending $60 billion a year

patching and customizing badly-written software? Is it a surprise that there are thou-

sands of security patches per year for common software platforms? We’ve seen esti-

mates that go as high as $1.5 trillion in damages per year worldwide for security

problems alone, and simple crashes and errors may be more than 10 times as much.

These are not rare flaws causing problems. There is a real crisis in producing quality

software.

The reality is that if we truly face up to the situation, we might reassess some conven-

tional beliefs. For instance, it is not true that a system is more secure because we can

patch the source code when a flaw is discovered. A system is secure or it is not—

there is no “more secure.” You can’t say a car is safer because you can replace the

fenders yourself after the brakes give out and it goes over a cliff, either. A system is

secure if there are no flaws that lead to a violation of policy. Being able to install the

latest patch to the latest bad code doesn’t make a system safer. If anything, after

we’ve done it a few times, it should perhaps reduce our confidence in the quality of

the software.

An honest view of programming might also cause us to pay more attention to

design—to capturing requirements and developing specifications. Too often we end

up with code that is put together without understanding the needs—and the pit-

falls—of the environment where it will be used. The result is software that misbe-

haves when someone runs it in a different environment, or with unexpected input.

There’s a saying that has been attributed to Brian Kernighan, but which appears to

have first been written down by W. D. Young, W.E. Boebert, and R.Y. Kain in 1985:

“A program that has not been specified cannot be incorrect; it can only be surprising.”

This is the Title of the Book, eMatter Edition

Foreword

Most of the security patches issued today are issued to eliminate surprises because

there are no specifications for the underlying code. As a profession, we write too

much surprising code.

I could go on, but I hope my points are clear: there are some real problems in the

way software is being produced, and those problems lead to some serious—and

expensive—problems. However, problem-free software and absolute security are

almost always beyond our reach in any significant software project, so the next best

thing is to identify and reduce the risks. Proven approaches to reduce these risks

include using established methods of software engineering, exercising care in design

and development, reusing proven software, and thinking about how to handle poten-

tial errors. This is the process of assurance—of building trust in our systems. Assur-

ance needs to be built in rather than asserted after the software is finished.

That’s why this book is so valuable. It can help people write correct, robust software

the first time and avoid many of the surprises. The material in this book can help you

provide a network connection with end-to-end security, as well as help you elimi-

nate the need to patch the code because you didn’t add enough entropy to key gener-

ation, or you failed to change the UID/GID values in the correct order. Using this

code you can get the environment set correctly, the signals checked, and the file

descriptors the way you need them. And along the way, you can read a clear, cogent

description about what needs to be set and why in each case. Add in some good

design and careful testing, and a lot of the surprises go away.

Are all the snippets of code in this book correct? Well, correct for what? There are

many other things that go into writing reliable code, and they depend on the con-

text. The code in this book will only get you partway to your goal of good code. As

with any cookbook, you may need to adjust the portions or add a little extra season-

ing to match your overall menu. But before you do that, be sure you understand the

implications! The authors of this book have tried to anticipate most of the circum-

stances where you would use their code, and their instructions can help you avoid

the most obvious problems (and many subtle ones). However, you also need to build

the rest of the code properly, and run it on a well-administered system. (For that, you

might want to check out some of the other O’Reilly books, such as Secure Coding by

Mark Graff and Kenneth van Wyk, and Practical Unix and Internet Security by Sim-

son Garfinkel, Gene Spafford, and Alan Schwartz.)

So, let’s return to those four categories of programmers. This book isn’t likely to help

the group of people who are perpetually unclear on the concepts, but it is unlikely to

hurt them. It will do a lot to help the people who need guidance and examples,

because it contains the text as well as the code. The people who write good software

most of the time could learn a lot by reading this book, and using the examples as

starting points. And the experts are the ones who will readily adopt this code (with,

perhaps, some small adaptions); expert coders know that reuse of trusted compo-

nents is a key method of avoiding mistakes. Whichever category of programmer you

This is the Title of the Book, eMatter Edition

xviii

Preface

the C programming language, with some quick forays into C++ when important,

and a bit of assembly when there’s no other way.

We hope this book will do well enough that we’ll be able to produce versions for

other programming languages. Until then, we are going to solve both of the afore-

mentioned problems at once with our web site, http://www.secureprogramming.com,

which you can also get to from the book’s web page on the O’Reilly site (http://

oreilly.com/catalog/secureprogramming/). Not only can you find errata there, but you

can also find and submit secure programming recipes that are not in the book. We

will put on the site recipes that we validate to be good. The goal of the site is to be a

living, breathing resource that can evolve as time progresses.

We Can’t Do It All

There are plenty of things that people may find to criticize about this book. It’s too

broad a topic to make a perfect book (that’s the motivation for the web site, actu-

ally). Although we believe that this book is likely to help you a great deal, we do

want to address some specific issues so at least you’ll know what you’re getting if

you buy this book:

This book is implementation-focused.

You’re not likely to build secure software if you don’t know how to design soft-

ware to be secure from the get-go. We know that well, and we discuss it at great

length in the book Building Secure Software. On the other hand, it’s at least as

easy to have a good design that results in an insecure implementation, particu-

larly when C is the programming language you’re using. Not only do our imple-

mentation-level solutions incorporate good design principles, but we also discuss

plenty of issues that will affect your designs as well as your implementations.

The world needs to know both how to design and how to implement with secu-

rity in mind. We focus on the implementation so that you’ll do a better job of it.

Nonetheless, we certainly recommend that you read a book that thoroughly cov-

ers design before you read this book.

This book doesn’t cover C++ well enough.

C++ programmers may grumble that we don’t use any C++ specific idioms. For

the most part, the advice we give applies to both languages, but giving all the

examples in C makes them more applicable, because practitioners in both lan-

guages can still use them. On the rare occasion that there are things to note that

are specific to C++, we certainly try to do so; examples include our discussions

of buffer overflows and the use of exception handling to prevent leaving pro-

grams in an insecure state. Over time, our coverage of C++ will improve on the

book’s web site, but, until then, C++ programmers should still find this book

relevant.

剩余791页未读，继续阅读

jiangdmdr

粉丝: 58
资源: 767

C和C++安全编程实战指南

Secure.Programming.Cookbook.for.C.and.C.

Secure Programming Cookbook for C and C++

Secure_Programming_Cookbook_for_C_and_C

Secure+Programming+Cookbook+for+C+and+C++

Secure Programming Cookbook for C and C++ 无水印pdf

iOS 8 Swift Programming Cookbook Solutions Examples for iOS Apps.pdf

FreeSWITCH.1.6.Cookbook.17852809

iOS 10 Programming Cookbook

Python Network Programming Cookbook, 2nd Edition - 2017

C# Programming Cookbook [EPUB+MOBI+PDF]

最新资源