DEV Community: Zeyrian Faris

Testing fourpointo Against Malicious Uploads: Prompt Injection and Stored XSS

Zeyrian Faris — Sun, 28 Jun 2026 12:01:29 +0000

fourpointo is a self-hosted Flask app I built that generates AI-powered task checklists and rubric breakdowns from uploaded assignment PDFs. It uses Groq's LLaMA 3.3 70B for extraction, SQLite for storage and Gunicorn behind a Cloudflare Tunnel.

After fixing a magic-byte validation bug found during normal use (a fake PDF was causing an unhandled crash in PyMuPDF), I wanted to go further and actually probe the upload pipeline the way an attacker might. This writeup documents that process: the setup, the test cases and the results.

All testing was done locally in a Kali VM against a local copy of fourpointo. No production data or other users were involved at any point.

Setup

The first step was building a valid baseline PDF to work from. A blank or garbage file wouldn't tell me anything useful since fourpointo already rejects those.

This gave me real.pdf, a small but genuinely valid PDF I could use as raw material for the rest of the testing.

Test 1: Input Validation (Magic Bytes and Content Gate)

Before testing anything more advanced, I wanted to confirm the existing validation layers actually worked. fourpointo has two gates:

A magic-byte check that rejects files that aren't structurally PDFs
A content gate (an LLM call) that rejects PDFs that don't read like an assignment specification

To test the second gate, I truncated a valid PDF so the header would pass but the internal structure would be incomplete.

Uploading the truncated file produced a clean rejection rather than a crash or a silent failure.

Result: Both gates behaved as intended. The truncated file still had a valid PDF header (since the magic bytes survive truncation) but lacked enough coherent content for the second gate to accept it, and it was rejected with a clear message instead of breaking anything downstream.

Building a Realistic Specification PDF

To test prompt injection and stored XSS properly, I needed a PDF that would actually pass the content gate, meaning it had to look like a real assignment specification with a Tasks section and a Grading Criteria section.

I wrote a small Python script using fpdf2 to generate this on demand, which also made it easy to produce variants later by editing one line at a time.

Once the script ran cleanly, I uploaded the resulting spec.pdf as a baseline with no malicious content. It passed the content gate and generated a normal checklist.

This confirmed the test harness worked end to end before introducing anything adversarial.

Test 2: Prompt Injection

fourpointo pipes extracted PDF text directly into an LLM call to generate tasks and rubric criteria. This is exactly the kind of pipeline that's vulnerable to prompt injection if the document content isn't treated as untrusted input.

Rather than using an obvious phrase like "ignore all previous instructions," I used a more disguised pattern that mimics how a real injection attempt would try to impersonate a system-level instruction embedded inside user-supplied content.

I built this into a new PDF and confirmed it was generated correctly.

After uploading it and generating the checklist, I checked the raw JSON output for the rubric extraction.

The injected text never appears anywhere in the output. The model extracted the real tasks and the real grading criteria and nothing else.

I also checked the rendered project page in the browser to confirm the same thing held true for the task list, not just the rubric.

Result: The injection attempt failed. fourpointo's extraction stayed accurate even when an instruction-like phrase was embedded directly inside the task text. It's worth noting that fourpointo's AI layer only reads and displays content. It doesn't grade anything or make decisions that affect a real outcome, so even a successful injection here would have limited impact beyond corrupting the displayed checklist. Still, this is a meaningful result because it shows the extraction step doesn't blindly follow instructions found inside untrusted document content.

Test 3: Stored XSS via PDF Content

Next, I wanted to know whether a script tag embedded inside a PDF's task text could survive the full pipeline (extraction, storage and rendering) and execute in the browser. I disguised the payload as part of a legitimate-looking task rather than dropping it in isolation, since that's closer to how a real attacker would try to slip it past a casual read.

I uploaded the resulting PDF and generated the checklist, then checked every task in the rendered UI.

No alert fired, and none of the displayed tasks contained the script tag at all. Looking at the task labels (Analyze Dataset, Write Report, Check Formatting, Create Charts, Submit Report), it's clear the AI isn't echoing the raw text back. It's paraphrasing each task into a short label before it ever reaches the frontend.

