CSE 270: Software Testing - Reading Material

5.6 Security Testing

Introduction

Security testing is a huge topic in software testing today. With the prevalence of data breaches, cyber attacks and other malicious actors trying to profit off of criminal activity, it is more important than ever that software is carefully examined for security defects. Effective security testing typically requires specialized training in ethical hacking techniques. Understanding security testing well can lead to a lucrative career in the security industry. Let’s start with an overview of the various types of security testing and how they are conducted.

Types of Security Testing

• Vulnerability Assessment:
  • Objective: Identify and assess vulnerabilities in a system.
  • Methodology: Use automated tools and manual techniques to scan the system for known weaknesses and potential security risks.
  • Outcome: Provides a comprehensive list of vulnerabilities, helping prioritize remediation efforts.
• Penetration Testing:
  • Objective: Simulate real-world cyber-attacks to assess the system's defenses.
  • Methodology: Ethical hackers (penetration testers) attempt to exploit vulnerabilities, gaining insights into potential threats and weaknesses.
  • Outcome: Helps identify and remediate specific vulnerabilities, assesses the system's overall security posture, and provides recommendations for improvement.
• Security Auditing:
  • Objective: Review and evaluate the system's security policies, configurations, and adherence to security standards.
  • Methodology: Conduct a comprehensive review of security controls, policies, and settings to ensure compliance with established security guidelines.
  • Outcome: Provides insights into the system's overall security hygiene, highlighting areas of non-compliance and suggesting corrective actions.
• Security Scanning:
  • Objective: Automate the process of scanning for known vulnerabilities and misconfigurations.
  • Methodology: Use specialized tools to identify and report vulnerabilities in the system's software, network, or configurations.
  • Outcome: Generates reports detailing identified vulnerabilities and potential security risks, allowing teams to prioritize remediation efforts.
• Security Code Review:
  • Objective: Analyze the source code for security flaws and vulnerabilities.
  • Methodology: Manual or automated review of source code to identify potential security weaknesses, such as injection flaws, insecure dependencies, or improper error handling.
  • Outcome: Provides insights into code-level vulnerabilities, allowing developers to address security issues during the development phase.
• Fuzz Testing:
  • Objective: Identify vulnerabilities by subjecting the system to unexpected or malformed inputs.
  • Methodology: Automated testing with a large volume of invalid, unexpected, or random data to discover potential vulnerabilities or crashes.
  • Outcome: Reveals how the system handles unexpected inputs and helps identify potential security weaknesses.
• Authentication and Authorization Testing:
  • Objective: Evaluate the effectiveness of authentication and authorization mechanisms.
  • Methodology: Test user authentication processes, access controls, and authorization mechanisms to identify vulnerabilities related to user identity and permissions.
  • Outcome: Highlights weaknesses in user authentication and authorization, helping strengthen access controls.
• Security Configuration Review:
  • Objective: Assess the security configurations of systems, applications, and network devices.
  • Methodology: Review configurations to ensure they align with security best practices and standards.
  • Outcome: Identifies misconfigurations that could lead to security vulnerabilities, providing recommendations for securing configurations.
• Encryption and Cryptography Testing:
  • Objective: Assess the strength and effectiveness of encryption and cryptographic implementations.
  • Methodology: Evaluate encryption algorithms, key management, and cryptographic protocols to ensure secure data protection.
  • Outcome: Identifies weaknesses in encryption practices and cryptographic implementations, enhancing data security.
• Security Incident Response Testing:
  • Objective: Evaluate the organization's ability to respond effectively to security incidents.
  • Methodology: Simulate security incidents to test the incident response plan, coordination, and communication.
  • Outcome: Assesses the organization's readiness to handle security incidents, identifies areas for improvement in incident response processes.
• Social Engineering Testing:
  • Objective: Assess the susceptibility of employees to social engineering attacks.
  • Methodology: Simulate social engineering tactics, such as phishing or impersonation, to test the awareness and response of employees.
  • Outcome: Identifies vulnerabilities related to human factors, helping improve employee awareness and training.

Each testing type plays a valuable role in ensuring a comprehensive and robust security posture for software systems. The combination of these approaches helps organizations build resilient and secure applications while effectively addressing potential security risks.

Categorizing Security Risks using the Common Weakness Enumeration

The Common Weakness Enumeration (CWE) is a community-driven initiative that originated from collaborative efforts between the MITRE Corporation and various cybersecurity organizations. Its development started in 2005 to address the need for a standardized language to identify and categorize software weaknesses and vulnerabilities

Key Components and Structure

CWE is structured around the following key components:

