Introduction to Secure Coding Guide
Secure coding is the practice of writing programs that are resistant to attack by malicious or mischievous people or programs. Secure coding helps protect a user’s data from theft or corruption. In addition, an insecure program can provide access for an attacker to take control of a server or a user’s computer, resulting in anything from a denial of service to a single user to the compromise of secrets, loss of service, or damage to the systems of thousands of users.
Secure coding is important for all software; if you write any code that runs on Macintosh computers or on iOS devices, from scripts for your own use to commercial software applications, you should be familiar with the information in this document.
At a Glance
Every program is a potential target. Attackers will try to find security vulnerabilities in your applications or servers. They will then try to use these vulnerabilities to steal secrets, corrupt programs and data, and gain control of computer systems and networks. Your customers’ property and your reputation are at stake.
Security is not something that can be added to software as an afterthought; just as a shed made out of cardboard cannot be made secure by adding a padlock to the door, an insecure tool or application may require extensive redesign to secure it. You must identify the nature of the threats to your software and incorporate secure coding practices throughout the planning and development of your product. This chapter explains the types of threats that your software may face. Other chapters in this document describe specific types of vulnerabilities and give guidance on code hardening techniques to fix them.
Hackers, Crackers, and Attackers
Contrary to the usage by most news media, within the computer industry the term hacker refers to an expert programmer—one who enjoys learning about the intricacies of code or an operating system. In general, hackers are not malicious. When most hackers find security vulnerabilities in code, they inform the company or organization that’s responsible for the code so that they can fix the problem. Some hackers—especially if they feel their warnings are being ignored—publish the vulnerabilities or even devise and publish exploits (code that takes advantage of the vulnerability).
The malicious individuals who break into programs and systems in order to do damage or to steal something are referred to as crackers, attackers, or black hats. Most attackers are not highly skilled, but take advantage of published exploit code and known techniques to do their damage.
Attackers may be motivated by a desire to steal money, identities, and other secrets for personal gain; corporate secrets for their employer’s or their own use; or state secrets for use by hostile governments or terrorist organizations. Some crackers break into applications or operating systems just to show that they can do it; nevertheless, they can cause considerable damage. Because attacks can be automated and replicated, any weakness, no matter how slight, can be exploited.
The large number of insiders who are attacking systems is of importance to security design because, whereas malicious hackers are most likely to rely on remote access to computers to do their dirty work, insiders might have physical access to the computer being attacked. Your software must be resistant to both attacks over a network and attacks by people sitting at the computer keyboard—you cannot rely on firewalls and server passwords to protect you.
No Platform Is Immune
So far, OS X has not fallen prey to any major, automated attack like the MyDoom virus. There are several reasons for this. One is that OS X is based on open source software such as BSD; many hackers have searched this software over the years looking for security vulnerabilities, so that not many vulnerabilities remain. Another is that the OS X turns off all routable networking services by default. Also, the email and internet clients used most commonly on OS X do not have privileged access to the operating system and are less vulnerable to attack than those used on some other common operating systems. Finally, Apple actively reviews the operating system and applications for security vulnerabilities, and issues downloadable security updates frequently.
iOS is based on OS X and shares many of its security characteristics. In addition, it is inherently more secure than even OS X because each application is restricted in the files and system resources it can access. Beginning in version 10.7, Mac apps can opt into similar protection.
That’s the good news. The bad news is that applications and operating systems are constantly under attack. Every day, black hat hackers discover new vulnerabilities and publish exploit code. Criminals then use that exploit code to attack vulnerable systems. Also, security researchers have found many vulnerabilities on a variety of systems that, if exploited, could have resulted in loss of data, allowing an attacker to steal secrets, or enabling an attacker to run code on someone else’s computer.
A large-scale, widespread attack is not needed to cause monetary and other damages; a single break-in is sufficient if the system broken into contains valuable information. Although major attacks of viruses or worms get a lot of attention from the media, the destruction or compromising of data on a single computer is what matters to the average user.
For your users’ sake, you should take every security vulnerability seriously and work to correct known problems quickly. If every Macintosh and iOS developer follows the advice in this document and other books on electronic security, and if the owner of each Macintosh takes common-sense precautions such as using strong passwords and encrypting sensitive data, then OS X and iOS will maintain their reputations for being safe, reliable operating systems, and your company’s products will benefit from being associated with OS X or iOS.
How to Use This Document
This document assumes that you have already read Security Overview.
The document begins with Types of Security Vulnerabilities, which gives a brief introduction to the nature of each of the types of security vulnerability commonly found in software. This chapter provides background information that you should understand before reading the other chapters in the document. If you’re not sure what a race condition is, for example, or why it poses a security risk, this chapter is the place to start.
The remaining chapters in the document discuss specific types of security vulnerabilities in some detail. These chapters can be read in any order, or as suggested by the software development checklist in Security Development Checklists.
Avoiding Buffer Overflows and Underflows describes the various types of buffer overflows and explains how to avoid them.
Validating Input and Interprocess Communication discusses why and how you must validate every type of input your program receives from untrusted sources.
Race Conditions and Secure File Operations explains how race conditions occur, discusses ways to avoid them, and describes insecure and secure file operations.
Elevating Privileges Safely describes how to avoid running code with elevated privileges and what to do if you can’t avoid it entirely.
Designing Secure User Interfaces discusses how the user interface of a program can enhance or compromise security and gives some guidance on how to write a security-enhancing UI.
Designing Secure Helpers and Daemons describes how to design helper applications in ways that are conducive to privilege separation.
In addition, the appendix Security Development Checklists provides a convenient list of tasks that you should perform before shipping an application, and the appendix Third-Party Software Security Guidelines provides a list of guidelines for third-party applications bundled with OS X.
This document concentrates on security vulnerabilities and programming practices of special interest to developers using OS X or iOS. For discussions of secure programming of interest to all programmers, see the following books and documents:
See Viega and McGraw, Building Secure Software, Addison Wesley, 2002; for a general discussion of secure programming, especially as it relates to C programming and writing scripts.
See Wheeler, Secure Programming for Linux and Unix HOWTO, available at http://www.dwheeler.com/secure-programs/; for discussions of several types of security vulnerabilities and programming tips for UNIX-based operating systems, most of which apply to OS X.
See Cranor and Garfinkel, Security and Usability: Designing Secure Systems that People Can Use, O’Reilly, 2005; for information on writing user interfaces that enhance security.
For documentation of security-related application programming interfaces (APIs) for OS X (and iOS, where noted), see the following Apple documents:
For an introduction to some security concepts and to learn about the security features available in OS X, see Security Overview.
For information on OS X authorization and authentication APIs, see Authentication, Authorization, and Permissions Guide, Authorization Services Programming Guide, Authorization Services C Reference, and Security Foundation Framework Reference.
For information about security in web application design, visit http://www.owasp.org/.