Top 25 Programming Mistakes
OWASP
Venki
Chennai Chapter Leader
Cognizant Technology Solutions
[email protected]
+91-9840148148
21-March-2009
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org
Top 25 Programming Mistakes
Discusses the most 25 popular errors
Is divided into 3 categories
Insecure Interaction Between Components
Risky Resource Management
Porous Defenses
We will also look at prevention & remediation
OWASP
2
Insecure Interactions Between Components
– Improper Input Validation
 What this means
 No validation or incorrect validation of inputs that affect the
control flow or the data flow
 The attacker crafts the input such a way that it might break the
normal flow of the application
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Availability: Program crash
 Confidentiality: Access unauthorized data
 Integrity: Modify data or alter the normal execution of the
program
 Exploit Likelihood: High
OWASP
3
Insecure Interactions Between Components
– Improper Input Validation
 Potential Mitigation
 Architecture & Design
 Use standard frameworks for validation
 Understand all entry points for unsafe inputs: parameters, arguments,
cookies, read fro devices/networks etc
 Assume all inputs are malicious
 Ensure validations are done at both server side & client side
 Do not depend on blacklisting to detect malicious inputs
 Implementation
 When data is combined, perform checks on the combined data
 Validate inputs when invoked from cross-language implementation
boundaries
 Do correct type-conversion to the expected type directly
 Decode input data to the applications internal representation before
validating
 Ensure all interacting components use the same character encoding
OWASP
4
Insecure Interactions Between Components
- Improper Encoding or Escaping
 What this means
 When a structured message is prepared, data is either not
encoded/escaped or is incorrectly encoded/escaped
 Intended structure of the message is lost
 When it Occurs
 Architecture & Design
 Implementation
 Operation
 Consequences
 Authorization: Internal communication flow can be modified between
components. Unexpected commands can be executed bypassing
security mechanisms. Incoming data can be misinterpreted
 Exploit Likelihood: Very High
OWASP
5
Insecure Interactions Between Components
– Improper Encoding or Escaping
 Potential Mitigation
 Requirements
 Fully specify which encodings are required by components that will be
communicating with each other
 Architecture & Design
 Use languages, libraries, or frameworks that make it easier to generate
properly encoded output
 Alternately, use built-in functions, but consider using wrappers in case those
functions are discovered to have a vulnerability
 Use white listed tags if you really have to have tags like in wiki pages etc.
 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
OWASP
6
Insecure Interactions Between Components
– SQL Injection
 What this means
 The application dynamically generates an SQL query based on user input, but it does not
sufficiently prevent that input from modifying the intended structure of the query
 When it Occurs
 Architecture & Design
 Implementation
 Operation
 Consequences
 Confidentiality: Since SQL databases generally hold sensitive data, loss of confidentiality is a
frequent problem with SQL injection vulnerabilities
 Authentication: If poor SQL commands are used to check user names and passwords, it may
be possible to connect to a system as another user with no previous knowledge of the
password.
 Authorization: If authorization information is held in a SQL database, it may be possible to
change this information through the successful exploitation of a SQL injection vulnerability
 Integrity: Just as it may be possible to read sensitive information, it is also possible to make
changes or even delete this information with a SQL injection attack
 Exploit Likelihood: Very High
OWASP
7
Insecure Interactions Between Components
– SQL Injection
 Potential Mitigation
 Requirements
 Use languages, libraries, or frameworks that make it easier to generate
properly encoded output
 Architecture & Design
 Process SQL queries using prepared statements, parameterized queries and
stored procedures
 Follow the principle of least privilege when creating user accounts to a SQL
database
 For any security checks that are performed on the client side, ensure that
these checks are duplicated on the server side
 Implementation
 If you need to use dynamically-generated query strings in spite of the risk,
use proper encoding and escaping of inputs
 Assume all input is malicious
OWASP
8
Insecure Interactions Between Components
– Cross Site Scripting
 What this means
 The software does not sufficiently validate, filter, escape, and encode
