MITRE_Corp_2011_CWE_SANs_Top_25_Most_Dangerous_Software_Errors_v1.0.3.pdf

The MITRE Corporation

2011 CWE/SANS Top 25 Most Dangerous Software Errors Copyright © 2011 http://cwe.mitre.org/top25/

Document version: 1.0.3 Date: September 13, 2011

Project Coordinators:

Bob Martin (MITRE) Mason Brown (SANS) Alan Paller (SANS) Dennis Kirby (SANS)

Document Editor:

Steve Christey (MITRE)

Introduction

The 2011 CWE/SANS Top 25 Most Dangerous Software Errors is a list of the most widespread and critical errors that can lead to serious vulnerabilities in software. They 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 Top 25 list is a tool for education and awareness to help programmers to prevent the kinds of vulnerabilities that plague the software industry, by identifying and avoiding all-too-common mistakes that occur before software is even shipped. Software customers can use the same list to help them to ask for more secure software. Researchers in software security can use the Top 25 to focus on a narrow but important subset of all known security weaknesses. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software.

The list is the result of collaboration between the SANS Institute, MITRE, and many top software security experts in the US and Europe. It leverages experiences in the development of the SANS Top 20 attack vectors (http://www.sans.org/top20/) and MITRE's Common Weakness Enumeration (CWE) (http://cwe.mitre.org/). 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 contains data on more than 800 programming errors, design errors, and architecture errors that can lead to exploitable vulnerabilities.

The 2011 Top 25 makes improvements to the 2010 list, but the spirit and goals remain the same.

This year's Top 25 entries are prioritized using inputs from over 20 different organizations, who evaluated each weakness based on prevalence, importance, and likelihood of exploit. It uses the Common Weakness Scoring System (CWSS) to score and rank the final results. The Top 25 list covers a small set of the most effective "Monster Mitigations," which help developers to reduce or eliminate entire groups of the Top 25 weaknesses, as well as many of the hundreds of weaknesses that are documented by CWE.

Table of Contents

Guidance for Using the Top 25 Brief Listing of the Top 25 Category-Based View of the Top 25 Organization of the Top 25 http://cwedev1.mitre.org/index.html http://cwedev1.mitre.org/top25/ http://cwedev1.mitre.org/cwss/ http://cwedev1.mitre.org/cwraf/ http://cwe.mitre.org/cwss http://cwe.mitre.org/cwss

Detailed CWE Descriptions Monster Mitigations Appendix A: Selection Criteria and Supporting Fields Appendix B: What Changed in the 2011 Top 25 Appendix C: Construction, Selection, and Scoring of the Top 25 Appendix D: Comparison to OWASP Top Ten 2010 Appendix E: Other Resources for the Top 25 Changes to This Document

Guidance for Using the Top 25

Here is some guidance for different types of users of the Top 25.

User Activity

Programmers new to security

Read the brief listing, then examine the Monster Mitigations section to see how a small number of changes in your practices can have a big impact on the Top 25.

Pick a small number of weaknesses to work with first, and see the Detailed CWE Descriptions for more information on the weakness, which includes code examples and specific mitigations.

Programmers who are experienced in security

Use the general Top 25 as a checklist of reminders, and note the issues that have only recently become more common. Consult the See the On the Cusp page for other weaknesses that did not make the final Top 25; this includes weaknesses that are only starting to grow in prevalence or importance.

If you are already familiar with a particular weakness, then consult the Detailed CWE Descriptions and see the "Related CWEs" links for variants that you may not have fully considered.

Build your own Monster Mitigations section so that you have a clear understanding of which of your own mitigation practices are the most effective - and where your gaps may lie.

Consider building a custom "Top n" list that fits your needs and practices. Consult the Common Weakness Risk Analysis Framework (CWRAF) page for a general framework for building top-N lists, and see Appendix C for a description of how it was done for this year's Top 25. Develop your own nominee list of weaknesses, with your own prevalence and importance factors - and other factors that you may wish - then build a metric and compare the results with your colleagues, which may produce some fruitful discussions.

Software project managers

Treat the Top 25 as an early step in a larger effort towards achieving software security. Strategic possibilities are covered in efforts such as Building Security In Maturity Model (BSIMM), SAFECode, OpenSAMM, Microsoft SDL, and OWASP ASVS.

Examine the Monster Mitigations section to determine which approaches may be most suitable to adopt, or establish your own monster mitigations and map out which of the Top 25 are addressed by them.

Consider building a custom "Top n" list that fits your needs and practices. Consult the Common Weakness Risk Analysis Framework (CWRAF) page for a general framework for building top-N lists, and see Appendix C for a description of how it was done for this year's Top 25. Develop your own nominee list of weaknesses, with your own prevalence and importance factors - and other factors that you may wish - then build a metric and compare the results with your colleagues, which may produce some fruitful discussions.

http://cwe.mitre.org/top25/archive/2011/2011_onthecusp.html http://cwe.mitre.org/cwraf/index.html http://www.bsi-mm.com/ http://www.bsi-mm.com/ http://www.safecode.org/publications.php http://www.opensamm.org/ http://www.microsoft.com/security/sdl/ http://www.owasp.org/index.php/ASVS http://cwe.mitre.org/cwraf/index.html

Software Testers

Read the brief listing and consider how you would integrate knowledge of these weaknesses into your tests. If you are in a friendly competition with the developers, you may find some surprises in the On the Cusp entries, or even the rest of CWE.

For each indvidual CWE entry in the Details section, you can get more information on detection methods from the "technical details" link. Review the CAPEC IDs for ideas on the types of attacks that can be launched against the weakness.

Software customers

Recognize that market pressures often drive vendors to provide software that is rich in features, and security may not be a serious consideration. As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you. Use the Top 25 to help set minimum expectations for due care by software vendors. Consider using the Top 25 as part of contract language during the software acquisition process. The SANS Application Security Procurement Language site offers customer-centric language that is derived from the OWASP Secure Software Contract Annex, which offers a "framework for discussing expectations and negotiating responsibilities" between the customer and the vendor. Other information is available from the DHS Acquisition and Outsourcing Working Group.

Consult the Common Weakness Risk Analysis Framework (CWRAF) page for a general framework for building a top-N list that suits your own needs.

For the software products that you use, pay close attention to publicly reported vulnerabilities in those products. See if they reflect any of the associated weaknesses on the Top 25 (or your own custom list), and if so, contact your vendor to determine what processes the vendor is undertaking to minimize the risk that these weaknesses will continue to be introduced into the code.

See the On the Cusp summary for other weaknesses that did not make the final Top 25; this will include weaknesses that are only starting to grow in prevalence or importance, so they may become your problem in the future.

Educators Start with the brief listing. Some training materials are also available.

Users of the 2010 Top 25

See the What Changed section; while a lot has changed on the surface, this year's effort is more well-structured.

Brief Listing of the Top 25

This is a brief listing of the Top 25 items, using the general ranking.

NOTE: 16 other weaknesses were considered for inclusion in the Top 25, but their general scores were not high enough. They are listed in a separate "On the Cusp" page.

Rank Score ID Name

[1] 93.8 CWE-

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

[2] 83.3 CWE-

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

[3] 79.0 CWE-

120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

[4] 77.7 CWE-

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

[5] 76.9 CWE- Missing Authentication for Critical Function http://cwe.mitre.org/top25/archive/2011/2011_onthecusp.html http://cwe.mitre.org/ http://www.csoonline.com/article/467314/Who_Pushed_Vendors_Toward_Better_Security_ http://www.sans.org/appseccontract/ http://www.sans.org/appseccontract/ http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex https://buildsecurityin.us-cert.gov/swa/acqwg.html http://cwe.mitre.org/cwraf/index.html http://cwe.mitre.org/top25/archive/2011/2011_onthecusp.html http://cwe.mitre.org/top25/archive/2011/2011_training.html http://cwe.mitre.org/top25/archive/2011/2011_onthecusp.html

[6] 76.8 CWE-

862 Missing Authorization

[7] 75.0 CWE-

798 Use of Hard-coded Credentials

[8] 75.0 CWE-

311 Missing Encryption of Sensitive Data

[9] 74.0 CWE-

434 Unrestricted Upload of File with Dangerous Type

[10] 73.8 CWE-

807 Reliance on Untrusted Inputs in a Security Decision

[11] 73.1 CWE-

250 Execution with Unnecessary Privileges

[12] 70.1 CWE-

352 Cross-Site Request Forgery (CSRF)

[13] 69.3 CWE-

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

[14] 68.5 CWE-

494 Download of Code Without Integrity Check

[15] 67.8 CWE-

863 Incorrect Authorization

[16] 66.0 CWE-

829 Inclusion of Functionality from Untrusted Control Sphere

[17] 65.5 CWE-

732 Incorrect Permission Assignment for Critical Resource

[18] 64.6 CWE-

676 Use of Potentially Dangerous Function

[19] 64.1 CWE-

327 Use of a Broken or Risky Cryptographic Algorithm

[20] 62.4 CWE-

131 Incorrect Calculation of Buffer Size

[21] 61.5 CWE-

307 Improper Restriction of Excessive Authentication Attempts

[22] 61.1 CWE-

601 URL Redirection to Untrusted Site ('Open Redirect')

[23] 61.0 CWE-

134 Uncontrolled Format String

[24] 60.3 CWE-

190 Integer Overflow or Wraparound

[25] 59.9 CWE-

759 Use of a One-Way Hash without a Salt

CWE-89 - SQL injection - delivers the knockout punch of security weaknesses in 2011. For data-rich software applications, SQL injection is the means to steal the keys to the kingdom. CWE-78, OS command injection, is where the application interacts with the operating system. The classic buffer overflow (CWE-120) comes in third, still pernicious after all these decades. Cross-site scripting (CWE-79) is the bane of web applications everywhere. Rounding out the top 5 is Missing Authentication (CWE-306) for critical functionality.

Category-Based View of the Top 25

This section sorts the entries into the three high-level categories that were used in the 2009 Top 25:

Insecure Interaction Between Components Risky Resource Management Porous Defenses

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.

For each weakness, its ranking in the general list is provided in square brackets.

Rank CWE ID Name

[1] CWE-

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

[2] CWE-

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

[4] CWE-

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

[9] CWE-

434 Unrestricted Upload of File with Dangerous Type

[12] CWE-

352 Cross-Site Request Forgery (CSRF)

[22] CWE-

601 URL Redirection to Untrusted Site ('Open Redirect')

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.

Rank CWE ID Name

[3] CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') [13] CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [14] CWE-494 Download of Code Without Integrity Check [16] CWE-829 Inclusion of Functionality from Untrusted Control Sphere [18] CWE-676 Use of Potentially Dangerous Function [20] CWE-131 Incorrect Calculation of Buffer Size [23] CWE-134 Uncontrolled Format String [24] CWE-190 Integer Overflow or Wraparound

Porous Defenses

The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored.

Rank CWE ID Name

[5] CWE-306 Missing Authentication for Critical Function [6] CWE-862 Missing Authorization [7] CWE-798 Use of Hard-coded Credentials [8] CWE-311 Missing Encryption of Sensitive Data

[10] CWE-807 Reliance on Untrusted Inputs in a Security Decision [11] CWE-250 Execution with Unnecessary Privileges [15] CWE-863 Incorrect Authorization [17] CWE-732 Incorrect Permission Assignment for Critical Resource [19] CWE-327 Use of a Broken or Risky Cryptographic Algorithm [21] CWE-307 Improper Restriction of Excessive Authentication Attempts [25] CWE-759 Use of a One-Way Hash without a Salt

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.

Ranking The ranking of the weakness in the general list.

Score Summary

A summary of the individual ratings and scores that were given to this weakness, including Prevalence, Importance, and Adjusted Score.

CWE ID

and name CWE identifier and short name of the weakness

Supporting Information

Supplementary information about the weakness that may be useful for decision-makers to further prioritize the entries.

Discussion Short, informal discussion of the nature of the weakness and its consequences. The discussion avoids digging too deeply into technical detail.

Prevention and Mitigations

Steps that developers can take to mitigate or eliminate the weakness. 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.

Related CWEs

Other CWE entries that are related to the Top 25 weakness. Note: This list is illustrative, not comprehensive.

General Parent

One or more pointers to more general CWE entries, so you can see the breadth and depth of the problem.

Related Attack Patterns

CAPEC entries for attacks that may be successfully conducted against the weakness.

Note: the list is not necessarily complete.

Other pointers

Links to more details including source code examples that demonstrate the weakness, methods for detection, etc.

Supporting Information

Each Top 25 entry includes supporting data fields for weakness prevalence, technical impact, and other information. Each entry also includes the following data fields.

Field Description

Attack Frequency How often the weakness occurs in vulnerabilities that are exploited by an attacker.

Ease of Detection How easy it is for an attacker to find this weakness.

Remediation Cost The amount of effort required to fix the weakness.

Attacker Awareness

The likelihood that an attacker is going to be aware of this particular weakness, methods for detection, and methods for exploitation.

http://capec.mitre.org/

See Appendix A for more details.

Detailed CWE Descriptions

This section provides details for each individual CWE entry, along with links to additional information. See the Organization of the Top 25 section for an explanation of the various fields.

1 CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Summary Weakness Prevalence High Consequences Data loss, Security bypass

Remediation Cost Low Ease of Detection Easy

Attack Frequency Often Attacker Awareness High

Discussion

These days, it seems as if software is all about the data: getting it into the database, pulling it from the database, massaging it into information, and sending it elsewhere for fun and profit. If attackers can influence the SQL that you use to communicate with your database, then suddenly all your fun and profit belongs to them. If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security. They could modify the queries to steal, corrupt, or otherwise change your underlying data. They'll even steal data one byte at a time if they have to, and they have the patience and know-how to do so. In 2011, SQL injection was responsible for the compromises of many high-profile organizations, including Sony Pictures, PBS, MySQL.com, security company HBGary Federal, and many others.

Technical Details | Code Examples | Detection Methods | References

Prevention and Mitigations Architecture and Design Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.

Architecture and Design If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since you may re-introduce the possibility of SQL injection.

Architecture and Design, Operation Run your code using the lowest privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Specifically, follow the principle of least privilege when creating user accounts to a SQL database. The database users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data. Use the strictest permissions possible on all database objects, such as execute-only for stored procedures.

Architecture and Design For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602.

Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Implementation If you need to use dynamically-generated query strings or commands in spite of the risk, properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict whitelist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).

