All Projects

Description

A Price Manipulation vulnerability exists in the domain purchase payment flow. By intercepting the payment request before it is sent to PayPal, an attacker can modify the payment amount from the legitimate purchase price to an arbitrary lower value (e.g., 1). PayPal then processes the modified amount, and after the payment is completed, the application accepts the transaction and displays a successful payment confirmation ("Thank You for Payment").

This indicates that the application trusts the client-supplied payment amount instead of validating the payment against the server-side order value before confirming the purchase.

CVSS v3.1 → Base Score: 8.8 (High)

Steps to Reproduce

1- Log in to a valid user account.
2- Navigate to the Domain section.
3- Click Add Domain.
4- Enter the details of a non-existing domain.
5- Continue until the final payment page where PayPal is selected.
6- Intercept the payment request using Burp Suite.
7- Modify the payment amount parameter from the original value to 1.
8- Forward the modified request.
9- Observe that PayPal requests payment of only 1.
10- Complete the payment.
11- Return to the application.
12- Observe that the application displays "Thank You for Payment", accepting the manipulated payment as successful.

Actual Behavior

The application accepts a client-modified payment amount and successfully completes the purchase workflow after receiving the PayPal payment notification, despite the payment being significantly lower than the actual order value.
Expected Behavior

The server must independently verify:

The original order amount.
The amount received from PayPal.
The payment status.
The associated order ID.

If any mismatch exists, the payment must be rejected, the order should not be fulfilled, and the user should be informed that payment verification failed.

Impact

Successful exploitation could allow an attacker to:

Purchase domains for significantly less than their actual price.
Pay only a minimal amount while receiving full services.
Manipulate payment values for financial gain.
Bypass intended pricing controls.
Cause revenue loss through fraudulent transactions.

Business Impact

This vulnerability can have serious financial and operational consequences, including:

1- Direct revenue loss from underpaid purchases.
2- Abuse of the domain registration process.
3- Fraudulent acquisition of paid services.
4- Loss of trust in the payment platform.
5- Increased chargebacks and payment disputes.
6- Potential compliance and accounting issues due to inconsistent transaction records.
7- Reputational damage if exploited at scale

Remediation

Implement strict server-side payment validation:

1- Never trust the payment amount received from the client.
2- Generate the payment amount exclusively on the server.
3- Validate the PayPal transaction using PayPal's API before completing the order.
4- Reject transactions where the paid amount does not exactly match the server-side order value.
5- Bind each payment to a unique server-generated order.
6- Prevent client-side modification of pricing information.

Conclusion

The application is vulnerable to server-side price manipulation, allowing authenticated users to alter the payment amount before it reaches PayPal. Because the backend accepts the manipulated payment without validating it against the original order value, attackers may obtain paid services while paying only a fraction of the legitimate price. Proper server-side verification of payment amounts and transaction details is essential to prevent financial fraud and protect the integrity of the payment system.

Thanks

attacker testd

test

Description After a user's mailbox permissions are revoked, the application correctly removes access to the mailbox through the user interface. However, the server still allows the user to directly access previously generated mailbox audit logs by requesting the log endpoint with the corresponding log ID.

This indicates that the application does not enforce authorization checks on the audit log resource based on the user's current permissions. As a result, a user whose mailbox access has been revoked can continue to access historical audit logs related to that mailbox.
CVSS v3.1 → Score: 4.3 (Medium)

Note: If the audit logs expose sensitive mailbox configuration or confidential information, the severity may be higher.

Steps to Reproduce 1- Login with User A.
2- Invite User B as an Administrator with mailbox management permissions.
3- Login as User B.
4- Navigate to the mailbox settings and make any configuration change.
5- Verify that an audit log entry is created for the action.
6- Login as User A and revoke User B's mailbox permissions.
7- Confirm that the mailbox section is no longer accessible through the UI for User B.
8- Login again as User B.
9- Intercept the request used to retrieve an audit log (or directly access the audit log endpoint).
10- Replace the current log ID with the previously generated mailbox audit log ID.
11- Send the request.

Actual Behaviour → Even after mailbox permissions have been revoked, the server returns the historical mailbox audit log when the user directly requests it using the known log ID.

Expected Behaviour → Once mailbox permissions are revoked, the server should validate the user's current authorization before returning any mailbox-related audit logs. Unauthorized users should receive 403 Forbidden (or an equivalent authorization error).

Impact → Users can continue accessing mailbox-related audit logs after losing mailbox permissions.
→ Authorization is enforced only in the UI, not on the backend resource.
→ Historical mailbox activity remains accessible despite permission revocation.

Business Impact → Violates the principle of least privilege.
→ Former administrators or users with revoked access may continue viewing historical mailbox activity.
→ May expose operational or sensitive mailbox information depending on the audit log contents.
→ Indicates inconsistent server-side authorization checks, increasing the risk of similar access control issues elsewhere in the application.

Remediation → Perform server-side authorization checks for every audit log request.
→ Validate the user's current permissions before returning mailbox-related logs.
→ Return 403 Forbidden when the user is no longer authorized.
→ Ensure audit log access follows the same permission model as the underlying mailbox resource.
Proof of Concept (PoC) Google Drive Link: https://drive.google.com/drive/folders/1c3fthnH3Vfq60bd4RacM3_aHF8zgmw88?usp=drive_link

Conclusion The application fails to properly enforce server-side authorization on mailbox audit log resources. Although mailbox access is removed from the user interface after permission revocation, previously generated audit logs remain accessible through direct requests using known log IDs. This represents a Broken Access Control issue because authorization is not consistently enforced on the backend.

Thanks

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