PentestForge

Local vulnerability analysis lab · 6 guided exercises · localhost only

PentestForge is a localhost-only learning project focused on understanding six web vulnerability classes. It documents how each issue can be reproduced in a controlled lab, where the security check is missing, what the impact is, and how a focused fix is verified. The lab/idor branch contains the intentionally vulnerable exercises; lab/solutions contains their remediations and regression tests. main remains unchanged.

Project scope: The technology store is a deliberately simple target for the exercises, not a production e-commerce product or a showcase of advanced full-stack engineering. The portfolio evidence is the vulnerability analysis, safe reproduction, remediation, and test results.

Short CV description: PentestForge is a local security-learning lab for documenting and reproducing six web vulnerability classes, explaining their root causes and impact, and verifying focused remediations with regression tests.

Lab walkthrough

▶ Watch the original 23-second walkthrough (MP4)
_{The GIF is a short looping preview. Click it to open the original video, included unchanged.}

Supporting lab interface

The interface provides context for the exercises. It is intentionally secondary to the vulnerability notes and verification evidence.

Storefront · Cửa hàng	Product detail · Trang chi tiết sản phẩm
LAB-06 SSRF · Bài thực hành SSRF có kiểm soát

Requirements

• Windows 11 with Docker Desktop and the WSL2 engine
• Linux with Docker Engine and the Docker Compose v2 plugin
• Docker Compose v2
• PowerShell on Windows, or Bash on Linux

The app is published on 127.0.0.1:8000. PostgreSQL is reachable only by services on the private Compose network.

Linux users who need Docker can follow the official Docker Engine installation guide for their distribution and the Compose plugin guide. Verify the setup with docker compose version.

Start the lab

From PowerShell in this repository:

Copy-Item .env.example .env

Edit .env and set a long random POSTGRES_PASSWORD and SECRET_KEY (at least 32 characters). Then build and start the containers:

docker compose up --build -d
docker compose logs -f web db ssrf-target

On Linux, open a Bash terminal in the repository. If you do not already have a .env file, create it with restricted permissions. Generate a value for each secret with the Python command, then paste both values into .env:

umask 077
cp .env.example .env
python3 -c 'import secrets; print(secrets.token_urlsafe(32))'
nano .env
docker compose up --build -d
docker compose logs -f web db ssrf-target

Use one generated value for POSTGRES_PASSWORD and another for SECRET_KEY. If you already have a .env, edit it in place and keep its existing values; do not copy over it.

Seed the fictional product catalog:

docker compose exec web python -m app.seed

Open http://127.0.0.1:8000. Create a normal user account to place demo orders. Registration does not allow users to choose an admin role.

Stop the app and database while keeping saved data:

docker compose down

To also erase the database volume and all local orders/accounts, run docker compose down -v.

Security learning scope

• Six documented vulnerability classes: IDOR, SQL Injection, Stored XSS, Mass Assignment, Path Traversal, and constrained SSRF.
• Two branches for comparison: vulnerable behavior on lab/idor and focused fixes on lab/solutions.
• Each guide explains the affected flow, cause, safe local reproduction, observed result, and remediation.
• Regression tests check the vulnerable behavior is blocked while the legitimate flow still works.
• Docker Compose, Alembic, and GitHub Actions make the exercises repeatable; they support the lab rather than define its portfolio focus.
• The e-commerce routes and UI are a small fictional target with demo data only.

See docs/architecture.md for the request flow and the guides for LAB-01 IDOR, LAB-02 SQL Injection, LAB-03 Stored XSS, LAB-04 Mass Assignment, LAB-05 Path Traversal, and LAB-06 SSRF.

Lab map

Lab	Issue demonstrated on lab/idor	Evidence on lab/solutions	Guide
LAB-01 · IDOR	Changing order_id exposes another user's order.	Other user gets 404; owner gets 200.	Guide
LAB-02 · SQL Injection	Search input changes SQL query meaning.	SQL-like text stays data; normal search works.	Guide
LAB-03 · Stored XSS	Stored review markup is interpreted by the browser.	Review is escaped; CSP blocks inline scripts.	Guide
LAB-04 · Mass Assignment	Client changes the account role.	Role remains server-managed; profile fields still update.	Guide
LAB-05 · Path Traversal	A path escapes the public download directory.	Public file works; paths outside it return 404.	Guide
LAB-06 · SSRF	Client influences the server-side request destination.	Destination stays fixed to the internal mock service.	Guide