Instead of building your own implementation, such features may be available in the database or programming language. For example, the Oracle DBMS_ASSERT package can check or enforce that parameters have certain properties that make them less vulnerable to SQL injection. For MySQL, the mysql_real_escape_string() API function is available in both C and PHP.

http://cwe.mitre.org/data/definitions/89.html http://cwe.mitre.org/data/definitions/89.html http://cwe.mitre.org/data/definitions/89.html#Demonstrative%20Examples http://cwe.mitre.org/data/definitions/89.html#Detection%20Methods http://cwe.mitre.org/data/definitions/89.html#References

Implementation Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

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 you are expecting colors such as "red" or "blue."

When constructing SQL query strings, use stringent whitelists that limit the character set based on the expected value of the parameter in the request.

This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.

Note that proper output encoding, escaping, and quoting is the most effective solution for preventing SQL injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent SQL injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, the name "O'Reilly" would likely pass the validation step, since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise handled. In this case, stripping the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.

When feasible, it may be safest to disallow meta-characters entirely, instead of escaping them. This will provide some defense in depth. After the data is entered into the database, later processes may neglect to escape meta-characters before use, and you may not have control over those processes.

Architecture and Design When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

Implementation Ensure that error messages only contain minimal details that are useful to the intended audience, and nobody else. The messages need to strike the balance between being too cryptic and not being cryptic enough. They should not necessarily reveal the methods that were used to determine the error.