• Weaknesses: Each weakness is assigned a unique identifier, allowing for unambiguous reference. Examples include SQL injection, buffer overflow, and use of hardcoded credentials.
• Categories: Weaknesses are organized into categories based on shared characteristics, making it easier to navigate and comprehend. Categories include input validation issues, authentication problems, and cryptography errors.
• Relationships: CWE establishes relationships between weaknesses, providing insights into the connections between different vulnerabilities and facilitating a more nuanced understanding.

Software testers can use the Common Weakness Enumeration (CWE) to enhance their testing efforts and contribute to the overall security of the software they are testing.

Staying Up-To-Date on Common Threats using the OWASP Top Ten

The OWASP (Open Web Application Security Project) Top Ten is a regularly updated list that originated from the collaborative efforts of security professionals worldwide within the OWASP community. The project was initiated in 2003 to raise awareness about the most critical security risks affecting web applications. The OWASP Top Ten is updated periodically to reflect the evolving threat landscape in web application security.

The most current OWASP Top Ten list can be found at the URL https://owasp.org/www-project-top-ten/

The OWASP Top Ten serves several purposes and is widely used in the cybersecurity community:

• Risk Awareness: The list aims to increase awareness of common security risks in web applications among developers, security professionals, and organizations.
• Guidance for Prioritization: It provides guidance on prioritizing security efforts by highlighting the most critical risks that developers and organizations should address.
• Educational Resource: The OWASP Top Ten serves as an educational resource for developers, offering insights into prevalent security risks and best practices for mitigation.
• Benchmarking Security Posture: Organizations can use the list to benchmark their security posture against industry standards and best practices.

Relationship with CWE

While both the OWASP Top Ten and CWE (Common Weakness Enumeration) address security issues in software, they have different scopes and objectives. The OWASP Top Ten focuses specifically on web application security risks and provides a concise, prioritized list. In contrast, CWE is a more comprehensive catalog that covers a broader range of software weaknesses beyond web applications.

The relationship between OWASP Top Ten and CWE lies in the fact that the OWASP Top Ten often references CWE identifiers for specific vulnerabilities. This linkage allows for a more detailed understanding of the underlying weaknesses associated with each item on the OWASP list. CWE provides a more extensive framework for categorizing and describing these weaknesses.

By learning the OWASP Top Ten, software testers can contribute to building more secure web applications, align their efforts with industry-recognized security priorities, and foster a proactive approach to identifying and mitigating common security risks.

Memory Safety in Programming Languages

Memory safety is an important aspect of programming language design and refers to a language's ability to prevent certain types of memory-related errors, such as buffer overflows, use-after-free, and dangling pointers. A memory-safe language helps mitigate vulnerabilities and enhances the overall security and stability of software.

Memory-Safe Languages:

Several programming languages are designed with memory safety features, including:

• Java: Java uses automatic memory management (garbage collection) to handle memory allocation and deallocation, reducing the risk of memory-related errors.
• C#: Similar to Java, C# incorporates garbage collection to manage memory automatically and provides a safer memory environment.
• Python: Python utilizes automatic memory management and lacks low-level memory manipulation features, contributing to a memory-safe environment.
• JavaScript: JavaScript is memory-safe as it is an interpreted language with automatic memory management, eliminating the need for explicit memory allocation and deallocation.

Memory-Unsafe Languages:

Certain commonly used programming languages lack built-in memory safety features, making them prone to memory-related vulnerabilities. Notable examples include:

• C: C is a powerful but memory-unsafe language. It allows direct memory manipulation and lacks built-in mechanisms to prevent buffer overflows and similar issues.
• C++: C++ inherits memory-unsafe features from C, including manual memory management with pointers, making it susceptible to memory-related vulnerabilities.
• Assembly Language: As a low-level language, assembly provides minimal abstractions, requiring developers to manage memory manually and increasing the risk of errors.

Common Memory-Related Issues:

• Buffer Overflow:
  • Description: A buffer overflow occurs when data exceeds the allocated space in a buffer, leading to overwriting adjacent memory.
  • Memory Unsafe Languages Impact: C and C++ are particularly susceptible due to manual memory management and lack of array bounds checking.
  • Consequences: Exploitable vulnerabilities, potential code execution, and compromise of system integrity.
• Use-After-Free:
  • Description: Use-after-free occurs when a program accesses memory that has already been deallocated, potentially leading to unintended behavior or security vulnerabilities.
  • Memory Unsafe Languages Impact: C and C++ are more prone due to manual memory management and explicit deallocation.
  • Consequences: Exploitable vulnerabilities, crashes, and unauthorized access to memory.

Understanding memory safety and adopting memory-safe languages or practices is helpful for building secure and robust software, reducing the likelihood of memory-related vulnerabilities that can be exploited by malicious actors.

Useful Links:  ←Unit 5.5 |  Unit 5.7→  | Table of Contents | Canvas