As cyber threats continue to evolve, ensuring our applications are secure from vulnerabilities is paramount. The OWASP Top 10 is a widely recognized standard that highlights the most critical security risks to web applications. Understanding and addressing these risks is essential for protecting our application and its users.

In this post, we will delve into automated testing methods for the first five vulnerabilities identified in the OWASP Top 10 for 2021. By incorporating these tests into our QA processes, we can catch and mitigate these vulnerabilities before they become significant issues.

We will cover the following five vulnerabilities:

• A01:2021-Broken Access Control
• A02:2021-Cryptographic Failures
• A03:2021-Injection
• A04:2021-Insecure Design
• A05:2021-Security Misconfiguration

Let's get started with understanding each vulnerability and how to effectively test for them.

A01:2021-Broken Access Control

Broken Access Control occurs when restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access unauthorized functionalities and data, such as viewing sensitive files, modifying user data, or changing access rights.

Common Consequences and Examples:

• Unauthorized Information Disclosure: Users can access data they should not see, such as by modifying the URL to access another user's account.
• Modification or Deletion of Data: Users can alter or delete data they do not own.
• Privilege Escalation: Regular users can perform administrative functions, for example, by exploiting an insecure direct object reference.
• API Endpoint Issues: API endpoints allowing access without proper authorization checks.

Testing Strategy:

A general approach for testing Broken Access Control includes:

• Identifying All Access Control Points: List all resources and functionalities that should be protected.
• Verifying Role-Based Access Controls: Ensure each role has appropriate permissions.
• Testing URL Manipulations: Check if users can access restricted resources by altering URLs.
• Checking Direct Object References: Ensure that object identifiers are not exposed or exploitable.
• Inspecting API Endpoints: Verify that all endpoints enforce proper authorization.

Code Example:

Here is a sample test using Selenium to verify role-based access control in a web application:

                                     
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
                        
# Initialize the Chrome driver
driver = webdriver.Chrome()
                        
try:
    # Admin user login
    driver.get('http://example.com/login')
    driver.find_element(By.ID, 'username').send_keys('admin')
    driver.find_element(By.ID, 'password').send_keys('adminpass' + Keys.RETURN)
                        
    # Access restricted admin page
    driver.get('http://example.com/admin')
    assert "Admin Page" in driver.page_source, "Admin should have access to admin page"
                        
    # Logout
    driver.get('http://example.com/logout')
                        
    # Regular user login
    driver.get('http://example.com/login')
    driver.find_element(By.ID, 'username').send_keys('user')
    driver.find_element(By.ID, 'password').send_keys('userpass' + Keys.RETURN)
                        
    # Try accessing the restricted admin page
    driver.get('http://example.com/admin')
    assert "Access Denied" in driver.page_source, "Regular user should not have access to admin page"
                            
finally:
    driver.quit()
                    

The script first logs in as an admin and accesses a restricted admin page to verify that the admin has the necessary access. Then, it logs out, logs back in as a regular user, and attempts to access the same admin page, ensuring that access is denied for non-admin users.

This example demonstrates how to automate the testing of role-based access control using Selenium. By regularly running such tests, we can ensure that our application's access controls are correctly enforced, reducing the risk of unauthorized access.

If you'd like to see a practical example, rather than just a sample, I've added a similar script to our GitHub page. This script demonstrates the vulnerability on the OWASP Juice Shop web application.

A02:2021-Cryptographic Failures

Cryptographic Failures occur when cryptographic algorithms are implemented incorrectly or when sensitive data is not adequately protected during storage or transmission. This can lead to data breaches, unauthorized access, and other security incidents.

Common Scenarios and Impacts:

• Unencrypted Data Transmission: Sensitive data sent over unencrypted channels can be intercepted by attackers.
• Weak or Deprecated Algorithms: Using outdated or weak cryptographic algorithms can be easily broken by attackers.
• Improper Key Management: Poor key generation, storage, and handling practices can compromise encryption schemes.
• Failure to Use HTTPS: Not enforcing HTTPS can expose sensitive data to interception and tampering.

Testing Strategy:

A general approach for testing Cryptographic Failures includes:

• Verifying Data Transmission Security: Ensure all sensitive data is transmitted over secure channels (e.g., HTTPS).
• Checking Algorithm Strength: Confirm that strong, up-to-date cryptographic algorithms are used.
• Reviewing Key Management Practices: Assess how cryptographic keys are generated, stored, and managed.
• Enforcing HTTPS: Verify that HTTPS is enforced across the entire application.

Code Example:

Here is a sample script using Python's requests library to check for HTTPS enforcement:

                                     
import requests

# List of URLs to test
urls = [
    'http://example.com/login',
    'http://example.com/register',
    'http://example.com/profile'
]
                        
