Types of Security Vulnerabilities
1)内存空间安全、2)参量级别数据安全;3)通信级别数据安全;4)数据访问控制;5)通信对象身份确认。
https://developer.apple.com/library/content/documentation/Security/Conceptual/SecureCodingGuide/Articles/TypesSecVuln.html#//apple_ref/doc/uid/TP40002529-SW2
Most software security vulnerabilities fall into one of a small set of categories:
buffer overflows
unvalidated input
race conditions
access-control problems
weaknesses in authentication, authorization, or cryptographic 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.
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.
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.
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. 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 available as long as the application is running (or until the application explicitly 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 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 to contain such an image, however (apart from convention 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 checking.
Any input received by your program from an untrusted source is a potential target for attack. (In this context, an ordinary user is an untrusted source.) Examples of input from an untrusted source include (but are not restricted 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 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 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 with the normal operation of the program, the race condition is a security vulnerability. Attackers can sometimes take advantage of small time gaps in the processing of code to interfere with the sequence 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 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.
For more information on how to perform secure interprocess communication, read Validating Input and Interprocess Communication.
Insecure File Operations
In addition to time-of-check–time-of-use problems, many other file operations are insecure. Programmers often make assumptions about the ownership, location, or attributes of a file that might not be true. For example, you might assume that you can always write to a file created by your program. However, if an attacker can change the permissions or flags on that file after you create it, and if you fail to check the result code after a write operation, you will not detect the fact that the file has been tampered with.
Examples of insecure file operations include:
writing to or reading from a file in a location writable by another user
failing to make the right checks for file type, device ID, links, and other settings before using a file
failing to check the result code after a file operation
assuming that if a file has a local pathname, it has to be a local file
These and other insecure file operations are discussed in more detail in Securing File Operations.
Access Control Problems
Access control is the process of controlling who is allowed to do what. This ranges from controlling physical access to a computer—keeping your servers in a locked room, for example—to specifying who has access to a resource (a file, for example) and what they are allowed to do with that resource (such as read only). Some access control mechanisms are enforced by the operating system, some by the individual application or server, some by a service (such as a networking protocol) in use. Many security vulnerabilities are created by the careless or improper use of access controls, or by the failure to use them at all.
Much of the discussion of security vulnerabilities in the software security literature is in terms of privileges, and many exploits involve an attacker somehow gaining more privileges than they should have. Privileges, also called permissions, are access rights granted by the operating system, controlling who is allowed to read and write files, directories, and attributes of files and directories (such as the permissions for a file), who can execute a program, and who can perform other restricted operations such as accessing hardware devices and making changes to the network configuration. File permissions and access control in OS X are discussed in File System Programming Guide.
Of particular interest to attackers is the gaining of root privileges, which refers to having the unrestricted permission to perform any operation on the system. An application running with root privileges can access everything and change anything. Many security vulnerabilities involve programming errors that allow an attacker to obtain root privileges. Some such exploits involve taking advantage of buffer overflows or race conditions, which in some special circumstances allow an attacker to escalate their privileges. Others involve having access to system files that should be restricted or finding a weakness in a program—such as an application installer—that is already running with root privileges. For this reason, it’s important to always run programs with as few privileges as possible. Similarly, when it is necessary to run a program with elevated privileges, you should do so for as short a time as possible.
Much access control is enforced by applications, which can require a user to authenticate before granting authorization to perform an operation. Authentication can involve requesting a user name and password, the use of a smart card, a biometric scan, or some other method. If an application calls the OS X Authorization Services application interface to authenticate a user, it can automatically take advantage of whichever authentication method is available on the user’s system. Writing your own authentication code is a less secure alternative, as it might afford an attacker the opportunity to take advantage of bugs in your code to bypass your authentication mechanism, or it might offer a less secure authentication method than the standard one used on the system. Authorization and authentication are described further in Security Overview.
Digital certificates are commonly used—especially over the Internet and with email—to authenticate users and servers, to encrypt communications, and to digitally sign data to ensure that it has not been corrupted and was truly created by the entity that the user believes to have created it. Incorrect or careless use of digital certificates can lead to security vulnerabilities. For example, a server administration program shipped with a standard self-signed certificate, with the intention that the system administrator would replace it with a unique certificate. However, many system administrators failed to take this step, with the result that an attacker could decrypt communication with the server. [CVE-2004-0927]
It’s worth noting that nearly all access controls can be overcome by an attacker who has physical access to a machine and plenty of time. For example, no matter what you set a file’s permissions to, the operating system cannot prevent someone from bypassing the operating system and reading the data directly off the disk. Only restricting access to the machine itself and the use of robust encryption techniques can protect data from being read or corrupted under all circumstances.
The use of access controls in your program is discussed in more detail in Elevating Privileges Safely.
Secure Storage and Encryption
Encryption can be used to protect a user’s secrets from others, either during data transmission or when the data is stored. (The problem of how to protect a vendor’s data from being copied or used without permission is not addressed here.) OS X provides a variety of encryption-based security options, such as
FileVault
the ability to create encrypted disk images
keychain
certificate-based digital signatures
encryption of email
SSL/TLS secure network communication
Kerberos authentication
The list of security options in iOS includes
passcode to prevent unauthorized use of the device
data encryption
the ability to add a digital signature to a block of data
keychain
SSL/TLS secure network communication
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.apple.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.
Types of Security Vulnerabilities的更多相关文章
- Java – 4 Security Vulnerabilities Related Coding Practices to Avoid---reference
This article represents top 4 security vulnerabilities related coding practice to avoid while you ar ...
- We found potential security vulnerabilities in your dependencies. Only the owner of this reposito...
删除package-lock.json并同步到git 定义的依赖项./package-lock.json具有已知的安全漏洞 找到一个叫做.gitignore,把package-lock.json贴在这 ...
- 转:PHP – Best Practises
原文来自于:http://thisinterestsme.com/php-best-practises/ There are a number of good practises that you s ...
- Windows Kernel Security Training Courses
http://www.codemachine.com/courses.html#kerdbg Windows Kernel Internals for Security Researchers Thi ...
- Security Testing Basics
Security Testing BasicsSoftware security testing is the process of assessing and testing a system to ...
- [Security] Web Security Essentials
In this course, we'll learn how to exploit and then mitigate several common Web Security Vulnerabili ...
- What is XMLHTTP? How to use security zones in Internet Explorer
Types of Security Zones Internet Zone This zone contains Web sites that are not on your computer or ...
- Spring Security(十九):6. Security Namespace Configuration
6.1 Introduction Namespace configuration has been available since version 2.0 of the Spring Framewor ...
- Atlassian - Confluence Security Advisory - 2019-03-20
-------------------- This problem refers to the advisory found at https://confluence.atlassian.com/d ...
随机推荐
- data对象转化成后端需要的json格式
data=JSON.stringify(json_data); $.ajax({type:'post',url:url+'warehouse/create_alliance_out/',data:da ...
- 推荐几本javascript与jquery的好书
有人说只要了解了javascript的基本语法,就可以通过看别人的代码来学习javascript了,我不敢苟同.代码是死的,它很难让你有自己的想法,而一本好书如果结构清晰,各个章节都立意明确循序渐进( ...
- Appium+python自动化
名称 链接地址 Appium+python自动化8-Appium Python API(上) http://mp.weixin.qq.com/s/WvpT5oRrYY22avI95FuypQ Appi ...
- 879C
贪心 题目看错了...还以为是从操作序列中选5个...然后半个小时没了... 我们把每位分别用0和1带入,看看返回值是什么,然后分类讨论.千万不用特判!!!之前忘了删了就fst... #include ...
- 用python写windows服务
用python写windows服务(1) 以python2.5 为例需要软件 * python 2.5 * pywin32(与2.5 版本相匹配的) Service Control Ma ...
- 模态对话框 DoModal的用法 (vs2008)与非模态对话框
Windows对话框分为两类:模态对话框和非模态对话框. 模态对话框,当它弹出后,本应用程序其他窗口将不再接受用户输入,只有该对话框响应用户输入,在对它进行相应操作退出后,其他窗口才能继续与用户交互. ...
- Java:String之间通过==比较的情况
大家都知道在String之间的内容比较的时候,是通过equals函数比较的. 但是在在许多的面试题中,总是出现一堆的判断两个String对象通过==比较的结果,实际上是考的Java内存分配机制. Ja ...
- OpenCV视频的读写
实验室的项目是处理视频,所以就从视频的读取和写入开始吧! 常用的接口有C++和Python,Python肯定要简洁许多,不过因为项目需要,还是用C++了(PS:其实是我被Python的速度惊到了... ...
- Collection View Programming Guide for iOS---(五)---Incorporating Gesture Support
Incorporating Gesture Support 结合手势支持 You can add greater interactivity to your collection views th ...
- SVG动画 -- 描边动画
代码说明:纯CSS实现,无JS <!DOCTYPE html> <html lang="en"> <head> <meta charset ...