Simple Guide to Preventing Software Security Weaknesses

Product Managers to Scrum Masters, and even those just curious about software have had some exposure to software development. You may have taken a few college classes on software development, dabbled in coding during your early career, or read about the latest tech trends in your free time. However, as roles evolve and the focus shifts away from hands-on coding, it's easy to lose touch with the intricacies of secure software.

?

The democratization of coding is more apparent than ever. Tools like ChatGPT Code Interpreter, AWS CodeWhisperer, Github Copilot, and more make software development accessible to a broader audience. This has given rise to the term "citizen developer," referring to individuals who, while not in traditional development roles, are venturing into the coding realm, whether out of professional necessity or personal curiosity. This guide offers a concise overview of some of the most prevalent software security weaknesses, ensuring that your ventures into code, no matter how occasional, remain robust and secure.

?

Before going into the specifics, it is helpful to familiarize yourself with the term "CWE." CWE, or Common Weakness Enumeration, is a community-driven project that identifies and categorizes prevalent software weaknesses. Notably, injection and memory corruption/disclosure weaknesses have consistently been among the most frequent and impactful over the past decade. The numbers accompanying each CWE, such as CWE-89, represent specific entries in the CWE list. This allows professionals and enthusiasts to reference detailed information about each weakness, enhancing their understanding and awareness.

?

1. Injection Weaknesses ?

?Injection weaknesses occur when untrusted data is sent to an interpreter as part of a command or query. This can trick the interpreter into executing unintended commands or accessing unauthorized data.

?

SQL Injection (CWE-89)

SQL injection is a type of security weakness that occurs when an attacker can insert or "inject" malicious SQL code into a query. This can allow the attacker to view data they shouldn't have access to, modify or delete data, and execute administrative operations on the database. It's a critical vulnerability because it can lead to a complete compromise of the affected system.

?

Example in Java

In the following Java code, user input is directly concatenated into an SQL query, making it vulnerable to SQL injection:

String userId = request.getParameter("userId");

String query = "SELECT * FROM users WHERE id = " + userId;?        

?

?If an attacker provides a value like 1 OR 1=1 for userId, the resulting query would return all records from the users table, potentially revealing sensitive information.

?

Mitigation

To prevent SQL injection, it's recommended to use prepared statements in Java. Prepared statements ensure user input is always treated as data and not executable code. Here's how you can use prepared statements:

String userId = request.getParameter("userId");

String query = "SELECT * FROM users WHERE id = ?";

PreparedStatement preparedStatement = connection.prepareStatement(query);

preparedStatement.setInt(1, Integer.parseInt(userId));

ResultSet resultSet = preparedStatement.executeQuery();?        

Using a prepared statement, the userId value is safely parameterized, and any malicious input will not be executed as part of the SQL query.

?

OS Command Injection (CWE-78)

OS Command Injection is a type of security vulnerability where an attacker can exploit an application to run arbitrary commands on the host operating system. This can lead to unauthorized access, data theft, data corruption, and potentially full system compromise.

?

Example in Python

In the Python code below, user input is directly passed to an OS command, making it vulnerable to command injection:

import os

filename = input("Enter filename to delete: ")

os.system("rm " + filename)?        

If an attacker provides a value like myfile.txt; cat /etc/passwd, not only will myfile.txt be deleted, but the contents of the /etc/passwd file (which contains user account information on Unix-based systems) will also be displayed.

?

Mitigation

1. Avoid Direct OS Commands: Use language-specific or library-specific functions whenever possible instead of directly invoking OS commands. For instance, you can use the os.remove() function to delete a file in Python.

2. Sanitize Inputs Rigorously: If you must use OS commands, ensure that user inputs are rigorously sanitized. This means validating, filtering, and escaping any data that will be passed to an OS command. Avoid allowing any form of dynamic input to be executed without strict validation.

3. Use Allowlist: Only allow specific, known-safe inputs. Reject any input that doesn't match the allowlist.

4. Limit Privileges: Run applications with the least privileges necessary. This way, even if an attacker manages to inject a command, the damage they can do is limited.

?

Deserialization of Untrusted Data (CWE-502)

Deserialization is the process of converting a stream of bytes back into a copy of the original object. When untrusted data is deserialized without proper validation, it can lead to arbitrary code execution.

?