Suggested learning path

To study the original issue and compare the fix, inspect the vulnerable flow on lab/idor, then switch to lab/solutions and run the matching regression test. Each guide identifies the affected route, the vulnerable branch behavior, and the proof expected from the fixed branch. Use disposable accounts and fictional data throughout.

Branch scope

• main remains the original foundation branch and is not changed by this work.
• lab/idor preserves all six intentionally vulnerable training exercises. Keep it separate from main and run it only on localhost.
• lab/solutions contains the fixed implementation for all six labs and regression tests for the security properties listed above.

GitHub Actions runs Ruff linting, a pip-audit dependency check, and Docker Compose integration tests on a fresh database. The solution tests prove the six listed regression cases and core user flows; CI is not a security certification or deployment approval.

Local security notes

Use fake data only. lab/solutions contains the remediations; lab/idor contains intentional vulnerabilities (IDOR, SQL Injection, Stored XSS, Mass Assignment, Path Traversal, and constrained SSRF). Run the vulnerable branch only on localhost; never expose its port or deploy it on a public network. Keep .env private. The session cookie uses HTTP for this loopback-only setup, so do not reuse this configuration for an internet-facing deployment. Alembic applies schema revisions in a one-shot Compose service before the web app starts.

See SECURITY.md for the training scope and guidance on reporting issues outside the documented labs. Product image credits are listed in IMAGE-CREDITS.md.

Useful commands

docker compose ps
docker compose logs --tail=100 web db ssrf-target
docker compose exec web python -m app.seed
docker compose exec web python -m unittest discover -s tests -v
docker compose down

The automated checks exercise all six remediations and core HTTP flows. They use temporary accounts and restore test-created orders, reviews, and product stock when they finish.

---

Tiếng Việt

PentestForge là dự án học tập chạy trên localhost, tập trung vào sáu nhóm lỗ hổng web. Tài liệu giải thích cách tái hiện trong lab cô lập, vị trí thiếu kiểm soát, tác động và cách xác minh bản sửa. Nhánh lab/idor giữ các tình huống cố ý dễ tổn thương; lab/solutions có bản khắc phục và regression tests. Nhánh main không bị thay đổi.

Phạm vi project: Cửa hàng công nghệ là mục tiêu mô phỏng đơn giản để tạo luồng kiểm thử, không phải sản phẩm thương mại hay minh chứng về năng lực full-stack chuyên sâu. Phần thể hiện chính là phân tích lỗ hổng, tái hiện an toàn, giải thích tác động và kiểm chứng biện pháp khắc phục.

Mô tả ngắn cho CV: Dự án lab cục bộ để tìm hiểu và tái hiện có kiểm soát sáu nhóm lỗ hổng web, giải thích nguyên nhân/tác động và kiểm tra các bản khắc phục bằng regression tests.

Video giới thiệu

▶ Xem video giới thiệu PentestForge dài 23 giây. GIF xem trước ở phần Lab walkthrough tự phát lặp lại; nhấn vào GIF để mở MP4 gốc được giữ nguyên.

Giao diện chỉ làm nền cho bài lab. Xem thêm ảnh trang chủ, trang chi tiết sản phẩm và màn hình lab SSRF.

Yêu cầu

• Windows 11 với Docker Desktop và WSL2
• Linux có Docker Engine và plugin Docker Compose v2
• Docker Compose v2
• PowerShell trên Windows hoặc Bash trên Linux

Ứng dụng chỉ được mở tại 127.0.0.1:8000. PostgreSQL chỉ được các dịch vụ trong mạng riêng của Compose truy cập.

Nếu dùng Linux và chưa cài Docker, hãy xem hướng dẫn cài Docker Engine cho bản phân phối đang dùng và hướng dẫn cài plugin Compose. Kiểm tra bằng lệnh docker compose version.

Khởi động phòng thực hành

Mở PowerShell tại thư mục repository:

Copy-Item .env.example .env

Sửa .env, đặt POSTGRES_PASSWORD và SECRET_KEY ngẫu nhiên, đủ dài (ít nhất 32 ký tự). Sau đó dựng và khởi động container:

docker compose up --build -d
docker compose logs -f web db ssrf-target

