All Projects

Description

The application is vulnerable to Cross-Site Request Forgery (CSRF) on the notification "Seen" endpoint. An attacker can craft a malicious HTML page that silently triggers the notification "seen" request from a victim's browser while the victim is authenticated.

Because the endpoint accepts the request without validating a CSRF token or verifying the request origin, the victim's notification status is changed without their knowledge or consent.

Although this does not expose sensitive information, it allows unauthorized modification of user data, violating the integrity of the victim's account.

CVSS v3.1 → Score: 4.3 (Medium)

Steps to Reproduce

1. Login to Attacker Account (Account A) using Firefox.

1. Navigate to Notifications.

1. Ensure at least one notification is available.

1. Enable Burp Suite Intercept.

1. Click Seen on a notification.

1. Capture the request.

1. Send the request to Burp Engagement Tools.

1. Generate a CSRF PoC.

1. Modify the generated PoC by changing:

method="POST" to method="GET"

1. Save the HTML file.

1. Login to Victim Account (Account B) using another browser (Chrome).

1. Ensure the victim has at least one unread notification.

1. Open the generated CSRF PoC in the victim's browser.

1. Click Submit Request.

1. Observe that the victim's notification is automatically marked as Seen without the victim performing the action.

Actual Behaviour

1. The notification is marked as Seen in the victim's account simply by visiting and submitting the attacker-controlled HTML page.

1. No CSRF protection, Origin validation, or SameSite-based mitigation prevents the request.

Expected Behaviour

1. The server should reject any state-changing request that does not contain a valid CSRF token and should verify the request originates from a trusted source.

1. Only the authenticated user performing the action from the legitimate application should be able to mark notifications as Seen.

Impact

1. Unauthorized modification of notification status.

1. Attackers can manipulate notification state without user consent.

1. Users may miss important notifications because they appear as already read.

1. Demonstrates missing CSRF protection on a state-changing endpoint.

1. Indicates other sensitive endpoints may also be vulnerable to CSRF.

Business Impact

1. Loss of integrity of user account data.

1. Important alerts, security notifications, or business messages may be marked as read without the user's knowledge.

1. Reduced user trust due to unauthorized account actions.

1. Reveals a security control weakness that could affect higher-risk endpoints if the same protection is missing elsewhere.

Remediation

1. Implement anti-CSRF tokens for all state-changing requests.

1. Validate the Origin and Referer headers.

1. Use SameSite=Lax or preferably SameSite=Strict for session cookies where appropriate.

1. Ensure endpoints that modify data only accept the intended HTTP method (e.g., POST) and cannot be invoked via GET.

1. Follow the Synchronizer Token Pattern or another robust CSRF defense mechanism across the application.

Video Proof of Concept:

Google Drive link → https://drive.google.com/drive/folders/1v9Y7TFbgv-FFztKX23aL_ZNkDu3GCqWT?usp=drive_link

Conclusion

The notification "Seen" endpoint lacks proper CSRF protection, allowing an attacker to force authenticated users to unknowingly mark their notifications as read. While the immediate impact is limited to unauthorized state modification, it represents a clear integrity issue and indicates that CSRF protections may be absent from other state-changing endpoints. Implementing standard CSRF defenses will prevent unauthorized cross-site requests and strengthen the application's overall security posture.

Thanks