Result: No XSS was observed, but the reason matters. This wasn't a deliberate sanitization control catching the payload. It was the summarization step rewriting the content before the payload could survive long enough to be rendered. If fourpointo's prompt ever changes to extract tasks verbatim instead of summarizing them, this protection could disappear without anyone noticing. It's a real mitigation today, but not one to rely on long term.

Test 4: Stored XSS via Direct Form Input

Since the PDF-based test was inconclusive about actual output escaping (the payload never survived to be rendered), I tested the rendering layer directly by typing a script tag straight into the project name field. This field gets stored and displayed with no LLM step in between, which isolates the question of whether the frontend escapes HTML on output.

After creating the project, I checked how the name rendered on the project page and in the sidebar.

The page title and sidebar entry both showed the literal text <script>alert('XSS via project name')</script> instead of executing it.

Result: Confirmed. fourpointo properly escapes this field on render. The script tag is treated as plain text rather than executable HTML, almost certainly because the frontend rendering layer (whether that's React's default text handling or template auto-escaping) doesn't interpret stored strings as raw HTML.

One caveat worth being precise about here: since fourpointo currently has no sharing, admin view, or export feature, this would technically be self-XSS rather than exploitable stored XSS, because there's no path for the payload to reach another user's session. The mechanism is confirmed either way, and the escaping itself is a real control that would matter immediately if any multi-user-facing feature (sharing, an admin dashboard or exported reports) were added later.

Summary of Findings

Test	Result	Notes
Magic-byte validation	Pass	Rejects non-PDF files correctly
Content gate validation	Pass	Rejects structurally invalid or unconvincing specs
Prompt injection (disguised)	Pass	Injected instruction was not followed
Stored XSS via PDF content	Pass (incidental)	Payload never survived extraction due to paraphrasing, not deliberate sanitization
Stored XSS via form input	Pass (deliberate)	Output is properly HTML-escaped on render

Recommendations

Continue treating all extracted document text as untrusted input. The current prompt injection resistance held up in this round of testing, but it should be re-verified any time the extraction prompt or model changes.
Don't rely on the LLM's paraphrasing behavior as a security control against XSS. If task extraction is ever changed to preserve verbatim text, explicit output encoding should be added at that point rather than assumed.
The form-field escaping currently in place is a genuine and correct control. If sharing, an admin view or export features are added in the future, this is the exact protection that would prevent a self-XSS finding from becoming a real stored XSS affecting other users.

Conclusion

Across four separate test categories, fourpointo held up better than expected for a personal project with a small user base. Input validation correctly filters malformed and irrelevant uploads, the AI extraction layer resisted a disguised prompt injection attempt and the frontend properly escapes user-controlled output. The one point worth continued attention is that the XSS resistance in the document pipeline is currently a side effect of summarization rather than a deliberate control, which is the kind of gap that's easy to lose track of as the app evolves.

Finding a File Upload Validation Bug in My Own App

Zeyrian Faris — Wed, 24 Jun 2026 06:49:33 +0000

Context

fourpointo is a Flask app I built and self-host that takes an uploaded assignment brief (PDF or DOCX) and uses an LLM to generate a structured task checklist from it. It's a real tool I use myself, and a portfolio piece.

I've been working through TryHackMe's Jr Pentester path, and one of the labs covered exploiting an unrestricted file upload: a server that trusted a file's extension instead of its actual content, allowing a .phtml webshell to be uploaded and executed.

After finishing that lab, I wanted to check whether fourpointo had the same class of weakness. Not by reading my own source code top to bottom, but by testing it the same way I'd test someone else's app: black-box, from the outside, the way an actual attacker or reviewer would.

Setup

To test this safely, I didn't want to throw unverified payloads at my live, internet-facing instance. So I cloned fourpointo onto a separate VM, set up a fresh Python virtual environment, installed dependencies, and got a local copy running independently of production. This also surfaced an unrelated environment quirk (a database schema that had drifted out of sync between my dev machine and production), which I fixed locally but is a separate issue from what's documented here.

With a working local copy, I had an isolated sandbox to actually break things in.

Discovery

fourpointo's upload field is restricted client-side with an accept attribute limiting the file picker to PDF and DOCX. That's a UI convenience, not a security control, so the first thing worth checking is whether the server enforces the same restriction, or only the browser does.