Such detailed information can be used to refine the original attack to increase the chances of success.

If errors must be tracked in some detail, capture them in log messages - but consider what could occur if the log messages can be viewed by attackers. Avoid recording highly sensitive information such as passwords in any form. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not.

In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.

Operation Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

Effectiveness: Moderate

Notes: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

Operation, Implementation If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Related CWEs CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

CWE-564 SQL Injection: Hibernate

CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key

CWE-619 Dangling Database Cursor ('Cursor Injection')

Related Attack Patterns

CAPEC-IDs: [view all] 7, 66, 108, 109, 110

2 CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

Summary Weakness Prevalence Medium Consequences Code execution

Remediation Cost Medium Ease of Detection Easy

Attack Frequency Often Attacker Awareness High

Discussion http://cwe.mitre.org/data/definitions/90.html http://cwe.mitre.org/data/definitions/564.html http://cwe.mitre.org/data/definitions/566.html http://cwe.mitre.org/data/definitions/619.html http://cwe.mitre.org/data/definitions/89.html#Related_Attack_Patterns http://capec.mitre.org/data/definitions/7.html http://capec.mitre.org/data/definitions/66.html http://capec.mitre.org/data/definitions/108.html http://capec.mitre.org/data/definitions/109.html http://capec.mitre.org/data/definitions/110.html http://cwe.mitre.org/data/definitions/78.html

