1. 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 OWASP http://www.owasp.org Top 25 Programming Mistakes Venki Chennai Chapter Leader Cognizant Technology Solutions venki@owasp.org +91-9840148148 21-March-2009

2. OWASP 2 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

3. OWASP 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 3

4. OWASP 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 4

5. OWASP 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 5

6. OWASP 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 6

7. OWASP 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 7

8. OWASP 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 8

9. OWASP 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 9

10. OWASP 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 10

11. OWASP 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 11

12. OWASP 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 12

13. OWASP 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 13

14. OWASP 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 14

15. OWASP 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 15

16. OWASP 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 16

17. OWASP 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 17

18. OWASP 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 18

19. OWASP 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 19

20. OWASP 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 20

21. OWASP 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  Exploit Likelihood: High 21

22. OWASP 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 22

23. OWASP 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  Exploit Likelihood: High 23

24. OWASP 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 24

25. OWASP 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 25

26. OWASP 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 26

27. OWASP 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 27

28. OWASP 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 28

29. OWASP Risky Resource Management – Code Injection  What this means  The product does not sufficiently filter code (control-plane) syntax from user- controlled 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 29

30. OWASP 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 30

31. OWASP 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 31

32. OWASP 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 32

33. OWASP Risky Resource Management – Improper Resource Shutdown or Release 33  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

34. OWASP 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. 34

35. OWASP 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 35

36. OWASP 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. 36

37. OWASP 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. 37

38. OWASP 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 38

39. OWASP 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 39

40. OWASP 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 40

41. OWASP 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 41

42. OWASP 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 42

43. OWASP 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 43

44. OWASP 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 44

45. OWASP 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 45

46. OWASP 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 46

47. OWASP 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 47

48. OWASP 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 48

49. OWASP 49 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.

50. OWASP 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 50

51. OWASP 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 pseudo- random output sources, such as hardware devices 51

52. OWASP 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 52

53. OWASP 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 53

54. OWASP 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 54

55. OWASP 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 55

56. OWASP References  http://www.sans.org/top25errors/ http://www.sans.org/top25errors/  Common Weakness Enumeration - http://cwe.mitre.org/top25/ http://cwe.mitre.org/top25/ 56

57. OWASP Questions? 57

58. OWASP Thank You 58