Test 1: Renamed file with a disallowed extension

I created a harmless test file and renamed it to .phtml, then tried uploading it both through the browser's file picker and by switching the picker to "All Files." The server rejected it. Good sign, extension-based filtering was at least present.

To rule out the picker itself doing the filtering rather than the server, I also took a real PDF, renamed it to test1.phtml, and uploaded that, real PDF content, disallowed extension. Still rejected. This confirmed the rejection was happening server-side, and that it was extension-based rather than content-based, at least in this direction.

Test 2: Valid extension, invalid content

The more interesting question was whether the check went any deeper than the filename. I created a file with a .pdf extension but garbage content (fake.pdf, containing the text "not a real pdf"). I uploaded it through the normal form.

It was accepted. The server didn't reject it. The user-facing response was a generic "Something went wrong. Please try again.", but the server's own logs showed the real cause: an unhandled exception.

File "app.py", line 67, in extract_text
    doc = fitz.open(stream=file.read(), filetype="pdf")
pymupdf.mupdf.FzErrorFormat: code=7: no objects found
pymupdf.FileDataError: Failed to open stream

The relevant code, before the fix:

def extract_text(file):
    filename = file.filename
    if filename.endswith('.pdf'):
        doc = fitz.open(stream=file.read(), filetype="pdf")
        text = ""
        for page in doc:
            text += page.get_text()
        return text
    elif filename.endswith('.docx'):
        import docx
        doc = docx.Document(file)
        text = ""
        for para in doc.paragraphs:
            text += para.text + "\n"
        return text
    else:
        return None

The validation logic only checks whether the filename string ends in .pdf or .docx. Nothing inspects the actual bytes of the file before handing it to PyMuPDF to parse as a real PDF. The library itself caught the mismatch, but by then the request had no graceful way to fail, so it crashed instead of returning a clean error.

Separately, the upload route saved the file to disk before any of this validation ran, meaning even a rejected file would already be written to static/uploads/ first.

Impact

It's worth being precise about what this bug does and doesn't allow, rather than overstating it.

This is not remote code execution. Unlike the THM lab that inspired this test, fourpointo runs on Flask and Gunicorn, with no PHP interpreter in the stack, so a disguised file extension has no path to being executed as code on the server.

What it does demonstrate:

Insufficient input validation. The check trusts the filename over the actual content, the same root cause as the lab's .phtml bypass, just without that bypass's consequence here.
Missing error handling around a fallible operation. A malformed file causes an unhandled exception. The user only saw a generic "Something went wrong. Please try again." rather than the underlying error, but the full traceback, including internal file paths, was written to the server's own logs. A clean rejection should have been possible at the validation layer instead of relying on a catch-all handler further up the stack.
Unvalidated files were written to disk before being checked. A rejected upload still left a file behind.

I tested whether this could escalate into a denial-of-service condition by checking if the crash brought down the whole server process or just the single request. After triggering the crash, the server continued responding normally to other requests immediately afterward. The impact is isolated to the failing request, not the application's overall availability.

Overall severity: low to medium. A real input validation gap with a reliability impact (an ugly failure mode for users), not a security compromise.

The Fix

Two changes, both in the file-handling logic.

Magic byte verification before parsing. Real PDF files begin with the bytes %PDF-. Real DOCX files (which are ZIP archives internally) begin with PK\x03\x04. Checking these few bytes before attempting to parse the file catches an obviously fake file immediately and cheaply:

def extract_text(file):
    filename = file.filename

    if filename.endswith('.pdf'):
        header = file.read(5)
        file.stream.seek(0)
        if header != b'%PDF-':
            return None

        try:
            doc = fitz.open(stream=file.read(), filetype="pdf")
            text = ""
            for page in doc:
                text += page.get_text()
            return text
        except Exception:
            return None

    elif filename.endswith('.docx'):
        header = file.read(4)
        file.stream.seek(0)
        if header != b'PK\x03\x04':
            return None

        try:
            import docx
            doc = docx.Document(file)
            text = ""
            for para in doc.paragraphs:
                text += para.text + "\n"
            return text
        except Exception:
            return None

    else:
        return None