def check_https(url):
    https_url = url.replace('http://', 'https://')
    try:
        response = requests.get(https_url)
        if response.status_code == 200:
            print(f"HTTPS is enforced for: {url}")
        else:
            print(f"HTTPS not enforced for: {url}")
    except requests.exceptions.RequestException as e:
        print(f"Failed to connect to {https_url}: {e}")
                        
for url in urls:
    check_https(url)
                    

The script checks a list of URLs that should be secured by attempting to connect to each URL using HTTPS. If the connection is successful and returns a status code of 200, it confirms that HTTPS is enforced; otherwise, it flags the URL as not being secure. This example demonstrates how to automate the testing for HTTPS enforcement, ensuring that all sensitive data transmissions are properly secured. By regularly running such tests, we can identify and remediate cryptographic failures, enhancing the overall security of our application.

A03:2021-Injection

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Types of Injection Attacks and Their Effects:

• SQL Injection: Attacker can manipulate SQL queries, potentially exposing or altering database data.
• Command Injection: Attacker can execute arbitrary system commands on the server.
• LDAP Injection: Attacker can modify LDAP statements to access unauthorized data or bypass authentication.
• XPath Injection: Attacker can alter XML queries to retrieve unauthorized data.

These attacks can lead to data breaches, loss of data integrity, denial of service, and unauthorized access.

Testing Strategy:

A general approach for testing Injection flaws includes:

• Input Validation: Ensure all user inputs are validated, sanitized, and escaped.
• Parameterized Queries: Use parameterized queries and prepared statements to prevent SQL injection.
• Code Review: Conduct code reviews to identify and fix potential injection points.
• Automated Scanning: Utilize automated security scanning tools to detect injection vulnerabilities.
• Fuzz Testing: Perform fuzz testing to send random data to the application and observe its behavior.

Code Example:

                                     
import requests

# URL of the web application's login endpoint
url = 'http://example.com/login'
                        
# List of payloads to test for SQL injection
payloads = [
    "' OR '1'='1",
    "' OR '1'='1' --",
    "' OR 1=1 --",
    "' OR 'a'='a",
    "' OR 'a'='a' --",
    "' OR 1=1 #",
    "' OR '1'='1' /*"
]
                        
def test_sql_injection(url, payloads):
    for payload in payloads:
        data = {
            'username': payload,
            'password': 'password'
        }
        response = requests.post(url, data=data)
        if "Welcome" in response.text or response.status_code == 200:
            print(f"Potential SQL Injection vulnerability detected with payload: {payload}")
        else:
            print(f"Payload {payload} did not succeed.")
                        
# Run the test
test_sql_injection(url, payloads)
                    

The script defines the URL of the web application's login endpoint and a list of common SQL injection payloads. The test_sql_injection function iterates over each payload, sends it to the login endpoint, and checks the response.

If the response indicates a successful login by containing "Welcome" in the response text or returning a 200 status code, it flags the payload as potentially causing an SQL injection vulnerability. This example demonstrates how QA engineers can automate the testing for SQL injection vulnerabilities by sending various malicious inputs to a web application's endpoint and analyzing the responses. By regularly performing such tests, we can identify and address injection flaws, enhancing the security of our application.

A04:2021-Insecure Design

Insecure design refers to security vulnerabilities that arise from inadequate or flawed design decisions made during the development of an application. Unlike implementation bugs, these issues stem from fundamental weaknesses in the application's architecture, design patterns, or overall security posture. Insecure design encompasses a broad range of issues, such as lack of threat modeling, poor data validation strategies, inadequate authentication mechanisms, and insufficient error handling.

Impact of Design Flaws on Security:

Design flaws can have severe consequences, including:

• Data Breaches: Insecure design can expose sensitive data to unauthorized access.
• Authentication Bypass: Flawed authentication mechanisms can allow attackers to gain unauthorized access to the system.
• Denial of Service: Poorly designed systems can be exploited to disrupt service availability.
• Privilege Escalation: Inadequate access controls can enable attackers to elevate their privileges within the application.

Testing Strategy:

A general approach for identifying and mitigating design flaws includes:

• Threat Modeling: Use threat modeling techniques to identify potential security threats and design flaws early in the development process.
• Secure Design Principles: Apply secure design principles, such as least privilege, defense in depth, and secure by default.
• Design Reviews: Conduct regular design reviews with security experts to assess and improve the security posture of the application.
• Security Requirements: Define and enforce security requirements throughout the software development lifecycle.
• Use of Secure Frameworks: Leverage secure frameworks and libraries that provide built-in security features and best practices.

Code Example:

Since insecure design is more about the architectural and design level rather than specific code implementations, a conceptual example using a threat modeling tool can be highly effective. Below is an example of how to use the Microsoft Threat Modeling Tool to identify and mitigate design flaws:

Conceptual Example Using Microsoft Threat Modeling Tool:

• Identify Assets: List all critical assets in your application, such as databases, user credentials, and sensitive data.
• Create a Data Flow Diagram (DFD): Use the tool to create a DFD that represents the flow of data through your application, highlighting trust boundaries.
• Identify Threats: Use the built-in STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to identify potential threats for each component in the DFD.
• Document Mitigations: For each identified threat, document potential mitigations and design changes required to address the threat.
• Review and Iterate: Regularly review and update the threat model as the application evolves to ensure ongoing security.

The Microsoft Threat Modeling Tool provides a structured approach to identifying and mitigating design flaws by visually representing the application's architecture and potential threats. By regularly using threat modeling techniques and incorporating security considerations into the design phase, we can proactively address design-related vulnerabilities and enhance the overall security of our application.

A05:2021-Security Misconfiguration

Security misconfiguration refers to improper configuration of security settings in applications, servers, databases, or frameworks. These misconfigurations can leave systems vulnerable to attacks by providing attackers with unnecessary access or exposing sensitive information. Common misconfigurations include default credentials, unpatched systems, overly permissive permissions, and exposed debug or error messages.

Common Misconfigurations and Their Effects:

• Default Credentials: Using default usernames and passwords can allow attackers to easily gain access to systems.
• Unpatched Systems: Failure to apply security patches can leave systems exposed to known vulnerabilities.
• Overly Permissive Permissions: Granting excessive permissions can enable unauthorized access to sensitive data or system functions.
• Exposed Debug/Error Messages: Displaying detailed error messages can provide attackers with valuable information about the system.

Testing Strategy:

A general approach for testing for misconfigurations includes:

• Automated Scanning: Use automated tools to scan for common misconfigurations and vulnerabilities.
• Manual Verification: Manually verify security settings to ensure they adhere to best practices.
• Configuration Management: Implement configuration management processes to maintain secure configurations across environments.
• Regular Audits: Conduct regular security audits to identify and remediate misconfigurations.
• Hardening Guides: Follow hardening guides and security benchmarks to configure systems securely.

Code Example:

Using Python to check for common misconfigurations such as default credentials, directory listing, and HTTP headers.

                                     
import requests

# Base URL for the web application
base_url = 'http://example.com/'
                        
# List of URLs to test for directory listing and headers
urls = [
    base_url,
    base_url + 'admin/',
    base_url + 'config/'
]
                        
# Default credentials to test
default_credentials = [
    ('admin', 'admin'),
    ('root', 'root'),
    ('admin', 'password'),
    ('user', 'user')
]
                        
# Function to check for directory listing
def check_directory_listing(url):
    response = requests.get(url)
    if 'Index of /' in response.text:
        print(f'Directory listing enabled on: {url}')
    else:
        print(f'Directory listing not enabled on: {url}')
                        
# Function to check for default credentials
def check_default_credentials(base_url, creds):
    login_url = base_url + 'login'
    for username, password in creds:
        response = requests.post(login_url, data={'username': username, 'password': password})
        if response.status_code == 200 and 'Welcome' in response.text:
            print(f'Default credentials work on {base_url} with username: {username} and password: {password}')
        else:
            print(f'Default credentials failed on {base_url} with username: {username} and password: {password}')
                        
# Function to check for overly permissive headers
def check_headers(url):
    response = requests.get(url)
    if 'X-Frame-Options' not in response.headers:
        print(f'Missing X-Frame-Options header on: {url}')
    if 'Content-Security-Policy' not in response.headers:
        print(f'Missing Content-Security-Policy header on: {url}')
    if 'X-XSS-Protection' not in response.headers:
        print(f'Missing X-XSS-Protection header on: {url}')
                        
# Run tests
print(f'\nTesting Base URL for Default Credentials: {base_url}')
check_default_credentials(base_url, default_credentials)
                        
for url in urls:
    print(f'\nTesting URL: {url}')
    check_directory_listing(url)
    check_headers(url)
                    

The script defines a base URL for the web application and a list of additional URLs to test for directory listing and security headers. It includes a function to check if directory listing is enabled by looking for the "Index of /" text in the response. Another function tests default credentials on the base URL's login endpoint, verifying if any common default credentials allow successful login. The script also checks for the presence of critical security headers like X-Frame-Options, Content-Security-Policy, and X-XSS-Protection in each URL's response.

Conclusion

In this blog post, we explored the importance of web application security and focused on automated testing strategies for the first five vulnerabilities in the OWASP Top 10. We discussed how each vulnerability can impact our application, provided general approaches for testing them, and shared code examples to help you get started with automation.

Regularly testing for these vulnerabilities will help you identify and address security issues early, ultimately enhancing the security posture of your web applications. Start by customizing the provided code examples to fit your specific needs and continuously refine your testing strategies.

If you'd like to try out the code examples, I've added modified versions targeting the OWASP Juice Shop web application to our GitHub page.

Stay tuned for the next post in this series, where we will cover the remaining five vulnerabilities in the OWASP Top 10.