Nếu dùng Linux, mở Bash tại thư mục repository. Nếu chưa có .env, tạo tệp với quyền truy cập hạn chế. Chạy lệnh Python bên dưới hai lần để tạo hai secret riêng, sau đó dán chúng vào .env:

umask 077
cp .env.example .env
python3 -c 'import secrets; print(secrets.token_urlsafe(32))'
nano .env
docker compose up --build -d
docker compose logs -f web db ssrf-target

Dùng một secret cho POSTGRES_PASSWORD và secret còn lại cho SECRET_KEY. Nếu đã có .env, hãy sửa tệp hiện tại và giữ nguyên các giá trị đang dùng; không chép đè lên tệp đó.

Tạo dữ liệu sản phẩm giả lập:

docker compose exec web python -m app.seed

Mở http://127.0.0.1:8000 và đăng ký tài khoản người dùng để đặt đơn hàng demo. Biểu mẫu đăng ký không cho phép chọn role admin.

Dừng ứng dụng và cơ sở dữ liệu mà vẫn giữ dữ liệu đã lưu:

docker compose down

Để xóa cả volume cơ sở dữ liệu cùng tài khoản và đơn hàng cục bộ, chạy docker compose down -v.

Trọng tâm học bảo mật

• Sáu chủ đề: IDOR, SQL Injection, Stored XSS, Mass Assignment, Path Traversal và SSRF có giới hạn.
• Hai nhánh để so sánh: hành vi dễ tổn thương ở lab/idor; bản khắc phục ở lab/solutions.
• Mỗi hướng dẫn mô tả luồng bị ảnh hưởng, nguyên nhân, cách tái hiện an toàn, kết quả quan sát và hướng sửa.
• Regression tests xác nhận hành vi nguy hiểm bị chặn trong khi chức năng hợp lệ vẫn hoạt động.
• Docker Compose, Alembic và GitHub Actions giúp dựng lại môi trường và kiểm tra nhất quán; đây là công cụ hỗ trợ bài lab, không phải trọng tâm portfolio.
• Cửa hàng, tài khoản, sản phẩm và đơn hàng đều là dữ liệu giả trong ứng dụng mô phỏng tối giản.

Xem docs/architecture.md để tìm hiểu luồng yêu cầu và các hướng dẫn LAB-01 IDOR, LAB-02 SQL Injection, LAB-03 Stored XSS, LAB-04 Mass Assignment, LAB-05 Path Traversal và LAB-06 SSRF.

Bản đồ lab

Lab	Tình huống trên lab/idor	Bằng chứng trên lab/solutions	Hướng dẫn
LAB-01 · IDOR	Đổi order_id để đọc đơn của tài khoản khác.	Người khác nhận 404; chủ đơn nhận 200.	Hướng dẫn
LAB-02 · SQL Injection	Input tìm kiếm làm đổi ý nghĩa câu SQL.	Chuỗi giống SQL được coi là dữ liệu; tìm kiếm bình thường vẫn chạy.	Hướng dẫn
LAB-03 · Stored XSS	Markup trong nhận xét đã lưu được trình duyệt diễn giải.	Review được escape; CSP chặn inline script.	Hướng dẫn
LAB-04 · Mass Assignment	Client đổi trường role của tài khoản.	Role vẫn do server quản lý; trường hồ sơ hợp lệ vẫn cập nhật.	Hướng dẫn
LAB-05 · Path Traversal	Đường dẫn thoát khỏi thư mục tải công khai.	Tệp public vẫn tải được; đường dẫn ngoài thư mục trả 404.	Hướng dẫn
LAB-06 · SSRF	Client tác động URL đích mà server truy cập.	Đích được cố định ở mock service nội bộ.	Hướng dẫn

Lộ trình học gợi ý

Để hiểu nguyên nhân và biện pháp sửa, xem tình huống trên lab/idor, sau đó chuyển sang lab/solutions và chạy regression test tương ứng. Mỗi hướng dẫn nêu route bị ảnh hưởng, điều kiện dẫn đến lỗi, tác động có thể quan sát và kết quả sau khi sửa. Chỉ dùng tài khoản dùng một lần và dữ liệu giả.

Phạm vi nhánh Git