Your software is often the bridge between an outsider on the network and the internals of your operating system. When you invoke another program on the operating system, but you allow untrusted inputs to be fed into the command string that you generate for executing that program, then you are inviting attackers to cross that bridge into a land of riches by executing their own commands instead of yours.

Technical Details | Code Examples | Detection Methods | References

Prevention and Mitigations Architecture and Design If at all possible, use library calls rather than external processes to recreate the desired functionality.

Architecture and Design, Operation Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by your software.

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 you to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

Notes: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Architecture and Design For any data that will be used to generate a command to be executed, keep as much of that data out of external control as possible. For example, in web applications, this may require storing the data locally in the session's state instead of sending it out to the client in a hidden form field.

Architecture and Design For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602.

Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Architecture and Design Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, consider using the ESAPI Encoding control or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.

Implementation If you need to use dynamically-generated query strings or commands in spite of the risk, properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict whitelist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).

Implementation If the program to be executed allows arguments to be specified within an input file or from standard input, then consider using that mode to pass arguments instead of the command line.

Architecture and Design If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Some languages offer multiple functions that can be used to invoke commands. Where possible, identify any function that invokes a command shell using a single string, and replace it with a function that requires individual arguments. These functions typically perform appropriate quoting and filtering of arguments. For example, in C, the system() function accepts a string that contains the entire command to be executed, whereas execl(), execve(), and others require an array of strings, one for each argument. In Windows, CreateProcess() only accepts one command at a time. In Perl, if system() is provided with an array of arguments, then it will quote each of the arguments.