user-controllable input before it is placed in output that is used as a
web page that is served to other users
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Confidentiality: The most common attack performed with cross-site
scripting involves the disclosure of information stored in user cookies
 Access Control: In some circumstances it may be possible to run
arbitrary code on a victim's computer when cross-site scripting is
combined with other flaws
 Exploit Likelihood: High to Very High
OWASP
9
Insecure Interactions Between Components
– Cross Site Scripting
 Potential Mitigation
 Requirements
 Use languages, libraries, or frameworks that make it easier to generate
properly encoded output
 Architecture & Design
 For any security checks that are performed on the client side, ensure that
these checks are duplicated on the server side
 Implementation
 Use and specify a strong character encoding such as ISO-8859-1 or UTF-8.
When an encoding is not specified, the web browser may choose a different
encoding by guessing which encoding is actually being used by the web
page. This can open you up to subtle XSS attacks related to that encoding
 Assume all input is malicious
OWASP
10
Insecure Interactions Between Components
– OS Command Injection
 What this means
 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
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Non-Repudiation: Attackers could execute unauthorized commands,
which could then be used to disable the software, or read and modify
data for which the attacker does not have permissions to access directly
 Exploit Likelihood: High
OWASP
11
Insecure Interactions Between Components
– OS Command Injection
 Potential Mitigation
 Requirements
 Use languages, libraries, or frameworks that make it easier to generate
properly encoded output
 Architecture & Design
 If at all possible, use library calls rather than external processes to recreate
the desired function
 Run your code in a "jail" or similar sandbox environment that enforces strict
boundaries between the process and the operating system
 Use languages, libraries, or frameworks that make it easier to generate
properly encoded output
 Implementation
 Properly quote arguments and escape any special characters within those
arguments
 Assume all input is malicious
OWASP
12
Insecure Interactions Between Components
– Cleartext transmission of Sensitive Info
 What this means
 The software transmits sensitive or security-critical data in
cleartext in a communication channel that can be sniffed by
unauthorized actors
 When it Occurs
 Architecture & Design
 Consequences
 Confidentiality: Anyone can read the contents of the message if
they have access to any channel being used for communication
 Exploit Likelihood: Medium to High
OWASP
13
Insecure Interactions Between Components
– Cleartext transmission of Sensitive Info
 Potential Mitigation
 Architecture & 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
OWASP
14
Insecure Interactions Between Components
– Cross-Site Scripting Forgery (CSRF)
 What this means
 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 it Occurs
 Architecture & Design
 Implementation
 Consequences
 Exploit Likelihood: High
OWASP
15
Insecure Interactions Between Components
– Cross-Site Scripting Forgery
 Potential Mitigation
 Architecture & 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
 Do not use the GET method for any request that triggers a state change
 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
OWASP
16
Insecure Interactions Between Components
– Race Condition
 What this means
 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
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Availability: When a race condition makes it possible to bypass a resource
cleanup routine or trigger multiple initialization routines, it may lead to resource
exhaustion
 Availability: When a race condition allows multiple control flows to access a
resource simultaneously, it might lead the program(s) into unexpected states,
possibly resulting in a crash
 Integrity: When a race condition is combined with predictable resource names
and loose permissions, it may be possible for an attacker to overwrite or access
confidential data
 Exploit Likelihood: Medium
OWASP
17
Insecure Interactions Between Components
– Race Condition
 Potential Mitigation
 Architecture & Design
 In languages that support it, use synchronization primitives. Only wrap these
around critical code to minimize the impact on performance
 Use thread-safe capabilities such as the data access abstraction in Spring
 Implementation
 When using multi-threading, only use thread-safe functions on shared
variables
 Disable interrupts or signals over critical parts of the code, but also make
sure that the code does not go into a large or infinite loop
OWASP
18
Insecure Interactions Between Components
– Error Message Information Leak
 What this means
 The software generates an error message that includes sensitive
