安全编码指南：抵御黑客攻击

需积分: 9 92 浏览量更新于2024-07-20 收藏 1.13MB PDF 举报

"SecureCodingGuide 是一份关于安全编码的指南，旨在帮助开发者编写能抵御恶意攻击的程序，保护用户数据免受盗窃或破坏。这份文档适用于所有软件开发人员，无论你是编写个人脚本还是商业应用，都应了解其中的安全编码原则。" 在当今的数字时代，安全编码的重要性不言而喻。不安全的代码可能会让攻击者有机可乘，对服务器或用户的计算机造成拒绝服务，甚至泄露秘密、丧失服务，或者破坏成千上万用户的系统。这份指南涵盖了多个关键的安全漏洞类型及其对策。 1. **缓冲区溢出**：缓冲区溢出是最常见的安全漏洞之一，当程序尝试写入超出分配内存空间的数据时，可能会导致数据覆盖，从而破坏程序的正常运行，甚至执行任意代码。 2. **未验证输入**：不检查用户输入的有效性和安全性，可能导致恶意数据注入，如SQL注入或跨站脚本攻击(XSS)。 3. **竞态条件**：在多线程环境中，不恰当的同步可能导致竞态条件，使得攻击者可以预测和操纵程序行为。 4. **进程间通信**：不安全的进程间通信可能暴露敏感信息，使攻击者能够操控其他进程。 5. **不安全的文件操作**：不当的文件读写操作可能导致数据泄露或权限滥用。 6. **访问控制问题**：如果没有正确实现访问控制，攻击者可能获得不应有的权限，执行未授权的操作。 7. **安全存储和加密**：确保数据在存储和传输过程中得到加密，防止被窃取或篡改。 8. **社会工程学**：利用人类交互来获取敏感信息，如通过钓鱼邮件或欺诈性电话。 9. **避免缓冲区溢出和下溢**：开发者需要特别关注栈溢出、堆溢出以及字符串处理，确保分配足够的缓冲区大小，并正确计算缓冲区尺寸。 10. **避免整数溢出和下溢**：整数运算可能导致溢出，从而影响计算结果，有时会被攻击者利用进行安全攻击。 11. **检测缓冲区溢出**：通过使用内存安全技术，如地址空间布局随机化(ASLR)、非执行栈和堆，可以提高系统的安全性。 12. **验证输入和进程间通信**：对用户输入和不同进程间的通信进行严格验证，是防止攻击的关键步骤。 13. **URL和文件处理**：错误处理URL和文件可能导致注入攻击，或让攻击者修改归档数据。 14. **模糊测试（Fuzzing）**：通过生成大量随机输入来发现程序中的漏洞，是一种有效的安全测试方法。 15. **进程间通信**：需要考虑如何安全地在进程之间交换信息，防止信息泄漏或被篡改。这份指南详细阐述了如何避免这些安全漏洞，提供了一系列技术和实践建议，对于任何希望提升软件安全性的开发者来说，都是宝贵的参考资料。通过遵循这些最佳实践，开发者可以编写出更安全、更可靠的软件，降低被攻击的风险。

Each service has appropriate uses, and each has limitations. For example, FileVault, which encrypts the contents

of a user’s root volume (in OS X v10.7 and later) or home directory (in earlier versions), is a very important

security feature for shared computers or computers to which attackers might gain physical access, such as

laptops. However, it is not very helpful for computers that are physically secure but that might be attacked

over the network while in use, because in that case the home directory is in an unencrypted state and the

threat is from insecure networks or shared files. Also, FileVault is only as secure as the password chosen by the

user—if the user selects an easily guessed password, or writes it down in an easily found location, the encryption

is useless.

It is a serious mistake to try to create your own encryption method or to implement a published encryption

algorithm yourself unless you are already an expert in the field. It is extremely difficult to write secure, robust

encryption code that generates unbreakable ciphertext, and it is almost always a security vulnerability to try.

For OS X, if you need cryptographic services beyond those provided by the OS X user interface and high-level

programming interfaces, you can use the open-source CSSM Cryptographic Services Manager. See the

documentation provided with the Open Source security code, which you can download at http://developer.ap-

ple.com/darwin/projects/security/. For iOS, the development APIs should provide all the services you need.