Implementation Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

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 you are expecting colors such as "red" or "blue."

When constructing OS command strings, use stringent whitelists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.

Note that proper output encoding, escaping, and quoting is the most effective solution for preventing OS command injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent OS command injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, when invoking a mail program, you might need to allow the subject field to contain otherwise-dangerous inputs like ";" and ">" characters, which would need to be escaped or otherwise handled. In this case, stripping the character might reduce the risk of OS command injection, but it would produce incorrect behavior because the subject field would not be recorded as the user intended. This might seem to be a minor inconvenience, but it could be more important when the program relies on well-structured subject lines in order to pass messages to other components.

Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.

Architecture and Design http://cwe.mitre.org/data/definitions/78.html http://cwe.mitre.org/data/definitions/78.html#Demonstrative%20Examples http://cwe.mitre.org/data/definitions/78.html#Detection%20Methods http://cwe.mitre.org/data/definitions/78.html#References

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

Operation Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force you to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Implementation Ensure that error messages only contain minimal details that are useful to the intended audience, and nobody else. The messages need to strike the balance between being too cryptic and not being cryptic enough. They should not necessarily reveal the methods that were used to determine the error.

Such detailed information can be used to refine the original attack to increase the chances of success.

If errors must be tracked in some detail, capture them in log messages - but consider what could occur if the log messages can be viewed by attackers. Avoid recording highly sensitive information such as passwords in any form. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not.

In the context of OS Command Injection, error information passed back to the user might reveal whether an OS command is being executed and possibly which command is being used.

Operation Use runtime policy enforcement to create a whitelist of allowable commands, then prevent use of any command that does not appear in the whitelist.

Technologies such as AppArmor are available to do this.

Operation Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

Effectiveness: Moderate

Notes: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

Architecture and Design, Operation Run your code using the lowest privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Operation, Implementation If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Related CWEs CWE-88 Argument Injection or Modification

Related Attack Patterns

CAPEC-IDs: [view all] 6, 15, 43, 88, 108

3 CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

Summary Weakness Prevalence High Consequences Code execution, Denial of service, Data loss

Remediation Cost Low Ease of Detection Easy

Attack Frequency Often Attacker Awareness High

Discussion

Buffer overflows are Mother Nature's little reminder of that law of physics that says: if you try to put more stuff into a container than it can hold, you're going to make a mess. The scourge of C applications for decades, buffer overflows have been remarkably resistant to elimination. However, copying an untrusted input without checking the size of that input is the simplest error to make in a time when there are much more interesting mistakes to avoid. That's why this type of buffer overflow is often referred to as "classic." It's decades old, and it's typically one of the first things you learn about in Secure Programming 101.

