iOS安全编码指南 Secure Coding Guide -- 02 Types of Security Vulnerabilities 上

IOS安全编码指南 Secure Coding Guide -- 02 Types of Security Vulnerabilities 上

Most software security vulnerabilities(|ˌvʌlnərəˈbɪləti|) fall into one of a small set of categories:

• buffer overflows
• unvalidated input
• race conditions
• access-control problems
• weaknesses in authentication(|ɔːˌθentɪˈkeɪʃn| n 验证), authorization(|ˌɔːθəraɪˈzeɪʃn| n 授权、批准), or cryptographic([ˌkrɪptə'græfɪk] adj 有关密码的、用密码写的) practices

This chapter describes the nature of each type of vulnerability.

Buffer Overflows

    A buffer overflow occurs when an application attempts to write data past the end (or, occasionally, past the beginning) of a buffer.

          occasional |əˈkeɪʒənl| adjective 偶尔的

          occasionally |əˈkeɪʒənəli| adverb 偶尔

    Buffer overflows can cause applications to crash, can compromise data, and can provide an attack vector for further privilege escalation to compromise the system on which the application is running.

          vector |ˈvektə(r)| n 矢量、向量、航线

          escalation |ˌeskəˈleɪʃn| noun 上涨、加剧、恶化

    Books on software security invariably mention buffer overflows as a major source of vulnerabilities. Exact numbers are hard to come by, but as an indication, approximately 20% of the published exploits reported by the United States Computer Emergency Readiness Team (US-CERT) for 2004 involved buffer overflows.

          invariably |ɪnˈveərɪəbli| adverb 一贯地

          mention |ˈmenʃn| transitive verb 提到 

          approximately |əˈprɒksɪmətli| adverb 大约

          emergency |ɪˈmɜːdʒənsi| noun Uncountable and countable 紧急情况

          readiness |ˈredɪnɪs| noun Uncountable 准备就绪、乐意、敏捷

    Any application or system software that takes input from the user, from a file, or from the network has to store that input, at least temporarily(|ˈtempərəli, American -pərerɪli| 临时地). Except in special cases(除了少数特殊情况), most application memory is stored in one of two places:

• stack—A part of an application’s address space that stores data that is specific to a single call to a particular function, method, block, or other equivalent construct.
• heap—General purpose storage for an application. Data stored in the heap remains(v 逗留、遗留) available as long as the application is running (or until the application explicitly(|ɪkˈsplɪsɪtli| adv 明确地、坦率地、生动地) tells the operating system that it no longer needs that data).Class instances, data allocated with malloc, core foundation objects, and most other application data resides(|rɪˈzaɪd| v 居住、属于) on the heap. (Note, however, that the local variables that actually point to the data are stored in the stack.)

    Buffer overflow attacks generally occur by compromising either the stack, the heap, or both. For more information, read Avoiding Buffer Overflows and Underflows

Unvalidated Input

    As a general rule, you should check all input received by your program to make sure that the data is reasonable.

For example, a graphics file can reasonably contain an image that is 200 by 300 pixels, but cannot reasonably contain an image that is 200 by -1 pixels. Nothing prevents a file from claiming(claim |kleɪm| v 声称、要求) to contain such an image, however (apart from(除了) convention(|kənˈvenʃn| n 大会、习俗、惯例) and common sense). A naive program attempting to read such a file would attempt to allocate a buffer of an incorrect size, leading to(导致) the potential for a heap overflow attack or other problem. For this reason, you must check your input data carefully. This process is commonly known as input validation or sanity(|ˈsænəti| n 精神正常、通情达理) checking.

    Any input received by your program from an untrusted source is a potential target for attack. (In this context, an ordinary(|ˈɔːdənri, American ˈɔːrdəneri| adj 普通的、一般的、平庸的) user is an untrusted source.) Examples of input from an untrusted source include (but are not restricted(restrict |rɪˈstrɪkt| v 限制、控制) to):

• text input fields
• commands passed through a URL used to launch the program
• audio, video, or graphics files provided by users or other processes and read by the program
• command line input(命令行输入)
• any data read from an untrusted server over a network
• any untrusted data read from a trusted server over a network (user-submitted HTML or photos on a bulletin board, for example)

    Hackers look at every source of input to the program and attempt to pass in malformed(|ˌmælˈfɔːmd| 畸形的) data of every type they can imagine. If the program crashes or otherwise misbehaves(行为不端、发生故障), the hacker then tries to find a way to exploit the problem. Unvalidated-input exploits have been used to take control of operating systems, steal data, corrupt users’ disks, and more. One such exploit was even used to “jail(监狱) break(越狱)” iPhones.

    Validating Input and Interprocess Communication describes common types of input-validation vulnerabilities and what to do about them.

Race Conditions(竞态条件、竞争条件)

    A race condition exists when changes to the order of two or more events can cause a change in behavior. If the correct order of execution is required for the proper(|ˈprɒpə(r)| adj 合适的、适当的、正确的) functioning of the program, this is a bug. If an attacker can take advantage of the situation to insert malicious code, change a filename, or otherwise interfere(|ˌɪntəˈfɪə(r)| v 插手、妨碍、干涉) with the normal operation of the program, the race condition is a security vulnerability. Attackers can sometimes take advantage of small time gaps(gap |gæp| n 空隙、间隔) in the processing of code to interfere with the sequence(|ˈsiːkwəns| n 一系列、顺序) of operations, which they then exploit.

    For more information about race conditions and how to prevent them, read Race Conditions and Secure File Operations.

Interprocess Communication

    Separate(|ˈsepərət| adj 分开的) processes(进程)—either within a single program(程序) or in two different programs—sometimes have to share information. Common methods include using shared memory or using some messaging protocol, such as Sockets, provided by the operating system. These messaging protocols used for interprocess communication are often vulnerable to attack; thus, when writing an application, you must always assume that the process at the other end of your communication channel could be hostile(|ˈhɒstaɪl, American ˈhɒstl| adj 不友善的、反对的).

    For more information on how to perform secure interprocess communication, read Validating Input and Interprocess Communication.