INTRODUCTION

THE WORLD IN WHICH WE USE TODAY'S IMACS AND MACBOOKS has little in common with the world of the first Macintosh computer Steve Jobs unveiled in 1984. The idea that everybody would be using a computer at home and at work — and indeed on the road — with permanent connections to the rest of the world via the Internet would have been thought out of the question back then. Forget completely the idea that people could carry full-featured computer/telephone/music player/camera devices in their jeans pockets. Or that you would be able to use your laptop or even your mobile phone to organize your finances with your bank, buy the latest movies, and get on with your work while away from the office. Taken to the extreme now, such technology is actually starting to provide dynamic connections between the digital and physical world — for example allowing you to photograph a physical object and associate it with online content such as a shop store or reviews. This is undoubtedly convenient, but it also brings new risks that were unheard of when the computers, their operating systems, and many of their applications were designed.

The organization Fight Identity Theft (http://www.fightidentitytheft.com) claims that identity theft cost 8.4 million Americans a total of $49.3 billion in 2008. The impact on any individual victim can be ruinous. As a result, this and other "cybercrimes" receive a lot of coverage in the media. It's reported frequently that a company or government department has leaked thousands of personal records; the hit the organization's reputation takes can easily be worse than the direct liability for the loss, such as government fines. Therefore, the total cost of the crime is unknown — businesses prefer not to disclose details unless obliged to, so we don't find exact figures for corporate identity theft. However, it is evident just from visible cases that the impact of such misconduct can be vast, and since the commercial world is increasingly underpinned by data as a key asset, security is high on the agenda of business risks.

Traditionally viruses, worms, and Trojan horses (collectively, "malware") have been seen by Mac users as Windows-only phenomena; they've quickly forgotten the Autostart problems of the 1990s and dismissed modern OS X malware as proof-of-concept or otherwise something that "real" Mac users need not worry about. Presumably the Mac malware infects only those machines owned by fake Mac owners, whoever they are. The reality is, of course, somewhat different from this simplistic picture. It's true that much less malicious software is known to target the Mac. But the way this software is sent to the victim's computer, the way the user is tricked into installing it, and the actions it takes once installed are the same on both platforms. Many attacks now involve a web server's detecting whether the user has a Mac or PC, and sending the appropriate malware in each case, as described in http://blog.trendmicro.com/more-mac-malware-in-the-wild/.

A successful attack does not need to start with the user's downloading a malicious application such as a Trojan horse. A whole class of "data-driven" attacks relies on being able to subvert a legitimate application to the attacker's ends by feeding it data that it cannot handle properly. A well-publicized example is one of the early "jail-breaking" tools for the iPhone, which used an error in the way Mobile Safari loaded TIFF images to cause Mobile Safari to run the jail-breaking code.

Then there are the more personal security compromises, which don't generate as many headlines or column inches as the big cybercrimes but nonetheless cause the victims to question their choice of applications and vendors. Finding that someone else has posted to the victim's Twitter account, or that his or her partner has been reading private e-mails or online banking statements, are examples of this form of attack.

Despite all these problems, there is no need to paint a picture of doom. If mitigating risk in software were a futile effort, there would be no need for the rest of this book. In Mac OS X and the iPhone OS, Apple has made a number of significant enhancements to the traditional UNIX platform design in order to improve its relevance in the 21st century. You, as a software developer working on those platforms, can easily spend some small amount of time on security considerations when designing your applications, which results in a big return for your users who receive a more secure product. You can identify the risks that will be present when the application is deployed to your users, and work to reduce the impact of those risks. The risks you deal with will be those that are relevant to the modern environment, with its modern threats; you don't need to (and indeed no longer can) rely on application conventions from the 1980s. You can develop your applications with an eye on security, so that they cannot be hijacked as they help their users communicate with people across the world. You can also communicate with your users in an open and honest manner, so that they understand the risks you're helping them to avoid, those risks you aren't, and the users' part in reducing all of them.

In Mac OS X and the iPhone OS, Apple has provided a number of APIs and security features that you can take advantage of in your applications to improve the security of those applications. Integrating with these features is as much a part of the overall user experience as is integration with "headline" features such as Spotlight or Automator. By providing a security experience consistent with those of the built-in and third-party applications, you make it easier for your users to understand how to get their work done in your applications with little risk. This reduces the mental effort they must spend on using the application, and makes it less likely that they will make mistakes in using or configuring it — just as developing with an eye on usability and accessibility helps to provide an easier user experience. Users enjoy being pleasantly surprised by the ease of using your application; they do not enjoy being surprised to find that it's sharing their information with the world when they thought it was not.

The purpose of this book is twofold. First, I hope to show how we developers of Mac and iPhone applications can reason about the security requirements of our users and the risks to which our applications are exposed. Then you can examine the security features and APIs available on the Mac and iPhone platforms in the context of that fresh understanding of your apps, to see how to reduce risks and provide your customers with a secure experience.

WHO SHOULD READ THIS BOOK

This book is for Cocoa and Cocoa Touch developers who are interested in ensuring that their applications provide a secure experience. You do not need any experience or familiarity with security principles or secure application development. I do assume that you are comfortable with the C and Objective-C languages, and familiar enough with the APIs that the discussions of code samples can focus on the aspect directly relevant to the matter at hand.

Perhaps you're reading this thinking, "But my app is so small, and doesn't have anything of value, so why would hackers target me"? First, disabuse yourself of the idea that all security risks come from pimply teenagers "hacking" their way into important computers from their parents' basements. The attacker could easily be an otherwise legitimate user of your app who has found a way to subvert it for his or her own needs, whether to craft a fake high-score entry for an online game or to read documents to which the user should not have access. The attack could even be entirely accidental: a user who mistakenly deletes critical data from an application has unintentionally exploited a weakness in that application. These possibilities will be explored throughout the rest of the book.

Nonetheless, consider the accuracy of the traditional view of the hacker. Is this person trying to compromise your app specifically? Maybe, if the purpose is to show that some competitor's app is a better choice. The attacker could have some other target in mind, for which your application provides a convenient stepping stone. Perhaps the idea is to get a document from a user who also has your application installed. Maybe your app uses some web service such as a social networking site, and it's that site the hacker is targeting. Maybe the hacker just wants to show that a Mac (or iPhone) can be compromised, and any application is fair game in proving that point. In January 2007, a project known as the "Month of Apple Bugs" (http://projects.info-pull.com/moab/) was launched, with the aim of publicizing security problems on the Mac platform. A large fraction of the vulnerabilities reported in that month did not affect Mac OS X itself, or even Apple's software, but third-party applications that run on the Mac platform. You have to agree with Michael Howard and David LeBlanc, who in their book Writing Secure Code said, "The defender must defend all points; the attacker can choose the weakest point." The security profile of a user's system depends on the concerted efforts of all the developers who write all the apps the user relies on.

WHAT ARE WE TRYING TO SECURE, AND FROM WHAT?

The first chapter of this book provides an overview of the security considerations to take into account when designing an application. Its message can easily be distilled into one sentence: know your app and its users. There, that's it; you can stop reading now (though I still recommend you buy the whole book because the wordy version is more interesting, I promise you that much). Without an understanding of what your users are trying to get done, whom they're communicating with to get it done, and how they're communicating, you cannot possibly know which security techniques are relevant to your application. Time you spend on adding irrelevant security countermeasures is time (and money) wasted with no valuable return — imagine building the Great Wall today to protect China from an enemy armed with cruise missiles.

In fact you can even do worse than build irrelevant countermeasures — you can build ones that stop your users from getting their work done. Increasingly, modern applications experience the challenge of flexibility vs. security. As we interact in a more connected world, the balance of these two objectives is being stressed more each day. There's a cliché in the security world that the most secure computer is one that is disconnected from the power supply, encased in a concrete block, and sunk to the bottom of an ocean. That's great, but how do I check my mail on it? If the reason I want a computer is to check my mail, and I can't, then the so-called security is actively working against me. I'll choose a different computer that doesn't have that "protection," and the person who poured the concrete has lost a sale.

The point of this story is that there is no such thing as a "most secure" or "perfectly secure" system or application. Many are appropriately secure, and even more could be made appropriately secure with very little effort correctly applied. This book is intended to help you decide what is appropriately secure for your users, and then how to use the tools at your disposal to achieve that security. Appropriate security means that you provide a reasonably risk-free user experience; you do not stop the user at every turn with a password prompt to keep the bad guys out. While this book will help you reason about the security model of your application, it cannot possibly be a substitute for performing that reasoning yourself. Turning to the last code sample now and typing the example source into your app will not add security pixie dust to the app; unfortunately, the security pixies do not exist (though I expect one of the anti-virus vendors might use them in its marketing someday).

By knowing what the users (and, of course, the attackers) want to do, you can easily identify the most important risks to the application. You can then work to mitigate just those risks — a wise and fruitful investment in your application's development. Some of the risks you find may be reduced by a different application design. Others may be mitigated by your taking advantage of Mac OS X or iPhone OS security features; this is the focus of Chapters 2 through 8. Still others may require careful coding to avoid buffer overruns or the mishandling of incoming data, which is addressed in Chapter 9.

Of course you will want to choose a point where sufficient, but not excessive, energy and time have been spent on the application and it is ready to ship. Security is no different from features, graphics, or bug fixes in this regard: put in too much time and the returns will decrease, all the while giving your competitors more time to ship their apps. Chapter 10 describes the security implications of shipping software, including security documentation, and handling any security issues that arise in the field.

Finally, Chapter 11 takes a brief tour through the world of Mac OS X kernel extensions. Kernel code operates in a significantly different environment from application code; it is important to understand this environment to produce secure kernel extensions.

ABOUT THE EXAMPLES

I hope you can tell that I believe the security considerations of app developers are highly dependent on the applications they are writing, and the environments and contexts within which their users operate. With that in mind, please take the code samples in this book in the spirit in which they are intended — as examples of using a particular API to achieve certain goals, rather than recipes to be pasted verbatim into other applications.

It may be that the risk addressed by one of the code samples is not one your application faces, so the effect of integrating the example would be to spend time and effort without any meaningful result. Worse, indiscriminately applying sample code to your application could increase some risks. For example, if you require authorization to enable some security feature (see Chapter 6 on performing privileged tasks), then it is harder for non-administrator users to enable that feature. Conversely, providing access to the feature to all comers might lead to a privilege escalation vulnerability — a problem discussed in Chapter 1. The only way to resolve the conflict is to weigh the importance of each risk — something that depends strongly on the specifics of your application. Of course, should you decide that the threat countered in the sample is one you need to address, feel free to use the code and techniques in the examples in your own application.

CONVENTIONS USED IN THIS BOOK

To help you get the most from the text and keep track of what's happening, we've used some conventions throughout the book. Typical examples follow:

A warning tells you that something terrible will happen should a particular event occur. For example, if you perform a task incorrectly, you might see data loss.

As for styles in the text:

• We italicize new terms and important words when we introduce them.

• We show keyboard strokes like this: Ctrl+A.

• We show filenames, URLs, and code within the text like so: persistence.properties.

  We present code in the following way:

  We use a monofont type with no highlighting for most code examples.

  
  

SOURCE CODE

As you work through the examples in this book, you may choose either to type in all the code manually, or to use the source code files that accompany the book. All the source code used in this book is available for download at http://www.wrox.com. When at the site, simply locate the book's title (use the Search box or one of the title lists) and click the Download Code link on the book's detail page to obtain all the source code for the book. Code that is included on the web site is highlighted by the following icon:

Listings include the filename in the title. If it is just a code snippet, you'll find the filename in a code note such as this:

Once you download the code, just decompress it with your favorite compression tool. Alternately, you can go to the main Wrox code download page at http://www.wrox.com/dynamic/books/download.aspx to see the code available for this book and all other Wrox books.

ERRATA

We make every effort to ensure that there are no errors in the text or in the code. However, no one is perfect, and mistakes do occur. If you find an error in one of our books, like a spelling mistake or faulty piece of code, we would be very grateful for your feedback. By sending in errata you may save another reader hours of frustration and at the same time you will be helping us provide even higher quality information.

To find the errata page for this book, go to http://www.wrox.com and locate the title using the Search box or one of the title lists. Then, on the Book Search Results page, click the Errata link. On this page you can view all errata that has been submitted for this book and posted by Wrox editors.

If you don't spot "your" error on the Errata page, click the Errata Form link and complete the form to send us the error you have found. We'll check the information and, if appropriate, post a message to the book's errata page and fix the problem in subsequent editions of the book.

P2P.WROX.COM

For author and peer discussion, join the P2P forums at p2p.wrox.com. The forums are a Web-based system for you to post messages relating to Wrox books and related technologies and interact with other readers and technology users. The forums offer a subscription feature to e-mail you topics of interest of your choosing when new posts are made to the forums. Wrox authors, editors, other industry experts, and your fellow readers are present on these forums.

At http://p2p.wrox.com you will find a number of different forums that will help you not only as you read this book, but also as you develop your own applications. To join the forums, just follow these steps:

Once you join, you can post new messages and respond to messages other users post. You can read messages at any time on the Web. If you would like to have new messages from a particular forum e-mailed to you, click the Subscribe to This Forum icon by the forum name in the forum listing.

For more information about how to use the Wrox P2P, be sure to read the P2P FAQs for answers to questions about how the forum software works as well as many common questions specific to P2P and Wrox books. To read the FAQs, click the FAQ link on any P2P page.