information about its environment, users, or associated data
 When it Occurs
 Architecture & Design
 Implementation
 System Configuration
 Consequences
 Confidentiality: Often this will either reveal sensitive information
which may be used for a later attack or private information
stored in the server
 Exploit Likelihood: High
OWASP
19
Insecure Interactions Between Components
– Error Message Information Leak
 Potential Mitigation
 Implementation
 Ensure that error messages only contain minimal information that are useful
to their intended audience, and nobody else
 Handle exceptions internally and do not display errors containing potentially
sensitive information to a user
OWASP
20
Risky Resource Management – Failure to Constrain
Operations within the Bounds of a Memory Buffer
 What this means
 The software may potentially allow operations, such as reading
or writing, to be performed at addresses not intended by the
developer
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Integrity: If the memory accessible by the attacker can be
effectively controlled, it may be possible to execute arbitrary
code
 Availability: Out of bounds memory access will very likely result
in the corruption of relevant memory, and perhaps instructions,
possibly leading to a crash
OWASP
 Exploit Likelihood: High
21
Risky Resource Management – Failure to Constrain
Operations within the Bounds of a Memory Buffer
 Potential Mitigation
 Requirements
 Use a language with features that can automatically mitigate or eliminate
buffer overflows
 Architecture & Design
 Use languages, libraries, or frameworks that make it easier to manage
buffers without exceeding their boundaries
 Implementation
 Programmers should adhere to the following rules when allocating and
managing their 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 calling this function 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
OWASP
22
Risky Resource Management – External
Control of Critical State Data
 What this means
 The software stores security-critical state information about its users, or
the software itself, in a location that is accessible to unauthorized actors
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Integrity: An attacker could potentially modify the state in malicious
ways. If the state is related to the privileges or level of authentication
that the user has, then state modification might allow the user to
bypass authentication or elevate privileges
 Confidentiality: The state variables may contain sensitive information
that should not be known by the client
 Availability: By modifying state variables, the attacker could violate the
application's expectations for the contents of the state, leading to a
denial of service due to an unexpected error condition
OWASP
 Exploit Likelihood: High
23
Risky Resource Management – External Control of
Critical State Data
 Potential Mitigation
 Architecture & Design
 Understand all the potential locations that are accessible to attackers
 Do not keep state information on the client without using encryption and
integrity checking, or otherwise having a mechanism on the server side to
catch state tampering
 Store state information on the server side only
 With a stateless protocol such as HTTP, use a framework that maintains the
state for you
 For any security checks that are performed on the client side, ensure that
these checks are duplicated on the server side
OWASP
24
Risky Resource Management – External
Control of File Name or Path
 What this means
 The software allows user input to control or influence paths that are used in file
system operations
 When it Occurs
 Architecture & Design
 Implementation
 Operation
 Consequences
 Availability: The application can operate on unexpected files. Confidentiality is
violated when the targeted filename is not directly readable by the attacker
 Availability: Availability can be violated if the attacker specifies an unexpected file
that the application modifies
 Availability: Availability can also be affected if the attacker specifies a filename
for a large file, or points to a special device or a file that does not have the
format that the application expects
 Integrity: Integrity is violated if the filename is written to, or if the filename is for
a program or other form of executable code
 Exploit Likelihood: High to Very High
OWASP
25
Risky Resource Management – External
Control of File Name or Path
 Potential Mitigation
 Architecture & Design
 When the set of filenames is limited or known, create a mapping from a set
of fixed input values (such as numeric IDs) to the actual filenames, and
reject all other inputs
 Run your code in a "jail" or similar sandbox environment that enforces strict
boundaries between the process and the operating system
 For any security checks that are performed on the client side, ensure that
these checks are duplicated on the server side
 Implementation
 Assume all input is malicious
 Use a built-in path canonicalization function (such as realpath() in C) that
produces the canonical version of the pathname, which effectively removes
".." sequences and symbolic links
 Operation
 Use OS-level permissions and run as a low-privileged user to limit the scope
