CyberSec Lab — CSRF: HarborLine Credit Union

OBJECTIVES

Explore the target application

Locate a state-changing function

Analyse the HTTP request structure

Review the page source for missing controls

Craft a working proof-of-concept

Understand and document the defences

Capture the flag

Submit the pentest finding

🌐

Browser

⚗️

PoC Editor

🛡️

Defences

📖

Reference

📋

Report

HARD ⭐⭐⭐⭐ — CSRF ASSESSMENT

CSRF LAB — HARBORLINE CREDIT UNION

TARGET: banking.harborline-cu.com (simulated)

SCENARIO

You are conducting a white-box web application penetration test against HarborLine Credit Union. The client has provided test credentials and asked you to evaluate the security of their online banking platform. You are authenticated as test user jason.mercer@harborline-cu.com.

Identify, demonstrate, and document any CSRF vulnerabilities you find. No hints will be provided — work through it as you would a real engagement.

ENGAGEMENT DETAILS

Item	Detail
Target	banking.harborline-cu.com
Test user	jason.mercer@harborline-cu.com
Account	HL-772041
Balance	$8,320.50
Scope	Authenticated web application features
Difficulty	Hard — no guided hints

DELIVERABLE

A documented finding with: vulnerability type, severity, CVSS v3.1 vector string (not just a score), vulnerable endpoint, proof-of-concept HTML, attack scenario, business impact, and specific remediation. The flag is unlocked by crafting a valid PoC.

Display Mode

BROWSER — HarborLine Credit Union

🔒 banking.harborline-cu.com/dashboard

HarborLine — Dashboard

Bill Payment

Wire Transfer

Page Source

HTTP Request

PoC EDITOR

REFERENCE — CSRF

CSRF MECHANICS

A CSRF attack tricks a victim's browser into making an unwanted request to a site they're authenticated with. Because browsers automatically include session cookies, the server treats the forged request as legitimate — unless the application implements anti-CSRF controls.

WHAT TO LOOK FOR

In page source: state-changing forms that lack a hidden CSRF token field.

In HTTP requests: POST bodies that contain only predictable parameters — no random token.

In cookies: session cookies with no SameSite attribute.

In response headers: no validation of Origin or Referer headers server-side.

CVSS v3.1 VECTOR NOTATION

AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N AV = Attack Vector (N=Network) AC = Attack Complexity (L=Low) PR = Privileges Required(N=None) UI = User Interaction (R=Required) S = Scope (U=Unchanged) C = Confidentiality (H=High) I = Integrity (H=High) A = Availability (N=None)

PoC REQUIREMENTS

A valid CSRF PoC must: target the exact vulnerable endpoint, use the correct HTTP method, include all required parameters, and auto-submit without any victim interaction (other than visiting the page). A victim clicking a button does not meet the standard — use onload.

REMEDIATION EXPECTATIONS

Name the specific defence mechanism, the implementation location (server-side form generation, cookie attributes, middleware), and an appropriate remediation timeline based on severity.

PENTEST REPORT — HarborLine CSRF Finding

CSRF VULNERABILITY — FINDING DOCUMENTATION

🚩 FLAG:

VULNERABILITY TYPE

SEVERITY

CVSS v3.1 VECTOR STRING (full vector required)

VULNERABLE ENDPOINT (full path)

ROOT CAUSE — what protection is absent?

ATTACK SCENARIO

BUSINESS IMPACT

REMEDIATION (specific — name the mechanism and implementation)

Score: 0 / 8