Transcript www.cs.uah.edu

2009 CWE/SANS Top 25 Most Dangerous
Programming Errors
Siroj Kansakar
o4/02/2008
Outline
• Introduction
• Brief Listing of The Top 25
• Organization of The Top 25
• Insecure Interaction Between Components
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
Introduction (contd…)
• Goals
– Stop vulnerabilities at the source by educating programmers on
how to eliminate all-too-common mistakes before software is
shipped.
– Tool for education and awareness to prevent different kinds of
vulnerabilities
– Software consumers could use the list to help them to ask for
more secure software.
– Software managers and CIOs can the list as a measuring stick of
progress in their efforts to secure their software.
Brief Listing of The Top 25
• Organized into three high-level categories that contains
multiple CWE entries
1. 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-20:
– CWE-116:
– CWE-89:
– CWE-79:
– CWE-78:
–
–
–
–
CWE-319:
CWE-352:
CWE-362:
CWE-209:
Improper Input Validation
Improper Encoding or Escaping of Output
Failure to Preserve SQL Query Structure
(aka 'SQL Injection')
Failure to Preserve Web Page Structure
(aka 'Cross-site Scripting')
Failure to Preserve OS Command Structure
(aka 'OS Command Injection')
Cleartext Transmission of Sensitive Information
Cross-Site Request Forgery (CSRF)
Race Condition
Error Message Information Leak
Brief Listing of The Top 25 (contd…)
2. 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-119:
–
–
–
–
CWE-642:
CWE-73:
CWE-426:
CWE-94:
–
–
–
–
CWE-494:
CWE-404:
CWE-665:
CWE-682:
Failure to Constrain Operations within the
Bounds of a Memory Buffer
External Control of Critical State Data
External Control of File Name or Path
Untrusted Search Path
Failure to Control Generation of Code
(aka 'Code Injection')
Download of Code Without Integrity Check
Improper Resource Shutdown or Release
Improper Initialization
Incorrect Calculation
Brief Listing of The Top 25 (contd…)
3. Porous Defenses
• The weaknesses in this category are related to defensive techniques
that are often misused, abused, or just plain ignored.
– CWE-285:
– CWE-327:
– CWE-259:
– CWE-732:
– CWE-330:
– CWE-250:
– CWE-602:
Improper Access Control (Authorization)
Use of a Broken or Risky Cryptographic
Algorithm
Hard-Coded Password
Insecure Permission Assignment for Critical
Resource
Use of Insufficiently Random Values
Execution with Unnecessary Privileges
Client-Side Enforcement of Server-Side
Security
Organization of The Top 25
•
CWE ID and name
•
Supporting data fields
•
Discussion
•
Prevention and mitigations
•
Related CWEs
•
Related attack patterns
Insecure Interaction Between Components
• CWE-20: Improper Input Validation
– Discussion
• #1 killer of healthy software
• Can lead to vulnerabilities when attackers can modify their inputs in unexpected
ways
– Example
Insecure Interaction Between Components
• CWE-20: Improper Input Validation
– Prevention and Mitigations
• 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. Perform input validation at well-defined interfaces
• 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 combine
• Testing
– Use automated static analysis tools that target this type of weakness. Many
modern techniques use data flow analysis to minimize the number of false
positives. This is not a perfect solution, since 100% accuracy and coverage are
not feasible
Insecure Interaction Between Components
• CWE-116: Improper Encoding or Escaping of Output
– Discussion
• Can allow attackers to change the commands that are sent to another component,
inserting malicious commands instead.
– Example
Insecure Interaction Between Components
• CWE-116: Improper Encoding or Escaping of Output
– Prevention and Mitigations
• Architecture and Design
– Use languages, libraries, or frameworks that make it easier to generate
properly encoded output. Examples include the ESAPI Encoding control.
Alternately, use built-in functions, but consider using wrappers in case those
functions are discovered to have a vulnerability.
• Implementation
– When exchanging data between components, ensure that both components
are using the same character encoding. Ensure that the proper encoding is
applied at each interface. Explicitly set the encoding you are using whenever
the protocol allows you to do so.
• Testing
– Use automated static analysis tools that target this type of weakness. Many
modern techniques use data flow analysis to minimize the number of false
positives. This is not a perfect solution, since 100% accuracy and coverage are
not feasible
Insecure Interaction Between Components
• CWE-89: Failure to Preserve SQL Query Structure (aka ‘SQL
Injection’)
– Discussion
• 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 they can do nasty things where they get all the fun and profit. 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.
Insecure Interaction Between Components
• CWE-89: Failure to Preserve SQL Query Structure (aka ‘SQL
Injection’)
– Example
Insecure Interaction Between Components
• CWE-89: Failure to Preserve SQL Query Structure (aka ‘SQL Injection’)
– Prevention and Mitigations
• Architecture and Design
– 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.
– Follow the principle of least privilege when creating user accounts to a SQL
database
• Implementation
– Assume all input is malicious. Use an "accept known good" input validation strategy
(i.e., use a whitelist). Reject any input that does not strictly conform to
specifications, or transform it into something that does. Use a blacklist to reject any
unexpected inputs and detect potential attacks.
• Testing
– Use automated static analysis tools that target this type of weakness. Many
modern techniques use data flow analysis to minimize the number of false
positives. This is not a perfect solution, since 100% accuracy and coverage are not
feasible.
Insecure Interaction Between Components
• CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site
Scripting')
– Discussion
• One of the most prevalent, obstinate, and dangerous vulnerabilities in web
applications.
• 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.
Insecure Interaction Between Components
• CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site
Scripting')
– Prevention and Mitigations
• Architecture and Design
– Use languages, libraries, or frameworks that make it easier to generate
properly encoded output.
• Implementation
– To help mitigate XSS attacks against the user's session cookie, set the session
cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as
more recent versions of Internet Explorer and Firefox), this attribute can
prevent the user's session cookie from being accessible to malicious client-side
scripts that use document.cookie. This is not a complete solution, since
HttpOnly is not supported by all browsers. More importantly,
XMLHTTPRequest and other powerful browser technologies provide read
access to HTTP headers, including the Set-Cookie header in which the HttpOnly
flag is set.
• Testing
– Use automated static analysis tools that target this type of weakness. Many
modern techniques use data flow analysis to minimize the number of false
positives. This is not a perfect solution, since 100% accuracy and coverage are
not feasible.
Insecure Interaction Between Components
• CWE-78: Failure to Preserve OS Command Structure (aka 'OS
Command Injection')
– Discussion
• The software uses externally-supplied input to dynamically construct all or part of a
command, which is then passed to the operating system for execution, but the
software does not sufficiently enforce which commands and arguments are
specified.
• 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.
• Alternately, 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.
Insecure Interaction Between Components
• CWE-78: Failure to Preserve OS Command Structure (aka 'OS
Command Injection')
– Example
Insecure Interaction Between Components
• CWE-78: Failure to Preserve OS Command Structure (aka 'OS
Command Injection')
– Prevention and Mitigations
• Architecture and Design
– If at all possible, use library calls rather than external processes to recreate the
desired functionality.
• 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.
• Testing
– Use automated static analysis tools that target this type of weakness. Many
modern techniques use data flow analysis to minimize the number of false
positives. This is not a perfect solution, since 100% accuracy and coverage are
not feasible
Insecure Interaction Between Components
• CWE-319: Cleartext Transmission of Sensitive Information
– Discussion
• The software transmits sensitive or security-critical data in cleartext in a
communication channel that can be sniffed by unauthorized actors.
• Many communication channels can be "sniffed" by attackers during data
transmission. For example, network traffic can often be sniffed by any attacker who
has access to a network interface. This significantly lowers the difficulty of
exploitation by attackers.
Insecure Interaction Between Components
• CWE-319: Cleartext Transmission of Sensitive Information
– Prevention and Mitigations
• Architecture and Design
– Encrypt the data with a reliable encryption scheme before transmitting
• Implementation
– When using web applications with SSL, use SSL for the entire session from
login to logout, not just for the initial login page.
• Testing
– Use tools and techniques that require manual (human) analysis, such as
penetration testing, threat modeling, and interactive tools that allow the
tester to record and modify an active session.
Insecure Interaction Between Components
• CWE-352: Cross-Site Request Forgery (CSRF)
– Discussion
• The web application does not, or can not, sufficiently verify whether a well-formed,
valid, consistent request was intentionally provided by the user who submitted the
request.
• When a web server is designed to receive a request from a client without any
mechanism for verifying that it was intentionally sent, then it might be 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 data disclosure or unintended code
execution.
Insecure Interaction Between Components
• CWE-352: Cross-Site Request Forgery (CSRF)
– Prevention and Mitigations
• Architecture and Design
– Use anti-CSRF packages such as the OWASP CSRFGuard.
– Identify especially dangerous operations. When the user performs a dangerous
operation, send a separate confirmation request to ensure that the user
intended to perform that operation.
• Implementation
– Ensure that your application is free of cross-site scripting issues (CWE-79),
because most CSRF defenses can be bypassed using attacker-controlled script.
• Testing
– Use tools and techniques that require manual (human) analysis, such as
penetration testing, threat modeling, and interactive tools that allow the
tester to record and modify an active session.
– Use OWASP CSRFTester to identify potential issues.
Insecure Interaction Between Components
• CWE-362: Race Condition
– Discussion
• The code requires that certain state should not be modified between two
operations, but a timing window exists in which the state can be modified by an
unexpected actor or process.
• This can have security implications when the expected synchronization is in
security-critical code, such as recording whether a user is authenticated, or
modifying important state information that should not be influenced by an
outsider.
Insecure Interaction Between Components
• CWE-362: Race Condition
– Prevention and Mitigations
• Architecture and Design
– Minimize the usage of shared resources in order to remove as much
complexity as possible from the control flow and to reduce the likelihood of
unexpected conditions occurring.
– Additionally, this will minimize the amount of synchronization necessary and
may even help to reduce the likelihood of a denial of service where an attacker
may be able to repeatedly trigger a critical section
• Implementation
– When using multi-threading, only use thread-safe functions on shared
variables.
• Testing
– Stress-test the software by calling it simultaneously from a large number of
threads or processes, and look for evidence of any unexpected behavior. The
software's operation may slow down, but it should not become unstable,
crash, or generate incorrect results.
– Insert breakpoints or delays in between relevant code statements to artificially
expand the race window so that it will be easier to detect.
Insecure Interaction Between Components
• CWE-209: Error Message Information Leak
– Discussion
• The software generates an error message that includes sensitive information about
its environment, users, or associated data.
• The sensitive information may be valuable information on its own (such as a
password), or it may be useful for launching other, more deadly attacks. If an attack
fails, an attacker may use error information provided by the server to launch
another more focused attack.
Insecure Interaction Between Components
• CWE-209: Error Message Information Leak
– Example
Insecure Interaction Between Components
• CWE-209: Error Message Information Leak
– Prevention and Mitigations
• Implementation
– Handle exceptions internally and do not display errors containing potentially
sensitive information to a user.
• Testing
– Identify error conditions that are not likely to occur during normal usage and
trigger them. For example, run the program under low memory conditions, run
with insufficient privileges or permissions, interrupt a transaction before it is
completed, or disable connectivity to basic network services such as DNS.
Monitor the software for any unexpected behavior. If you trigger an
unhandled exception or similar error that was discovered and handled by the
application's environment, it may still indicate unexpected conditions that
were not handled by the application itself.
Thank You