of any successful attack
OWASP
26
Risky Resource Management – Untrusted
Search Path
 What this means
 The application searches for critical resources using an externally-supplied search
path that can point to resources that are not under the application's direct
control
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Availability: The program could be redirected to the wrong files, potentially
triggering a crash or hang when the targeted file is too large or does not have
the expected format
 Integrity: There is the potential for arbitrary code execution with privileges of the
vulnerable program
 Confidentiality: The program could send the output of unauthorized files to the
attacker
 Exploit Likelihood: High
OWASP
27
Risky Resource Management – Untrusted
Search Path
 Potential Mitigation
 Architecture & Design
 Hard-code your search path to a set of known-safe values, or allow them to
be specified by the administrator in a configuration file
 Implementation
 When invoking other programs, specify those programs using fully-qualified
pathnames
 Sanitize your environment before invoking other programs. This includes the
PATH environment variable, LD_LIBRARY_PATH and other settings that
identify the location of code libraries, and any application-specific search
paths
 Check your search path before use and remove any elements that are likely
to be unsafe, such as the current working directory or a temporary files
directory
 Use other functions that require explicit paths. Making use of any of the
other readily available functions that require explicit paths is a safe way to
avoid this problem
OWASP
28
Risky Resource Management – Code
Injection
 What this means
 The product does not sufficiently filter code (control-plane) syntax from usercontrolled input (data plane) when that input is used within code that the
product generates
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Authentication: In some cases, injectable code controls authentication; this may
lead to a remote vulnerability
 Access Control: Injected code can access resources that the attacker is directly
prevented from accessing
 Confidentiality: The injected code could access restricted data / files
 Accountability: Often the actions performed by injected control code are
unlogged
 Exploit Likelihood: Medium
OWASP
29
Risky Resource Management – Code
Injection
 Potential Mitigation
 Architecture & Design
 Refactor your program so that you do not have to dynamically generate
code
 Run your code in a "jail" or similar sandbox environment that enforces strict
boundaries between the process and the operating system
 Implementation
 Assume all input is malicious
OWASP
30
Risky Resource Management – Download of
Code Without Integrity Check
 What this means
 The product downloads source code or an executable from a remote location and
executes the code without sufficiently verifying the origin and integrity of the
code
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Availability: Executing untrusted code could result in a compromise of the
application and failure to function correctly for users
 Confidentiality: If an attacker can influence the untrusted code then, upon
execution, it may provide the attacker with access to sensitive files
 Integrity: Executing untrusted code could compromise the control flow of the
program, possibly also leading to the modification of sensitive resources
 Exploit Likelihood: Medium
OWASP
31
Risky Resource Management – Download of
Code Without Integrity Check
 Potential Mitigation
 Architecture & Design
 Use integrity checking on the transmitted code
– If you are providing the code that is to be downloaded, such as for automatic
updates of your software, then use cryptographic signatures for your code and
modify your download clients to verify the signatures
– Use code signing technologies such as Authenticode
OWASP
32
Risky Resource Management – Improper
Resource Shutdown or Release
 What this means
 When a resource is created or allocated, the developer is responsible for properly
releasing the resource as well as accounting for all potential paths of expiration
or invalidation, such as a set period of time or revocation.
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Availability: Most unreleased resource issues result in general software reliability
problems, but if an attacker can intentionally trigger a resource leak, the attacker
might be able to launch a denial of service attack by depleting the resource pool
 Confidentiality: When a resource containing sensitive information is not correctly
shutdown, it may expose the sensitive data in a subsequent allocation
 Exploit Likelihood: Medium
OWASP
33
Risky Resource Management – Improper
Resource Shutdown or Release
 Potential Mitigation
 Requirements
 Use a language with features that can automatically mitigate or eliminate
resource-shutdown weaknesses.
 Implementation
 It is good practice to be responsible for freeing all resources you allocate