• main là nhánh nền tảng ban đầu, không được thay đổi trong phần việc này.
• lab/idor giữ cả sáu bài có lỗ hổng cố ý. Tách nhánh này khỏi main và chỉ chạy trên localhost.
• lab/solutions chứa bản khắc phục cho sáu lab cùng regression tests xác nhận các điều kiện bảo mật.

GitHub Actions chạy Ruff, pip-audit và integration tests Docker Compose với database mới. Test của nhánh solutions xác nhận sáu trường hợp hồi quy cùng các luồng cơ bản; CI không phải chứng nhận bảo mật hay phê duyệt triển khai.

Lưu ý bảo mật

Chỉ sử dụng dữ liệu giả. lab/solutions chứa các bản khắc phục; lab/idor chứa lỗ hổng cố ý (IDOR, SQL Injection, Stored XSS, Mass Assignment, Path Traversal và SSRF có giới hạn). Chỉ chạy nhánh lab dễ tổn thương trên localhost; không mở cổng ra mạng công cộng. Giữ riêng tư tệp .env. Cookie Session dùng HTTP vì ứng dụng chỉ lắng nghe trên loopback; không dùng lại cấu hình này cho dịch vụ hướng Internet. Alembic quản lý schema; service migrate áp dụng các revision trước khi web khởi động.

Xem SECURITY.md để biết phạm vi bài thực hành và cách báo cáo vấn đề nằm ngoài các lab đã công bố. Nguồn ảnh sản phẩm được ghi tại IMAGE-CREDITS.md.

Thuật ngữ bảo mật

• Authentication (xác thực): kiểm tra danh tính người đăng nhập.
• Authorization (phân quyền): quyết định danh tính đó được phép làm gì.
• Session (phiên đăng nhập): trạng thái đăng nhập được duy trì giữa các yêu cầu.
• Ownership check (kiểm tra quyền sở hữu tài nguyên): xác nhận tài nguyên như đơn hàng thuộc về người dùng hiện tại.
• CSRF (Cross-Site Request Forgery – giả mạo yêu cầu liên trang): kiểu tấn công khiến trình duyệt gửi yêu cầu ngoài ý muốn bằng phiên đăng nhập của người dùng.
• IDOR (Insecure Direct Object Reference – tham chiếu trực tiếp đối tượng không an toàn): lỗi phân quyền khi đổi mã định danh cho phép truy cập tài nguyên của người khác. LAB-01 cho thấy lỗi ở lab/idor; lab/solutions kiểm tra Ownership check trong truy vấn.
• SQL Injection (SQLi – chèn mã SQL): xảy ra khi input người dùng bị ghép vào cú pháp SQL. LAB-02 được giữ trong lab/idor; bản solutions dùng bind parameter.
• Stored XSS (Cross-Site Scripting lưu trữ): nội dung người dùng lưu lại rồi được trình duyệt diễn giải như HTML/JavaScript. LAB-03 được giữ trong lab/idor; bản solutions escape nội dung và giữ CSP nghiêm ngặt.
• Mass Assignment (gán hàng loạt thuộc tính): server gán trường client gửi vào model mà không bảo vệ trường đặc quyền. LAB-04 được giữ trong lab/idor; bản solutions chỉ cập nhật trường hồ sơ cho phép.
• Path Traversal (duyệt đường dẫn): thao túng đường dẫn, thường bằng ../, để đọc ngoài thư mục dự kiến. LAB-05 được giữ trong lab/idor; bản solutions giới hạn đường dẫn ở thư mục public.
• SSRF (Server-Side Request Forgery – giả mạo yêu cầu phía máy chủ): khiến server gửi yêu cầu tới dịch vụ client không truy cập trực tiếp. LAB-06 có allowlist giới hạn trên lab/idor; lab/solutions dùng URL nội bộ cấu hình sẵn, không nhận URL từ client.

Lệnh thường dùng

docker compose ps
docker compose logs --tail=100 web db ssrf-target
docker compose exec web python -m app.seed
docker compose exec web python -m unittest discover -s tests -v
docker compose down

Bộ kiểm thử tự động gọi ứng dụng HTTP cục bộ và kiểm tra sáu bản khắc phục cùng các luồng cơ bản. Bộ kiểm thử tạo tài khoản tạm thời, sau đó dọn đơn hàng, nhận xét và hoàn lại tồn kho do kiểm thử tạo ra.