Error handling around the actual parse. Even a file that passes the magic byte check could still be corrupted or malformed internally. Wrapping the parsing call in a try/except means that case fails the same clean way, returning None rather than propagating an unhandled exception.

One side effect worth noting: extract_text now returns None for two different reasons, an unsupported extension, or a supported extension with content that fails the magic byte check, and the route can't tell which happened. Both currently surface as "Unsupported file type," which is accurate for the first case but a little misleading for the second, since the file's extension was actually fine. A more precise message ("This file doesn't appear to be a valid PDF") would better reflect what actually failed, though it doesn't affect the security or reliability of the fix itself.

Validate before writing to disk. The upload route previously saved the file before checking if extract_text could read it. Reordering this means a rejected file never touches disk in the first place:

filename = f"{uuid.uuid4()}_{pdf.filename}"

text = extract_text(pdf)
if text is None:
    return {"error": "Unsupported file type. Please upload a PDF or DOCX."}, 400

upload_folder = os.path.join('static', 'uploads')
os.makedirs(upload_folder, exist_ok=True)
filepath = os.path.join(upload_folder, filename)
pdf.stream.seek(0)
pdf.save(filepath)

After this fix, re-uploading fake.pdf returns a clean response instead of a crash:

Unsupported file type. Please upload a PDF or DOCX.

I also re-tested the original .phtml upload attempt to confirm the fix didn't change behavior there. It was still rejected, as before.

Takeaway

The THM lab's lesson, that a file's claimed type and its actual content are two different things, applies just as directly to my own code as it does to a deliberately vulnerable training box. The difference here wasn't the size of the consequence, it was that nobody had asked the question yet.

Testing your own projects the same way you'd test someone else's, without reading the source first to confirm your assumptions, is a genuinely useful habit. It catches the gap between what you assume your code does and what it actually does.

I Found a Source Code Disclosure Bug in My Own Flask App With Gobuster

Zeyrian Faris — Sat, 20 Jun 2026 03:03:44 +0000

Context

I'm a first-year Cybersecurity and Digital Forensics student, currently working through TryHackMe's Jr Pentester path. While practicing directory enumeration with gobuster, I had an idea: rather than only running it against lab targets, why not point it at something I actually built and care about?

That something is fourpointo. It Flask app I'm developing that generates AI task lists and rubric breakdowns from uploaded assignment PDFs, self-hosted on a Dell server and deployed via Cloudflare Tunnel.

I wasn't expecting to find anything. I was mostly testing whether I understood the tool. I ended up finding a real, textbook misconfiguration and figured it was worth documenting properly, both as a learning exercise and as a small case study in why this category of bug is so common.

The Setup

To do this safely, I didn't touch the live production app (fourpointo has real registered users and testing against it directly wasn't worth the risk). Instead, I cloned the public GitHub repo and ran a local dev copy on an isolated Kali VM, hitting localhost only.

I then deliberately introduced a misconfiguration I wanted to study: I copied database.py, one of the app's core server-side source files, into the static/ directory.

Why this matters: in Flask, static/ is auto-served by the framework with no route required. Anything dropped in there, intentionally or by accident, is publicly reachable. It's meant to hold CSS, JS, images: client-facing assets. Files in templates/, by contrast, are not directly reachable; they only render through actual app routes. Mixing a server-side source file into static/ blurs a trust boundary that should be kept firm.

This is a realistic mistake. It's easy to imagine a developer copying a file for a quick test, or a build script misplacing something, and forgetting to remove it before deploying.

Discovery

With the dev server running locally, I ran:

gobuster dir -u http://localhost:5000/static -w /usr/share/wordlists/dirb/common.txt -x html,htm,php,py,js,json,txt,xml,bak,old,zip,sql,env,config,yml -t 50

Output:

database.py     (Status: 200) [Size: 7739]
script.js        (Status: 200) [Size: 8746]
Progress: 73808 / 73808 (100.00%)
Finished

script.js showing up is expected as it is a legitimate static asset. database.py showing up alongside it is not.

Confirming the Finding

A 200 status from gobuster tells you a path exists and returned content but it doesn't tell you what that content is. To confirm actual impact, I pulled the file directly:

curl http://localhost:5000/static/database.py