and to be consistent with how and where you free memory in a function.
 Memory should be allocated/freed using matching functions such as
malloc/free, new/delete, and new[]/delete[].
 When releasing a complex object or structure, ensure that you properly
dispose of all of its member components, not just the object itself.
OWASP
34
Risky Resource Management – Improper
Initialization
 What this means
 The software does not follow the proper procedures for initializing a resource,
which might leave the resource in an improper state when it is accessed or used
 When it Occurs
 Implementation
 Operation
 Consequences
 Availability: The resource may have values that the program did not expect,
causing erroneous code paths to be exercised and leading to a crash or exit
 Confidentiality: When reusing a resource such as memory or a program variable,
the original contents of that resource may not be cleared before it is sent to an
un-trusted party
 Integrity: The uninitialized data may contain values that cause program flow to
change in ways that the programmer did not intend. For example, if an
uninitialized variable is used as an array index in C, then its previous contents
may produce an index that is outside the range of the array
 Exploit Likelihood: Medium
OWASP
35
Risky Resource Management – Improper
Initialization
 Potential Mitigation
 Architecture and Design
 Identify all variables and data stores that receive information from external
sources, and apply input validation to make sure that they are only initialized
to expected values.
 Implementation
 Explicitly initialize all your variables and other data stores, either during
declaration or just before the first usage.
 Pay close attention to complex conditionals that affect initialization, since
some conditions might not perform the initialization.
 Build and Compilation
 Run or compile your software with settings that generate warnings about
uninitialized variables or data.
OWASP
36
Risky Resource Management – Improper
Initialization
 Testing
 Use dynamic tools and techniques that interact with the software using large
test suites with many diverse inputs, such as fuzz testing (fuzzing),
robustness testing, and fault injection. The software's operation may slow
down, but it should not become unstable, crash, or generate incorrect
results.
 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.
OWASP
37
Risky Resource Management – Incorrect
Calculation
 What this means
 When software performs a security-critical calculation incorrectly, it might lead to
incorrect resource allocations, incorrect privilege assignments, or failed
comparisons among other things. Many of the direct results of an incorrect
calculation can lead to even larger problems such as failed protection
mechanisms or even arbitrary code execution
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Availability: If the incorrect calculation causes the program to move into an
unexpected state, it may lead to a crash or impairment of service
 Access Control: In the context of privilege or permissions assignment, an
incorrect calculation can provide an attacker with access to sensitive resources
 Exploit Likelihood: High
OWASP
38
Risky Resource Management – Incorrect
Calculation
 Potential Mitigation
 Implementation
 Perform input validation on any numeric inputs by ensuring that they are
within the expected range
 Use the appropriate type for the desired action. For example, in C/C++, only
use unsigned types for values that could never be negative, such as height,
width, or other numbers related to quantity
 Use languages, libraries, or frameworks that make it easier to handle
numbers without unexpected consequences
OWASP
39
Porous Defenses – Improper Access Control
(Authorization)
 What this means
 When access control checks are not applied consistently - or not at all - users are
able to access data or perform actions that they should not be allowed to
perform. This can lead to a wide range of problems, including information leaks,
denial of service, and arbitrary code execution
 When it Occurs
 Architecture & Design
 Implementation
 Operation
 Consequences
 Integrity: Allowing access to unauthorized users can result in an attacker gaining
access to the sensitive resources being protected, possibly modifying or
removing them, or performing unauthorized actions
 Exploit Likelihood: High
OWASP
40
Porous Defenses – Improper Access Control
(Authorization)
 Potential Mitigation
 Architecture and Design
 Divide your application into anonymous, normal, privileged, and
administrative areas. Use role-based access control (RBAC) to enforce the
roles at the appropriate boundaries
 Ensure that you perform access control checks related to your business
logic. Use authorization frameworks such as the JAAS Authorization
Framework and the OWASP ESAPI Access Control feature
 For web applications, make sure that the access control mechanism is