Example in Java

?Suppose you have a simple Person class:

?// java

import java.io.Serializable;

public class Person implements Serializable {

??? private String name;

??? private int age;

??? // getters, setters, and other methods...

}        

?And you deserialize an object of this class from a byte stream:

// java

import java.io.ObjectInputStream;

import java.io.FileInputStream;

?public class DeserializePerson {

??? public static void main(String[] args) {

??????? try {

??????????? FileInputStream fileIn = new FileInputStream("person.ser");

??????????? ObjectInputStream in = new ObjectInputStream(fileIn);

??????????? Person person = (Person) in.readObject();

??????????? in.close();

??????????? fileIn.close();

??????? } catch (Exception e) {

??????????? e.printStackTrace();

??????? }

??? }

}        

If an attacker can provide a malicious person.ser file, they might be able to execute arbitrary code on your system.

?

Mitigation

1. Avoid deserializing data from untrusted sources.

2. Implement strict type checks during deserialization to ensure that only expected types are processed.

3. Use safe serialization formats like JSON or XML, which don't support code execution.

?

Code Injection (CWE-94)

?Code Injection is a type of security vulnerability that arises when an application allows untrusted input to be executed as code. Attackers can exploit this flaw to run malicious code within the application's context, potentially leading to data theft, data manipulation, or even full system compromise.

?

Example in JavaScript (Node.js)

?In the Node.js code snippet below, user input is directly passed to the eval() function, which evaluates and executes the provided string as JavaScript code:

// javascript

let code = req.query.code;

eval(code);?        

If an attacker sends a request with a malicious code snippet as the code query parameter, it will be executed by the server. For instance, they could send code to access sensitive data or disrupt the server's operations.

?

Mitigation

1. Avoid Using eval(): The simplest and most effective way to prevent code injection is to avoid using functions like eval() that can execute strings as code.

2. Rigorous Input Validation: If there's an absolute need to use such functions, ensure that all inputs are rigorously validated. Use strict whitelists to determine what is allowed and reject anything that doesn't match.

3. Use Safe Alternatives: In many cases, there are safer alternatives to functions like eval(). For JavaScript, consider using JSON.parse() it for safely parsing JSON strings or other methods that don't execute code.

4. Limit Privileges: Run your application with the least privileges necessary. This way, even if an attacker manages to inject code, the potential damage can be minimized.

?

Expression Language Injection (CWE-917)

Expression Language (EL) provides a way to access Java object properties, methods, or application data within a Java web application. When user input is improperly included in these expressions without validation, attackers can inject malicious EL expressions, leading to data breaches or even remote code execution.

?

Example in Java (within a JSF context)

?Suppose you have a JSF page where you display a user message:

?// xml

<h:outputText value="#{param.userMessage}" />        

?An attacker can send a request with the following parameter:

userMessage=#{requestScope['javax.servlet.jsp.jstl.fmt.localizationContext'].parent.config.servletContextName}?        

This would cause the application to display the servlet context name, indicating that the attacker can evaluate arbitrary EL expressions.

?

Mitigation

?1. Never directly include user input in EL expressions.

2. Use parameterized methods or APIs that automatically handle user input safely.

3. Configure your web application to use the latest version of the EL processor, which might have added protections against such injections.

?

2. Memory Corruption/Disclosure Weaknesses ?

?These weaknesses arise from mismanagement of memory, leading to unexpected behavior.

?

Out-of-bounds Write (CWE-787)

An out-of-bounds write occurs when data is written to a buffer beyond its allocated size. This can corrupt adjacent memory, leading to unpredictable behavior, crashes, or even the execution of malicious code if exploited by an attacker.

Example in C++

?In the C++ code snippet below, a buffer is allocated to hold 10 characters, but a longer string is copied into it:

?// cpp

char buffer[10];

strcpy(buffer, "This string is too long!");        

This results in writing past the end of the buffer, potentially overwriting other memory locations.

?

Mitigation

1. Check Data Length: Always verify the length of data before writing it to a buffer. Ensure it does not exceed the buffer's allocated size.

2. Use Safe Functions: Instead of functions like strcpy, which do not check buffer sizes, consider using safer alternatives like strncpy that take the maximum length as an argument.

3. Memory Management Libraries: Utilize libraries or features that help manage memory more safely, such as C++'s std::string or std::vector.

