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.
Download ReportTranscript 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.
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