enforced correctly at the server side on every page. Users should not be
able to access any unauthorized functionality or information by simply
requesting direct access to that page
OWASP
41
Porous Defenses – Use of a Broken or Risky
Cryptographic Algorithm
 What this means
 The use of a non-standard algorithm is dangerous because a determined
attacker may be able to break the algorithm and compromise whatever data has
been protected. Well-known techniques may exist to break the algorithm
 When it Occurs
 Architecture & Design
 Consequences
 Confidentiality
 The confidentiality of sensitive data may be compromised by the use of a
broken or risky cryptographic algorithm
 Integrity
 The integrity of sensitive data may be compromised by the use of a broken
or risky cryptographic algorithm
 Accountability
 Any accountability to message content preserved by cryptography may be
subject to attack
 Exploit Likelihood: Medium to High
OWASP
42
Porous Defenses – Use of a Broken or Risky
Cryptographic Algorithm
 Potential Mitigation
 Architecture and Design
 Do not develop your own cryptographic algorithms. They will likely be
exposed to attacks that are well-understood by cryptographers. Reverse
engineering techniques are mature
 Use a well-vetted algorithm that is currently considered to be strong by
experts in the field, and select well-tested implementations
 Design your software so that you can replace one cryptographic algorithm
with another. This will make it easier to upgrade to stronger algorithms.
 Carefully manage and protect cryptographic keys (see CWE-320). If the keys
can be guessed or stolen, then the strength of the cryptography itself is
irrelevant
Implementation
 Use languages, libraries, or frameworks that make it easier to use strong
cryptography
 Industry-standard implementations will save you development time and may
be more likely to avoid errors that can occur during implementation of
cryptographic algorithms
OWASP
43
Porous Defenses – Use of a Broken or Risky
Cryptographic Algorithm
 When you use industry-approved techniques, you need to use them
correctly. Don't cut corners by skipping resource-intensive steps (CWE-325).
These steps are often essential for preventing common attacks
OWASP
44
Porous Defenses – Hard-Coded Password
 What this means
 A hard-coded password typically leads to a significant authentication failure that
can be difficult for the system administrator to detect. Once detected, it can be
difficult to fix, so the administrator maybe forced into disabling the product
entirely. There are two main variations:
Inbound: the software contains an authentication mechanism that checks for a
hard-coded password.
Outbound: the software connects to another system or component, and it
contains hard-coded password for connecting to that component.
 When it Occurs
 Architecture & Design
 Implementation
 Consequences
 Authentication
 If hard-coded passwords are used, it is almost certain that malicious users
will gain access through the account in question
 Exploit Likelihood: Very high
OWASP
45
Porous Defenses – Hard-Coded Password
 Potential Mitigation
 Architecture and Design
 For outbound authentication: store passwords outside of the code in a
strongly-protected, encrypted configuration file or database that is protected
from access by all outsiders, including other local users on the same system
 For inbound authentication: Rather than hard-code a default username and
password for first time logins, utilize a "first login" mode that requires the
user to enter a unique strong password
 Perform access control checks and limit which entities can access the feature
that requires the hard-coded password
 For inbound authentication: apply strong one-way hashes to your passwords
and store those hashes in a configuration file or database with appropriate
access control
OWASP
46
Porous Defenses – Hard-Coded Password
 For front-end to back-end connections: Three solutions are possible:
– The first suggestion involves the use of generated passwords which are changed
automatically and must be entered at given time intervals by a system
administrator. These passwords will be held in memory and only be valid for the
time intervals
– Next, the passwords used should be limited at the back end to only performing
actions valid for the front end, as opposed to having full access
– Finally, the messages sent should be tagged and checksummed with
time sensitive values so as to prevent replay style attacks
OWASP
47
Porous Defenses – Insecure Permission
Assignment for Critical Resource
 What this means
 The software specifies permissions for a security-critical resource in a way that
allows that resource to be read or modified by unintended actors
 When it Occurs




Architecture and Design
Implementation
Installation
Operation
 Exploit Likelihood: Medium to high