For more information about OS X and iOS security features, read Authentication, Authorization, and Permissions

Guide .

Social Engineering

Often the weakest link in the chain of security features protecting a user’s data and software is the user himself.

As developers eliminate buffer overflows, race conditions, and other security vulnerabilities, attackers increasingly

concentrate on fooling users into executing malicious code or handing over passwords, credit-card numbers,

and other private information. Tricking a user into giving up secrets or into giving access to a computer to an

attacker is known as social engineering.

For example, in February of 2005, a large firm that maintains credit information, Social Security numbers, and

other personal information on virtually all U.S. citizens revealed that they had divulged information on at least

150,000 people to scam artists who had posed as legitimate businessmen. According to Gartner (www.gart-

ner.com), phishing attacks cost U.S. banks and credit card companies about $1.2 billion in 2003, and this number

is increasing. They estimate that between May 2004 and May 2005, approximately 1.2 million computer users

in the United States suffered losses caused by phishing.

Software developers can counter such attacks in two ways: through educating their users, and through clear

and well-designed user interfaces that give users the information they need to make informed decisions.

For more advice on how to design a user interface that enhances security, see “Designing Secure User

Interfaces” (page 74).

Types of Security Vulnerabilities

Social Engineering

Buffer overflows, both on the stack and on the heap, are a major source of security vulnerabilities in C,

Objective-C, and C++ code. This chapter discusses coding practices that will avoid buffer overflow and underflow

problems, lists tools you can use to detect buffer overflows, and provides samples illustrating safe code.

Every time your program solicits input (whether from a user, from a file, over a network, or by some other

means), there is a potential to receive inappropriate data. For example, the input data might be longer than

what you have reserved room for in memory.

When the input data is longer than will fit in the reserved space, if you do not truncate it, that data will overwrite

other data in memory. When this happens, it is called a buffer overflow. If the memory overwritten contained

data essential to the operation of the program, this overflow causes a bug that, being intermittent, might be

very hard to find. If the overwritten data includes the address of other code to be executed and the user has

done this deliberately, the user can point to malicious code that your program will then execute.

Similarly, when the input data is or appears to be shorter than the reserved space (due to erroneous assumptions,

incorrect length values, or copying raw data as a C string), this is called a buffer underflow. This can cause any

number of problems from incorrect behavior to leaking data that is currently on the stack or heap.

Although most programming languages check input against storage to prevent buffer overflows and underflows,

C, Objective-C, and C++ do not. Because many programs link to C libraries, vulnerabilities in standard libraries

can cause vulnerabilities even in programs written in “safe” languages. For this reason, even if you are confident

that your code is free of buffer overflow problems, you should limit exposure by running with the least privileges

possible. See “Elevating Privileges Safely” (page 60) for more information on this topic.

Keep in mind that obvious forms of input, such as strings entered through dialog boxes, are not the only

potential source of malicious input. For example:

Buffer overflows in one operating system’s help system could be caused by maliciously prepared embedded

images.

A commonly-used media player failed to validate a specific type of audio files, allowing an attacker to

execute arbitrary code by causing a buffer overflow with a carefully crafted audio file.

[

CVE-2006-1591

CVE-2006-1370]

There are two basic categories of overflow: stack overflows and heap overflows. These are described in more

detail in the sections that follow.

Avoiding Buffer Overflows and Underflows

剩余122页未读，继续阅读

TonsonMiao

粉丝: 33
资源: 7

安全编码指南：抵御黑客攻击

SecureCodingGuide.pdf

Secure Coding Guide (Apple Inc)

数据手册-SN75176B-datasheet.zip

基于javaswing酒店点餐系统

WinPE-26241.5000-ReFS-v3.14.wim

Kubernetes系统精讲 Go语言实战K8S集群可视化--第8章 【核心知识+原理分析】将应用和配置分离.zip

节能减排商品类别.doc

三废污染+区域经济数据整理-最新出炉.zip

评标委员会成员评标意见表.doc

E056AER部分文献及其复现数据与程序_共37篇-最新出炉.zip

最新资源

Kubernetes系统精讲 Go语言实战K8S集群可视化--第8章【核心知识+原理分析】将应用和配置分离.zip