Top 15 Software Security Weaknesses Or Why are there so many zero days (Part 2)
Zero Day Vulnerabilities
Zero day vulnerabilities are merely software bugs that affect the security of applications.? ? More software = more bugs.? MITRE has studied the correlation between zero-day/security flaws and the programming and design errors that lead to them.
This is the second of three planned articles on the most common reasons that zero days find their way into software.? ? If you have not, please start with Part 1, it sets the scene.
Security Bugs - Software Weaknesses
Continuing with the analysis from MITRE identifying most frequent causes of application security problems.???
10) Unrestricted Upload of File with Dangerous Type
Always check that an uploaded file is what the uploader (and the file extension) says it is.? ? Arbitrary code execution is possible if an uploaded file is interpreted and executed as code by the recipient. This is especially true for .asp and .php extensions uploaded to web servers because these file types are often treated as automatically executable, even when file system permissions do not specify execution. For example, in Unix environments, programs typically cannot run unless the execute bit is set, but PHP programs may be executed by the web server without directly invoking them on the operating system.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.??
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
9) Cross-Site Request Forgery (CSRF)
When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, it is possible for an attacker to trick a client into making an unintentional request to the web server which will be treated as an authentic request. This can be done via a URL, image load, XMLHttpRequest, etc. and can result in exposure of data or unintended code execution.
The consequences will vary depending on the nature of the functionality that is vulnerable to CSRF. An attacker could effectively perform any operations as the victim. If the victim is an administrator or privileged user, the consequences may include obtaining complete control over the web application - deleting or stealing data, uninstalling the product, or using it to launch other attacks against all of the product's users. Because the attacker has the identity of the victim, the scope of CSRF is limited only by the victim's privileges. ? This is frequently the mechanism used to install credit card skimmer code on an e-commerce website.
When building web based applications, use a vetted library or framework that provides measures that make this weakness easier to avoid.? ? OWASP provides some good tools to help lock down your web application from CSRF. ? Check out CSRFGuard and the ESAPI Session Management control framework.
8) Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Many file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin", which may also be useful in accessing unexpected files. This is referred to as absolute path traversal.
In many programming languages, the injection of a null byte (the 0 or NULL) may allow an attacker to truncate a generated filename to widen the scope of attack. For example, the software may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.
领英推荐
7)? Use After Free
The attempt to use previously-freed memory can have any number of unintended consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system's reuse of the freed memory.?
MITRE posits that use-after-free errors have two common and sometimes overlapping causes:
In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process.
At the risk of offending some religious sensibilities (and sounding like a cranky old man) here, I also blame the academic community for this one.? ? Students form their fundamental programming habits during the first couple of semesters in computer science programs.? ? Too often these early programming fundamentals courses are conducted in Python or Java which provides memory management seatbelts and the students never have to contend with (and debug) the dreaded words:
$ ./my_prog
Segmentation Fault (core dumped)
When students don’t learn proper memory management as students, they fail to do it as professionals.
?… Stepping off the soapbox …
6) OS Command Injection
When software constructs all or part of an OS command using externally-influenced input from an upstream component, but does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.???
This could allow attackers to execute unexpected, dangerous commands directly on the operating system. This weakness can lead to a vulnerability in environments in which the attacker does not have direct access to the operating system, such as in web applications. If the weakness occurs in a privileged program, it could allow the attacker to specify commands that normally would not be accessible, or to call alternate commands with privileges that the attacker does not have.?
This is pretty basic stuff and should be treated much like checking input in the same manner that would be done to prevent SQL Injection.? ? However, if I am the architect or security officer assigned to the development effort, my opinion would be “Just say no!”.? ? If at all possible, use library calls rather than external processes to recreate the desired functionality.????
If the function cannot be achieved through library use, run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. ? OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
Next Week?
Next week I will complete the top 15 list. ? Stay tuned.