Technical Details | Code Examples | Detection Methods | References http://cwe.mitre.org/data/definitions/88.html http://cwe.mitre.org/data/definitions/78.html#Related_Attack_Patterns http://capec.mitre.org/data/definitions/6.html http://capec.mitre.org/data/definitions/15.html http://capec.mitre.org/data/definitions/43.html http://capec.mitre.org/data/definitions/88.html http://capec.mitre.org/data/definitions/108.html http://cwe.mitre.org/data/definitions/120.html http://cwe.mitre.org/data/definitions/120.html http://cwe.mitre.org/data/definitions/120.html#Demonstrative%20Examples http://cwe.mitre.org/data/definitions/120.html#Detection%20Methods http://cwe.mitre.org/data/definitions/120.html#References

Prevention and Mitigations Requirements Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

Architecture and Design Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Examples include the Safe C String Library (SafeStr) by Messier and Viega, and the Strsafe.h library from Microsoft. These libraries provide safer versions of overflow-prone string-handling functions.

Notes: This is not a complete solution, since many buffer overflows are not related to strings.

Build and Compilation Run or compile your software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.

Effectiveness: Defense in Depth

Notes: This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Implementation Consider adhering to the following rules when allocating and managing an application's memory:

Double check that your buffer is as large as you specify.

When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.

Check buffer boundaries if accessing the buffer in a loop and make sure you are not in danger of writing past the allocated space.

If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

Implementation Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

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 you are expecting colors such as "red" or "blue."

Architecture and Design For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602.

Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Operation Use a feature like Address Space Layout Randomization (ASLR).

Effectiveness: Defense in Depth

Notes: This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Operation Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent.

Effectiveness: Defense in Depth

Notes: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

Build and Compilation, Operation Most mitigating technologies at the compiler or OS level to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is good practice to implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution.

Implementation Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

Effectiveness: Moderate

Notes: This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131).

Architecture and Design When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

Architecture and Design, Operation Run your code using the lowest privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Architecture and Design, Operation

Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by your software.

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 you to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

Notes: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Related CWEs CWE-129 Improper Validation of Array Index

CWE-131 Incorrect Calculation of Buffer Size

Related Attack Patterns

CAPEC-IDs: [view all] 8, 9, 10, 14, 24, 42, 44, 45, 46, 47, 67, 92, 100

4 CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Summary Weakness Prevalence High Consequences Code execution, Security bypass

Remediation Cost Low Ease of Detection Easy

Attack Frequency Often Attacker Awareness High

Discussion

Cross-site scripting (XSS) is one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications. It's pretty much inevitable when you combine the stateless nature of HTTP, the mixture of data and script in HTML, lots of data passing between web sites, diverse encoding schemes, and feature-rich web browsers. If you're not careful, attackers can inject Javascript or other browser-executable content into a web page that your application generates. Your web page is then accessed by other users, whose browsers execute that malicious script as if it came from you (because, after all, it *did* come from you). Suddenly, your web site is serving code that you didn't write. The attacker can use a variety of techniques to get the input directly into your server, or use an unwitting victim as the middle man in a technical version of the "why do you keep hitting yourself?" game.

Technical Details | Code Examples | Detection Methods | References

Prevention and Mitigations Architecture and Design Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Implementation, Architecture and Design Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.

For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.

Parts of the same output document may require different encodings, which will vary depending on whether the output is in the:

HTML body

Element attributes (such as src="XYZ")

URIs

JavaScript sections http://cwe.mitre.org/data/definitions/129.html http://cwe.mitre.org/data/definitions/131.html http://cwe.mitre.org/data/definitions/120.html#Related_Attack_Patterns http://capec.mitre.org/data/definitions/8.html http://capec.mitre.org/data/definitions/9.html http://capec.mitre.org/data/definitions/10.html http://capec.mitre.org/data/definitions/14.html http://capec.mitre.org/data/definitions/24.html http://capec.mitre.org/data/definitions/42.html http://capec.mitre.org/data/definitions/44.html http://capec.mitre.org/data/definitions/45.html http://capec.mitre.org/data/definitions/46.html http://capec.mitre.org/data/definitions/47.html…