4. Boundary Checks: Implement boundary checks in your code to prevent writing outside of allocated memory.

?

Classic Buffer Overflow (CWE-120)

A classic buffer overflow vulnerability arises when more data is written into a buffer than it can hold, causing the excess data to overflow into adjacent memory. This can lead to unpredictable behavior, crashes, or even the execution of malicious code if exploited.

Example in C++

In the C++ code snippet below, a buffer is allocated to hold 50 characters. However, there's no check on the length of the input before copying it to the buffer, which can lead to an overflow if input is longer than 50 characters:

// cpp

void unsafe_function(char *input) {

??? char buffer[50];

??? strcpy(buffer, input);

}        

Mitigation

?1. Use Safe Functions: Instead of using strcpy, which does not check buffer sizes, consider using safer alternatives like strncpy. This function takes an additional argument specifying the maximum number of characters to copy, preventing overflows:

?? // cpp

?? strncpy(buffer, input, sizeof(buffer) - 1);

?? buffer[sizeof(buffer) - 1] = '\0';? // Ensure null termination?        

2. Boundary Checks: Always verify the length of data before writing it to a buffer to ensure it doesn't exceed the buffer's allocated size.

3. Modern C++ Practices: Consider using C++ standard library containers like std::string which manage memory dynamically and reduce the risk of buffer overflows.

?

?

Use After Free (CWE-416)

Use After Free refers to a situation where a program continues to use a memory location after it has been deallocated or freed. This can lead to various vulnerabilities, including data corruption, crashes, and potentially allowing an attacker to execute arbitrary code.

?

Example in C++

In the C++ code snippet below, an integer is dynamically allocated on the heap and then immediately deallocated. However, the program then tries to access and modify the memory through the pointer, which is now pointing to a freed memory location:

// cpp

int* ptr = new int(10);? // Allocate memory for an integer on the heap

delete ptr;????????// Deallocate the memory

*ptr = 4;?????????// Use after free: trying to access freed memory?        

??

Mitigation

1. Nullify Pointers: After deallocating memory, always set the pointer to nullptr. This ensures that any subsequent use of the pointer will be more easily detected as it will lead to a null pointer dereference, which is typically easier to diagnose than use after free:

?? // cpp

?? delete ptr;

?? ptr = nullptr;        

2. Avoid Double Freeing: Ensure that memory is not freed more than once. Double freeing can also lead to vulnerabilities.

3. Use Smart Pointers: Modern C++ offers smart pointers like std::unique_ptr and std::shared_ptr which automatically manage memory and can help prevent use after free and other memory-related issues.

?

NULL Pointer Dereference (CWE-476)

?A NULL Pointer Dereference occurs when a program tries to access or modify memory through a pointer that hasn't been initialized (i.e., it points to nullptr or NULL). This can lead to undefined behavior, typically resulting in program crashes, and in some contexts, it might be exploited for malicious purposes.

?

Example in C++

?In the C++ code snippet below, a pointer is explicitly initialized to nullptr, which means it doesn't point to any valid memory location. The subsequent attempt to dereference this pointer leads to undefined behavior:

?// cpp

int *ptr = nullptr;? // Pointer initialized to nullptr

*ptr = 4;??????????? // Dereferencing a nullptr, leading to undefined behavior?        

Mitigation

1. Initialize Pointers: Always initialize pointers when they are declared. This can be to a valid memory location or to nullptr if the actual memory location is not yet known.

2. Null Checks: Before dereferencing a pointer, always check if it's nullptr. This can prevent unintended dereferences:

?? // cpp

?? if (ptr != nullptr) {

?????? *ptr = 4;

?? }?        

3. Use Modern C++ Practices: Consider using smart pointers like std::unique_ptr and std::shared_ptr which, in many cases, can help manage memory more safely and reduce the risk of null pointer dereferences.

Conclusion

The tech industry is vast, and roles often blur the lines between business and development. Whether you're a seasoned Product Manager, an insightful Business Analyst, or a dedicated Scrum Master, having a foundational understanding of software weaknesses is invaluable. As the world of coding becomes more accessible to everyone, being vigilant and adopting best practices to mitigate these weaknesses is crucial. Regular code reviews, using security tools, and continuous education are essential in maintaining a secure software environment.