Tampering

Tampering with Data Analysis

Analyze source code for tampering threats where attackers can modify data, code, or configuration without detection. Maps to STRIDE T -- violations of the Integrity security property.

Supported Flags

Read ../../shared/schemas/flags.md for the full flag specification. This skill supports all cross-cutting flags including --scope, --depth, --severity, --format, --fix, --quiet, and --explain.

Framework Context

Read ../../shared/frameworks/stride.md, specifically the T - Tampering with Data section, for the threat model backing this analysis. Key concerns: SQL injection, parameter tampering, man-in-the-middle, file modification, configuration tampering, code injection.

Workflow

1. Determine Scope

Parse flags and resolve the target file list per the flags spec. Filter to files likely relevant to data handling:

• Database query builders and ORM usage
• API request handlers and form processors
• File upload and file write operations
• Configuration loaders and environment parsers
• Serialization/deserialization logic
• Template rendering engines
• Webhook receivers and inter-service message handlers
• Package manifests and lock files (for supply chain integrity)

2. Analyze for Tampering Threats

For each in-scope file, apply the Analysis Checklist below. At --depth standard, read each file and trace user input to data operations. At --depth deep, follow input across file boundaries through function calls, imports, and middleware chains to find indirect injection paths.

3. Report Findings

Output findings per ../../shared/schemas/findings.md using the TAMP ID prefix (e.g., TAMP-001). Set references.stride to "T" on every finding.

Analysis Checklist

Work through these questions against the scoped code. Each "yes" may produce a finding.

1. SQL injection -- Is user input concatenated or interpolated into SQL strings? Search for string formatting in query construction: f-strings, + concatenation, format(), template literals near SELECT, INSERT, UPDATE, DELETE. Even ORM raw query methods are vulnerable if they interpolate user input.
2. Command injection -- Is user input passed to shell execution functions? Look for os.system, subprocess.call with shell=True, exec(), child_process.exec, backtick execution with unsanitized input. Check if arguments are passed as arrays (safe) vs. strings (unsafe).
3. NoSQL injection -- Are user-controlled objects passed directly into MongoDB/NoSQL query operators? Look for $gt, $ne, $where, $regex coming from request bodies without schema validation or type enforcement.
4. Parameter tampering -- Are hidden form fields, cookies, or URL parameters trusted without server-side validation? Check if price, role, user ID, quantity, or discount values from the client are used directly in business logic without re-derivation from server state.
5. Missing integrity checks -- Are downloaded files, API responses, or inter-service messages consumed without HMAC, signature, or checksum verification? Look for fetch, requests.get, file reads where the content is used without hash validation. Check webhook handlers for missing signature verification.
6. Unsafe deserialization -- Is untrusted data deserialized with pickle.loads, yaml.load (without SafeLoader), unserialize(), ObjectInputStream, Marshal.load, or eval(JSON)? These can lead to remote code execution.
7. Path traversal for writes -- Can user input influence file write paths? Look for ../ or unvalidated path components in file creation, upload handling, or log file naming. Check if os.path.realpath or equivalent canonicalization is applied before writing.
8. Missing CSRF protection -- Do state-changing endpoints (POST/PUT/DELETE) lack CSRF token validation? Check for absence of CSRF middleware, @csrf_exempt on sensitive endpoints, or token verification gaps in form handlers.
9. Configuration injection -- Can environment variables, config files, or feature flags be modified through application inputs? Look for dynamic config loading from user-influenced sources, admin panels that write config without integrity checks.
10. Template injection -- Is user input rendered in server-side templates without escaping? Search for render_template_string, Jinja2 with autoescape=False, eval in template contexts, Handlebars triple-stash {{{, or Twig raw filters on user data.
11. Header injection -- Can user input be injected into HTTP response headers? Look for setHeader, res.header, response.headers where values come from request parameters, enabling response splitting or cookie injection.
12. Prototype pollution -- In JavaScript, are user-controlled objects merged unsafely? Look for Object.assign({}, userInput), _.merge, _.defaultsDeep, or spread operators on untrusted data that could set __proto__ or constructor.prototype.

Pragmatism Notes

• Not every string concatenation near SQL is injection. Check if the concatenated value is a constant, an enum, or derived from trusted server-side logic. Only flag when user input reaches the query.
• CSRF protection is less relevant for pure JSON APIs consumed by SPAs with token-based auth (Bearer tokens are not automatically attached like cookies). Focus CSRF findings on cookie-authenticated form submissions.
• Prototype pollution is JavaScript-specific. Skip this check for other language ecosystems.
• Mass assignment findings require checking the ORM's built-in protections. Many modern frameworks (Rails strong params, Django forms, Pydantic models) have allowlisting built in.

What to Look For

Concrete code patterns and grep heuristics to surface tampering risks:

• String-built queries: f"SELECT, "SELECT * FROM " +, query = "...${, .format( adjacent to SQL keywords, execute(f", .query("..."+. Grep: (execute|query|prepare)\s*\(\s*(f['"]|['"].*\+|.*format).
• Shell execution with input: os.system(, subprocess.call(.*shell=True, exec(, child_process.exec(, Runtime.getRuntime().exec(. Grep: (system|exec|popen|spawn)\s*\(.
• Unsafe deserialization: pickle.loads, yaml.load( without Loader=SafeLoader, unserialize(, readObject(, eval(.*JSON, Marshal.load. Grep: (pickle\.loads|yaml\.load|unserialize|readObject|Marshal\.load).
• Missing parameterization: Database calls using string concatenation instead of ?, $1, or %s placeholders with parameter tuples/arrays.
• No CSRF middleware: State-changing routes without csrf_protect, csurf, @csrf_exempt on sensitive endpoints, missing X-CSRF-Token header checks. Grep: csrf_exempt|csrf.*disable.
• Unvalidated file paths: os.path.join(base, user_input) without os.path.commonprefix or realpath validation, path.resolve without containment check, .. not stripped from upload filenames.
• Direct object use from request: req.body or request.json passed directly to ORM .create() or .update() without allowlist filtering (mass assignment risk). Grep: \.create\(\s*req\.body|\.update\(\s*req\.body.
• Prototype pollution vectors: _.merge(, _.defaultsDeep(, Object.assign(.*req with untrusted input. Grep: (merge|assign|extend)\s*\(.*req\.(body|query|params).

Output Format

Each finding must conform to ../../shared/schemas/findings.md.

id:          TAMP-<NNN>
severity:    critical | high | medium | low
confidence:  high | medium | low
location:    file, line, function, snippet
description: What the tampering risk is and how it could be exploited
impact:      What an attacker can modify or corrupt
fix:         Concrete remediation with diff when possible
references:
  stride: "T"
  cwe:    CWE-89 (SQLi), CWE-78 (OS Command Injection), CWE-352 (CSRF), or relevant CWE
metadata:
  tool:      tampering
  framework: stride
  category:  T

Severity Guidelines for Tampering

Common CWE References