During a penetration test, you find a login form vulnerable to CSRF. What is your next step?

Question

Options

• ATest if session cookies are protected with the SameSite attribute
• BFlood the login endpoint with requests
• CCreate a phishing attack against the login page
• DInject SQL commands into the login form

• A
  78% (43)
• B
  5% (3)
• C
  4% (2)
• D
  13% (7)

Explanation

When a login form is vulnerable to CSRF, the natural next step is to investigate what mitigations are (or aren't) in place - and the SameSite cookie attribute is the primary browser-level defense against CSRF, so testing whether it's properly set (option A) directly validates the scope and impact of the vulnerability.

Why the distractors are wrong:

• B (flood with requests) describes a DoS/brute-force attack, which is a different vulnerability class entirely - not a CSRF follow-up.
• C (phishing attack) is a social engineering tactic outside the technical scope of CSRF exploitation and typically out of scope for a standard pentest without explicit authorization.
• D (SQL injection) targets a completely different vulnerability in a different input vector; CSRF and SQLi are unrelated attack surfaces.

Memory tip: Think "CSRF = Cross-Site Request Forgery" - the browser is the weapon. SameSite is the cookie attribute that tells the browser not to send cookies on cross-site requests, so it's the direct countermeasure. If SameSite is missing or set to None, the CSRF attack remains viable; if it's Strict or Lax, the attack is blocked. Always follow a CSRF finding by checking whether the browser-level guard exists.

No community discussion yet for this question.