Identifying & Fixing Common Python 3 Vulnerabilities

Identifying & Fixing Common Python 3 Vulnerabilities

Overview

In this tutorial, we will:

1. Present a sample Python function that contains multiple security flaws.

2. Identify and explain each flaw.

3. Fix the issues with secure code.

4. Provide tips and best practices throughout.

By the end, you’ll better understand why each vulnerability is risky and how to handle user inputs, secrets, and subprocess calls in Python 3 safely.

Step 1: Examine the Insecure Code

Let’s start with a small Python file (insecure_app.py) that contains four separate vulnerabilities. Read through the code and see if you can spot the issues before we break them down.

Quick Observations

• The function uses eval(), constructs raw SQL queries with user inputs, and calls external commands without sanitizing.

• There’s a hardcoded secret key, which should never be committed to source control.

• It also uses yaml.load with a full loader, which could be risky for untrusted data.

Step 2: Identify the Vulnerabilities

Let’s take each issue in turn.

1. Hardcoded Secret Key

   • What’s Wrong? Storing secrets (API keys, passwords, tokens) directly in code is a major risk. If your repository is leaked or compromised, attackers gain immediate access to these credentials.

   • Threat: Credential theft, unauthorized access.

2. Arbitrary Code Execution via eval()

   • What’s Wrong? eval() will execute any string as Python code, giving attackers a direct path to run arbitrary commands (remote code execution, RCE).

   • Threat: Full system compromise, data exfiltration, pivot to other services.

3. SQL Injection

   • What’s Wrong? Concatenating user input directly into SQL allows attackers to modify or completely alter database queries.

   • Threat: Data leaks, table deletion, privilege escalation.

4. Insecure Subprocess Call

   • What’s Wrong? If untrusted user input is passed to commands, attackers can manipulate arguments to execute arbitrary shell commands, especially if combined with shell metacharacters.

   • Threat: Arbitrary command execution, data destruction.

(Bonus: Insecure YAML Loading)

• Using yaml.load with the default loader (or yaml.FullLoader) can lead to object deserialization attacks if the input is fully untrusted. Best to use yaml.safe_load or a restricted schema.

Step 3: Secure the Code (Line by Line)

Below is the corrected version of the same function. We’ll walk through each change and explain how it fixes the vulnerabilities.

Explanation of Fixes

1. Secret Key Management

   • Before: SECRET_KEY = "mysecret123"

   • After: SECRET_KEY = os.environ.get("SECRET_KEY")

   • How it Helps: Environment variables keep secrets out of the codebase. In a real environment, use a secrets manager or secure vault.

2. Replacing eval()

   • Before: result = eval(user_input)

   • After: numeric_value = int(user_input) (or any safe parsing method)

   • How it Helps: We no longer allow arbitrary code execution. If you need to evaluate expressions, consider using a well-reviewed sandbox or a restricted parser.

3. Parameterized SQL Queries

   • Before: query = "SELECT * FROM users WHERE name = '" + user_input + "';"

   • After: query = "SELECT * FROM users WHERE name = ?;" (then cursor.execute(query, (user_input,)))

   • How it Helps: This ensures user input is passed as a parameter, preventing injection of malicious SQL commands.

4. Securing Subprocess Calls

   • Before: subprocess.run(["/bin/echo", "Received:", user_input])

   • After: Sanitizing user_input with replace(), then passing sanitized_input instead.

   • How it Helps: Reduces risk of shell metacharacters. In production, consider robust whitelisting or a library that properly escapes arguments.

5. Safe YAML Loading

   • Before: yaml.load(..., Loader=yaml.FullLoader)

   • After: yaml.safe_load(...)

   • How it Helps: Prevents arbitrary object construction or code execution from malicious YAML.

Step 4: Testing & Verification

1. Static Analysis

   • Tools like Bandit can help you catch uses of eval(), unsafe subprocess calls, and other known risky patterns.

   • Example command:

2. Dependency Scanning

   • Check for outdated or vulnerable libraries with pip-audit, Snyk, or Safety.

   • Example command:

3. Manual Testing

   • Pass different inputs (including malicious ones like "; DROP TABLE users;") to ensure your code behaves safely.

Recap & Best Practices

• Hardcoded secrets are never a good idea. Use environment variables or a vault service.

• Avoid eval() and other dangerous functions (exec(), pickle for untrusted data).

• Always parameterize SQL queries to stop injection attacks.

• Validate or sanitize user input before passing it to external commands (subprocess).

• Prefer yaml.safe_load over yaml.load for untrusted YAML data.

By following these secure coding patterns, you significantly reduce the risk of remote code execution, data breaches, and injection attacks. Integrate static analysis and dependency audits into your development pipeline, and keep an eye on your logs for suspicious behavior.

Pro Tip: Set up continuous integration (CI) to automatically run Bandit (or similar tools) on every pull request, ensuring new insecure patterns are caught early.

Final Thoughts

In this tutorial, we walked through a single function demonstrating multiple security weaknesses commonly found in Python 3 code. By removing hardcoded secrets, eliminating eval(), parameterizing SQL queries, sanitizing subprocess calls, and loading YAML safely, we mitigate the most critical vulnerabilities.

Adopt these best practices in your own projects to maintain a robust security posture. Feel free to share this guide with your team, or use it as a checklist during code reviews. Staying vigilant about security from day one can save you from costly incidents in the future!