2012年苹果安全编码指南：保护软件免受攻击关键

需积分: 10 83 浏览量更新于2024-07-18 收藏 1.14MB PDF 举报

Apple Secure Coding Guide 2012 是一份由 Apple 公司发布的官方文档，旨在提供编写安全代码的最佳实践指南，以保护用户数据免受恶意攻击和数据泄露的风险。这份文档适用于所有在 Macintosh 计算机和 iOS 设备上运行的软件开发人员，无论是个人脚本还是商业应用。它涵盖了多个关键的安全话题，确保软件在面对黑客、 crackers 和攻击者时具有足够的防护能力。首先，文档强调了没有平台能够免疫于安全威胁，因此了解并遵循这些原则至关重要。它提供了如何有效利用这份文档的指导，包括快速概览黑客行为和可能的攻击手段。安全漏洞主要分为几类： 1. **缓冲区溢出**：这是一种常见的攻击方式，通过超过预设大小的输入数据破坏程序内存，可能导致程序崩溃或被恶意控制。文档提供了避免和检测缓冲区溢出的策略，如正确计算缓冲区大小，以及使用验证输入的方法。 2. **未验证输入**：未经检查的用户输入可能导致代码执行意外操作，如 SQL 注入或代码注入。指南强调了输入验证的重要性，以防止这种风险。 3. **竞争条件（Race Conditions）**：当多个线程同时访问共享资源时，可能会导致数据不一致。文档教导开发者如何处理并发问题，确保数据的一致性和程序的稳定性。 4. **进程间通信（Interprocess Communication, IPC）**：不安全的 IPC 可能允许攻击者获取敏感信息或操控系统。文档指导开发者采用安全的通信机制。 5. **不安全的文件操作**：错误地读写文件可能暴露敏感数据或成为攻击入口。指南建议使用安全的文件操作模式，如权限管理和加密。 6. **访问控制问题**：确保只有授权用户和进程可以访问特定资源是至关重要的。文档讨论了如何实施有效的访问控制策略。 7. **安全存储与加密**：存储用户数据时，文档提倡使用加密技术来保护数据隐私。 8. **社会工程学攻击**：非技术性的欺骗手段也可能威胁到软件安全。开发者需要识别并防范这些心理攻击。 9. **其他攻击类型**：还包括如 Fuzzing（模糊测试）、代码插入、对已存数据的修改等，文档给出了相应的防御措施。最后，文档还涉及信号处理（Signal Handling）和网络通信的安全考虑，以全面保障应用程序在复杂环境中的安全性。 Apple Secure Coding Guide 2012 提供了一套全面的指南，帮助开发者构建安全的软件，降低被攻击的风险，并维护用户数据和系统的完整性和可靠性。通过遵循文档中的原则和技术，开发者可以在 Apple 平台上创建更安全的应用程序。

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 73).

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 59) 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

剩余113页未读，继续阅读

albertsouthwell

粉丝: 2
资源: 26

2012年苹果安全编码指南：保护软件免受攻击关键

SecureCodingGuide.pdf

secure coding in c and c++

java protect

小林coding计算机网络

python 安装arithmetic_coding

$ ssh -T git@git.coding.net ssh: connect to host git.coding.net port 22: Connection timed out 是什么意思 就是说git@git.coding.net这个要填自己的呗？

上传本地文件夹到coding

h = HuffmanCoding('example.txt') path = h.compress() h = HuffmanCoding(path) h.decompress(path)显示Name‘HuffmanCoding’is not defined

测试人员如何使用coding工具

最新资源

$ ssh -T git@git.coding.net ssh: connect to host git.coding.net port 22: Connection timed out 是什么意思就是说git@git.coding.net这个要填自己的呗？