OWASP
48
Porous Defenses – Insecure Permission
Assignment for Critical Resource
 Potential Mitigation
 Architecture and Design
 When using a critical resource such as a configuration file, check to see if
the resource has insecure permissions
 Divide your application into anonymous, normal, privileged, and
administrative areas. Reduce the attack surface by carefully defining distinct
user groups, privileges, and/or roles. Map these against data, functionality,
and the related resources and then set the permissions accordingly
 System Configuration
 For all configuration files, executables, and libraries, make sure that they are
only readable and writable by the software's administrator
 Implementation
 During program startup, explicitly set the default permissions or unmask to
the most restrictive setting possible. Also set the appropriate permissions
during program installation. This will prevent you from inheriting insecure
permissions from any user who installs or runs the program.
OWASP
49
Porous Defenses – Use of Insufficiently
Random Values
 What this means
 When software receives predictable values in a context requiring unpredictability,
it may be possible for an attacker to guess those predictable values, and use this
guess to impersonate another user or access sensitive information
 When it Occurs
 Architecture & Design
 Exploit Likelihood: Medium to high
OWASP
50
Porous Defenses – Use of Insufficiently
Random Values
 Potential Mitigation
 Architecture and Design
 Use a well-vetted algorithm that is currently considered to be strong by
experts in the field, and select well-tested implementations with adequate
length seeds
 Implementation
 Consider a PRNG that re-seeds itself as needed from high quality pseudorandom output sources, such as hardware devices
OWASP
51
Porous Defenses – Execution with
Unnecessary Privileges
 What this means
 The software performs an operation at a privilege level that is higher than the
minimum level required, which creates new weaknesses or amplifies the
consequences of other weaknesses
 When it Occurs
 Architecture & Design
 Installation
 Operation
 Common consequences
 Confidentiality
 Integrity
 Availability
 An attacker will be able to gain access to any resources that are allowed by
the extra privileges. Common results include executing code, disabling
services, and reading restricted data.
 Exploit Likelihood: Medium
OWASP
52
Porous Defenses – Execution with
Unnecessary Privileges
 Potential Mitigation
 Architecture and Design
 Identify the functionality that requires additional privileges, such as access
to privileged operating system resources. Wrap and centralize this
functionality if possible, and isolate the privileged code as much as possible
from other code
 Implementation
 Perform extensive input validation for any privileged code that must be
exposed to the user and reject anything that does not fit your strict
requirements
 If circumstances force you to run with extra privileges, then determine the
minimum access level necessary
 Ensure that you drop privileges as soon as possible (CWE-271), and make
sure that you check to ensure that privileges have been dropped
successfully
OWASP
53
Porous Defenses – Client-Side Enforcement
of Server-Side Security
 What this means
 When the server relies on protection mechanisms placed on the client side, an
attacker can modify the client-side behavior to bypass the protection
mechanisms resulting in potentially unexpected interactions between the client
and server. The consequences will vary, depending on what the mechanisms are
trying to protect
 When it Occurs
 Architecture & Design
 Exploit Likelihood: Medium
 Potential Mitigation
 Architecture and Design
 For any security checks that are performed on the client side, ensure that
these checks are duplicated on the server side. 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
OWASP
54
Porous Defenses – Client-Side Enforcement
of Server-Side Security
 If some degree of trust is required between the two entities, then use
integrity checking and strong authentication to ensure that the inputs are
coming from a trusted source
 Testing
 Use dynamic tools and techniques that interact with the software using large
test suites with many diverse inputs, such as fuzz testing (fuzzing),
robustness testing, and fault injection. The software's operation may slow
down, but it should not become unstable, crash, or generate incorrect
results
OWASP
55
References
http://www.sans.org/top25errors/
Common Weakness Enumeration http://cwe.mitre.org/top25/
OWASP
56
Questions?
OWASP
57
Thank You
OWASP
58
Descargar

OWASP Plan