Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.
- In this chapter, we'll discuss general security principles. These principles are the foundation for the specific issues that we'll cover in later chapters. If new technologies emerge in the future, these core principles can still guide you. They are fundamental to all of security. We'll start by talking about the principle of least privilege. Think about your house or your apartment. Who do you give keys to? You might give keys to a family member, your next door neighbor, or to a trusted friend. However, you would not give keys to all of your family, or all of your neighbors, or all of your friends. You control and limit the access to your personal property. Many office buildings have security guards who regulate access. If you work in such a building, you may only have access to some floors or some departments. Even within those areas, there may be spaces that are off-limits to you, such as a server room, a supply closet, or even certain filing cabinets. These real-world examples of limiting access make common sense. Some people have access, while others don't. They are only given additional access privileges when it's necessary. The default is to not grant access. It's a lot like being on a need-to-know basis, but it's a need-to-have-access basis. The same principle applies to digital security. We call it the principle of least privilege. Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job. The principle of least privilege means giving a user account only those privileges which are essential to that user's work, and nothing more. If a user's job is only to edit website text, then they should not be able to browse a list of paying customers. Users in human resources should not be able to see accounting information, and users in accounting should not be able to see human resource information. Any user with limited privileges should never have enough system access to edit their own privileges. The principle of least privilege applies to every program as well as to every user. As such, it can be applied to APIs, system resources, database access, software version control, and even public-facing webpages, which grant access to different types of customers or to staff members. Now let's consider code access. Code needs access privileges applied to it, too. You should apply the principle of least privilege to your code and limit what is available to other code. Let's use some PHP code as an example. Notice that all of the variables and functions in this class are marked as being public. That makes them callable by other code, code which is outside this class. They do not need to be public. They will only be used internally by the user class itself. The only function that needs to be callable by code outside this class is authenticate. The other items can be marked private. This limits access to the code inside the user class and follows the principle of least privilege. Wherever you apply the principle of least privilege, the idea is to control access to systems and resources. You do that by granting as little access as possible. It is also important to have procedures in place to remove access when it's no longer needed. If someone leaves your organization, they should have to turn in their physical keys and all their digital access should be revoked at the same time. This is especially true if you work with contractors who may come and go more frequently than full-time staff. The principle of least privilege increases security because any vulnerabilities are limited and localized. It's always bad to have an account hacked, but the damage is far less if the hacked account has limited privileges. The principle of least privilege is one of the most important security principles, and you should apply to everything you do.
- Threat models
- Least privilege
- Defense in depth
- Validating and sanitizing input
- Credential attacks
- SQL injection
- Cross-site scripting