This returned the full, raw source of database.py. No authentication, no warning, just plain text served like any other static asset.

The file contained:

Full database schema (table definitions for projects, tasks, and others, including column names and relationships)
Application logic for handling user data, including how passwords are hashed before being written to the database
Enough structural detail to understand exactly how the app's data model and core functions work, without needing to guess

To be clear: no real user data, hardcoded secrets, or API keys were exposed in this case. Fourpointo correctly keeps those in environment variables, not in source. But that's somewhat beside the point. The schema and logic disclosure alone is a meaningful leak on its own, and in a less careful codebase, this exact misconfiguration could just as easily have exposed live credentials.

Why This Matters

Source code disclosure is generally underrated as a finding because it doesn't look as dramatic as, say, SQL injection or an exposed admin panel. But it directly enables both:

Targeted attacks: knowing exact table names, column names, and queries removes the guesswork an attacker would otherwise need for SQL injection, IDOR, or logic-abuse attempts.
Reconnaissance for the next bug: reading real application logic often reveals other weaknesses (missing validation, unsafe assumptions, auth logic quirks) that would be far harder to find through black-box testing alone.

It's also a good demonstration of why directory brute-forcing matters in a real pentest. In practice you rarely know a target's folder structure in advance. You fingerprint the stack (Flask, in this case, identifiable through default error pages, cookie naming, etc.), pick a wordlist suited to that stack, and brute-force from there. Knowing Flask serves static/ by default is exactly the kind of framework-specific knowledge that turns a generic scan into a targeted one.

Remediation

The fix is straightforward: keep server-side source code out of any directory the web server treats as public:

Never place .py (or other server-side source) files inside static/
At the web server/proxy level, explicitly deny serving source file extensions as a defense-in-depth measure, e.g. for Nginx:

location ~* \.py$ {
      deny all;
  }

Periodically audit what's actually inside static/ as it's easy for stray files to accumulate over time without anyone noticing

Takeaway

The lesson that stuck with me most: a directory's purpose and a directory's actual contents can quietly drift apart, and nothing forces you to notice until someone runs a scan. Treating static/ (or any auto-served directory) as inherently safe just because of what it's meant to hold, rather than auditing what's actually in there, is exactly the kind of assumption that creates this category of bug.

Testing this against my own app, rather than only against lab targets, was a useful exercise precisely because the stakes felt real even at a small scale: this is a live app with actual users, and the same gap could plausibly have existed in production without me thinking to check.

How I self-hosted my Flask app on an old laptop for almost free

Zeyrian Faris — Mon, 25 May 2026 14:37:30 +0000

I recently built fourpointo, a Flask web app for polytechnic students to manage assignments. Once it was working locally, I needed to get it live without paying for cloud hosting every month.

Then I realised I had an old, unused laptop which I was trying to find a purpose for. I figured it would be great to use it as a home server to host my website and it saves costs.

I wiped the laptop and went with Ubuntu Server since it's lightweight and widely used. There's plenty of documentation if I got stuck.

I then cloned fourpointo from my new laptop onto my server.

When developing fourpointo, I used Python's Flask library. However, Flask's built-in server is single-threaded and not designed to handle multiple requests at once. Gunicorn is a production-grade server that runs multiple workers so it can handle real traffic.

After installing Gunicorn, I got the domain fourpointo.app from Namecheap which serves as the URL for my app.

I then used Cloudflare Tunnel because it routes traffic through Cloudflare's servers, so my home IP stays hidden rather than being exposed publicly.

One issue I ran into was fourpointo going down every time I closed the lid of my server. Then I realised the server cannot go to sleep, even if the lid is closed. So I edited a systemd script using the Command Line Interface to set it so that it doesn't go to sleep when the lid is closed.

Another issue I faced was fixing bugs and pushing updates remotely. In order to update fourpointo, I needed to SSH into the server. However, that only worked if I was on the same wifi as my server. So remote fixing was impossible. To solve this issue, I used Tailscale which acts as a bridge between my server and my laptop. Tailscale generated an IP for me to use when I want to SSH into the server remotely.

Through this experience, I learnt the basics of server and network administration using Linux. I will continue to push updates to fourpointo to enhance users' experiences and hopefully in the future, I will be able to scale the app up.