# CVE-2024-27717 - Cross-Site Request Forgery (CSRF) in Eskooly Web Product <= v3.0

## Introduction

Cross-Site Request Forgery (CSRF) vulnerabilities are a significant threat to web applications, allowing attackers to perform unauthorized actions on behalf of authenticated users. This post explores CVE-2024-27717, a critical CSRF vulnerability in Eskooly Free Online School Management Software v.3.0 that enables attackers to escalate privileges via the Token Handling component.

## Discovery of the Vulnerability

CVE-2024-27717 was discovered during a detailed security assessment of Eskooly's web application. The vulnerability was identified in the token handling mechanism, where the application fails to implement sufficient measures to protect against CSRF attacks.

### Related Findings

* Cross-site Request Forgery

### **Technical Details**

The vulnerability arises from the lack of anti-CSRF tokens and improper handling of user sessions. Specifically, the application does not use unique, unpredictable tokens in state-changing requests, allowing attackers to trick authenticated users into performing unintended actions.

### Example of Impact

The impact of CVE-2024-27717 includes:

* Unauthorized actions performed on behalf of authenticated users.&#x20;
* Potential for attackers to escalate privileges and compromise user accounts.&#x20;
* Increased risk of data breaches and unauthorized data manipulation.&#x20;
* Compromise of sensitive user information and application integrity.

## Eskooly Application&#x20;

1. Update the account and password

-> POST Request:

```
POST /bb/account.php HTTP/2

Host: eskooly.com
--SNIP--

--SNIP--
email=HERE@MAIL.COM&password=1&timezone=Asia%2FKarachi&currency=2&symbol=%24&changepassword=

```

2. Craft the payload with the new mail and password

<figure><img src="https://content.gitbook.com/content/8bgvMbF6wy5EyGrkuyUO/blobs/WzPlxrFKqN0lkIDILZLl/image.png" alt=""><figcaption></figcaption></figure>

3. Send to admin and the victim triggered the attack

<figure><img src="https://content.gitbook.com/content/8bgvMbF6wy5EyGrkuyUO/blobs/SlpRRmwDgniYTTLhN4gK/image.png" alt=""><figcaption></figcaption></figure>

## Risk&#x20;

### Impact

**High.**&#x20;

The impact is high due to the nature of the actions that can be performed. Changing a user's password via CSRF can lock legitimate users out of their accounts and give attackers unauthorized access.

### Likelihood&#x20;

**High.**

In this specific context, where a CSRF attack allows password updates or change email of the victim, the likelihood is high.

## Recommendation

It’s recommended to:

1. Implement Anti-CSRF Tokens: Use unique, unpredictable anti-CSRF tokens in all forms and state-changing requests. These tokens ensure that only requests originating from your own website are accepted, effectively blocking forged requests from other sites.
2. SameSite Cookie Attribute: Utilize the SameSite attribute in cookies to restrict their sending to only first-party contexts, reducing the risk of CSRF attacks.

## **References**

* [**CWE-352: Cross-Site Request Forgery (CSRF)**](https://cwe.mitre.org/data/definitions/352.html)
* [**OWASP Top Ten 2013 Category A8 - Cross-Site Request Forgery (CSRF)**](https://cwe.mitre.org/data/definitions/936.html)
* [**OWASP: Cross-Site Request Forgery Prevention Cheat Sheet**](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)
