Security Testing III

Front

CWE: Common Weakness Enumeration

Back

The CWE (Common Weakness Enumeration) provides a list of the most common software and hardware weaknesses that can contribute to security vulnerabilities, with each CWE having a unique identifier and being described by several fields. CWEs vary in levels of abstraction and are hierarchically organized, with relationships such as "parent of," "child of," "can follow," and "member of."

Front

CWE: Top 10/25

Back

These lists highlight the most dangerous software weaknesses across various applications and systems, not limited to a single domain like the web. Each CWE is scored based on its prevalence, measured by how often it is linked to a CVE, its average severity in real-world applications, and the potential damage if exploited. The Top 10 focuses on known exploited vulnerabilities (KEV), while the Top 25 considers broader factors such as the source of information, ease of detection by code scanning tools, ease of exploitation, and the potential impact for adversaries exploiting these weaknesses.

Front

CWE Top-10 Weaknesses

Back

1. Use-After-Free (CWE-416)

2. Heap-based Buffer Overflow (CWE-122)

3. Out-of-bounds Write (CWE-787)

4. Improper Input Validation (CWE-20)

5. Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection’) (CWE-78)

6. Deserialization of Untrusted Data (CWE-502)

7. Server-Side Request Forgery (SSRF) (CWE-918)

8. Access of Resource Using Incompatible Type ('Type Confusion’) (CWE-843)

9. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal’) (CWE-22)

10. Missing Authentication for Critical Function (CWE-306)

Front

Use-After-Free (CWE-416)

Back

Description:

• The product reuses or references memory after it has been freed.

• At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation.

• Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Prevention:

• Choose a language that provides automatic memory management.

• When freeing pointers, be sure to set them to NULL once they are freed.

Detection:

• Fuzzing

• Automatic static analysis

Front

Use-After-Free (CWE-416): note

Back

• UAF not only relates to pointers and memory.

• UAF(-like) weaknesses can be found also when other resources (e.g., file handles or network connections) are mismanaged.

• Hence, UAF can occur also in languages (e.g., Java) with automatic memory management system.

Front

Heap-based Buffer Overflow (CWE-122)

Back

Description:

• A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using malloc() or new().

Prevention:

• Use automatic buffer overflow detection mechanisms

• Implement and perform bounds checking on input.

• Do not use dangerous functions such as gets. Look for their safe equivalent, which checks for the boundary.

Detection:

• Fuzzing

• Automated static analysis

Front

Out-of-bounds Write (CWE-787)

Back

Description:

• The product writes data past the end, or before the beginning, of the intended buffer.

• Often used to describe the consequences of writing to memory outside the bounds of a buffer, or to memory that is otherwise invalid.

Prevention:

• Double check that the buffer is as large as specified

and check buffer boundaries.

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

Detection:

• Automated static analysis

• Automated dynamic analysis (fuzzing, fault-injection based testing)

Front

Out-of-bounds Write (CWE-787): note

Back

CWE-119: Improper Restriction of Operations

within the Bounds of a Memory Buffer

Description:

• The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary.

• This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.

Front

Improper Input Validation (CWE-20)

Back

Description:

• The product receives input values, but it does not validate or incorrectly validates them.

• Input validation is a frequently-used technique for checking potentially dangerous inputs in order to ensure that the inputs are safe for processing within the code.

• In the case of no-validation, unintended input values can alter the program control flow.

Prevention:

• Use an input validation framework, e.g., Struts, OWASP ESAPI Validation APIs.

• Check all the potentially untrusted inputs (e.g., parameters, arguments, cookies, anything read from the network)

• Assume all input is malicious.

Detection:

• Automated/Manual static analysis.

• Automated dynamic analysis (fuzzing, fault-injection testing).

Front

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

Back

Description:

• The product constructs an OS command using externally- influenced input, but it does not neutralize (or it incorrectly neutralizes) special elements that could modify the intended OS command.

Prevention:

• Use library calls rather than external processes to recreate the desired functionality.

• For any security checks performed on the client side, ensure

that these checks are duplicated on the server side

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

Detection:

• Automated static analysis (not perfect solution since APIs cannot be analyzed/considered by tools)

• Automated dynamic analysis (fuzzing, fault-injection based

testing