cwe.mitre.org/top25 -> cwe.mitre.org/top25/
pdf) Date: January 12, 2009 Project Coordinators: Bob Martin (MITRE) Mason Brown (SANS) Alan Paller (SANS) Document Editor: Steve Christey (MITRE) Introduction Introduction The 2009 CWE/SANS Top 25 Most Dangerous Programming Errors is a list of the most significant programming errors that can lead to serious software vulnerabilities. They occur frequently, are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all. The list is the result of collaboration between the SANS Institute, MITRE, and many top software security experts in the US and Europe. MITRE maintains the CWE web site, with the support of the US Department of Homeland Security's National Cyber Security Division, presenting detailed descriptions of the top 25 programming errors along with authoritative guidance for mitigating and avoiding them. The CWE site also contains data on more than 700 additional programming errors, design errors, and architecture errors that can lead to exploitable vulnerabilities. The main goal for the Top 25 list is to stop vulnerabilities at the source by educating programmers on how to eliminate all-too-common mistakes before software is even shipped. The list will be a tool for education and awareness that will help programmers to prevent the kinds of vulnerabilities that plague the software industry. Software consumers could use the same list to help them to ask for more secure software. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software.
Appendix C: Other Resources for the Top 25 Brief Listing of the Top 25 Brief Listing of the Top 25 The Top 25 is organized into three high-level categories that contain multiple CWE entries. Insecure Interaction Between Components These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems.
CWE-209: Error Message Information Leak Risky Resource Management The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources.
CWE-682: Incorrect Calculation Porous Defenses The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored.
feedback, including software developers, scanning tool vendors, security consultants, government representatives, and university professors. Several intermediate versions were created and resubmitted to the reviewers before the list was finalized.
threat model was developed that identifies an attacker who has solid technical skills and is determined enough to invest some time into attacking an organization.
Appendix B Weaknesses in the Top 25 were selected using two primary criteria: * Weakness Prevalence: how often the weakness appears in software that was not developed with security integrated into the software development life cycle (SDLC). Prevalence was determined based on estimates from multiple contributors to the Top 25 list, since appropriate statistics are not readily available. With these criteria, future versions of the Top 25 will evolve to cover different weaknesses.
Organization of the Top 25 Organization of the Top 25 For each individual weakness entry, additional information is provided. The primary audience is intended to be software programmers and designers. Developers may choose one or more of these mitigations to fit their own needs. Note that the effectiveness of these techniques vary, and multiple techniques may be combined for greater defense-in-depth. Other Supporting Data Fields Each Top 25 entry includes supporting data fields for weakness prevalence and consequences.
CWE-20: Improper Input Validation Summary Weakness Prevalence High Consequences Code execution Denial of service Data loss Remediation Cost Low Ease of Detection Easy to Difficult Attack Frequency Often Attacker Awareness High Discussion It's the number one killer of healthy software, so you're just asking for trouble if you don't ensure that your input conforms with expectations. For example, an identifier that you expect to be numeric shouldn't ever contain letters. Nor should the price of a new car be allowed to be a dollar, not even in today's economy. Applications often have more complex validation requirements than these simple examples. Incorrect input validation can lead to vulnerabilities when attackers can modify their inputs in unexpected ways. Many of today's most common vulnerabilities can be eliminated, or at least reduced, using proper input validation. Prevention and Mitigations Architecture and Design Use an input validation framework such as Struts or the OWASP ESAPI Validation API. If you use Struts, be mindful of weaknesses covered by the CWE-101 category. Architecture and Design Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data to be displayed or stored. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue." Reject any input that does not strictly conform with specifications, or transform it into something that does. Architecture and Design Duplicate any client-side checks on the server side in order to avoid CWE-602. These checks only help reduce the amount of server processing time for normal users who do not know the format of required input. Attackers can bypass these mechanisms easily by intercepting parameters after the client-side checks and altering the values before they are submitted to the server. This should be simple to implement in terms of time and difficulty, and will greatly reduce the likelihood of insecure parameter values being used in the application. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, Ajax frameworks need to perform input validation to prevent DOM-based XSS and similar problems. Architecture and Design Do not rely exclusively on blacklist validation to detect malicious input or to encode output (CWE-184). There are too many ways to encode the same character, so you're likely to miss some variants. Implementation When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined. Implementation Be especially careful to validate your input when you invoke code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow. Implementation Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained. Implementation Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypas...
|
http://csua.com/feed/