Online Examination System Project 1.0 - Cross-site request forgery (CSRF)

Exploit Author: Ramil Mustafayev Analysis Author: www.bubbleslearn.ir Category: WebApps Language: PHP Published Date: 2023-06-13

# Exploit Title: Online Examination System Project 1.0 - Cross-site request forgery (CSRF)
# Google Dork: n/a
# Date: 09/06/2023
# Exploit Author: Ramil Mustafayev (kryptohaker)
# Vendor Homepage: https://github.com/projectworldsofficial/online-examination-systen-in-php
# Software Link: https://github.com/projectworlds32/online-examination-systen-in-php/archive/master.zip
# Version: 1.0
# Tested on: Windows 10, XAMPP for Windows 8.0.28 / PHP 8.0.28
# CVE : n/a

Online Examination System Project <=1.0 versions (PHP/MYSQL) are vulnerable to Cross-Site Request Forgery (CSRF) attacks. An attacker can craft a malicious link that, when clicked by an admin user, will delete a user account from the database without the admin’s consent. This is possible because the application uses GET requests to perform account deletion and does not implement any CSRF protection mechanism. The email of the user to be deleted is passed as a parameter in the URL, which can be manipulated by the attacker. This could result in loss of data.

To exploit this vulnerability, an attacker needs to do the following:

1. Identify the URL of the target application where Online Examination System Project is installed. For example, http://example.com/
2. Identify the email address of a user account that the attacker wants to delete. For example, victim@example.com
3. Create an HTML page that contains a hidden form with the target URL and the user email as parameters. For example:

<html>
  <body>
    <form action="http://example.com/update.php" method="GET">
      <input type="hidden" name="demail" value="victim@example.com" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

4. Host the HTML page on a server that is accessible by the admin user of the target application. For example, http://attacker.com/poc.html
5. Send the URL of the HTML page to the admin user via email, social media, or any other means.

If the admin user visits the URL of the HTML page, the script will submit the form and delete the user account associated with the email address from the database without the admin’s consent or knowledge.

Understanding Cross-Site Request Forgery (CSRF) in the Online Examination System Project 1.0

Cross-Site Request Forgery (CSRF) is a critical web security vulnerability that allows attackers to exploit authenticated users' sessions to perform unintended actions on their behalf. In the case of the Online Examination System Project 1.0, a widely used PHP-based application hosted on GitHub, this vulnerability manifests in a particularly dangerous way: unauthorized deletion of user accounts through maliciously crafted URLs.

Root Cause: Insecure Use of GET Requests

The core flaw lies in how the application handles account deletion. Instead of using a secure POST method with token validation, the system relies on GET requests to delete user accounts. The target endpoint — typically update.php — accepts the email address of the victim as a query parameter, such as:

http://example.com/update.php?demail=victim@example.com

This design is inherently insecure because GET requests are easily manipulated and can be triggered via links, images, or embedded scripts. Unlike POST, GET requests are not protected by default CSRF mechanisms, and their parameters are visible in the URL, making them ideal targets for exploitation.

Exploitation Scenario: The Malicious HTML Page

An attacker can create a simple HTML page that silently submits a request to the vulnerable endpoint. The following example demonstrates how this works:

<html>
<body>
<form action="http://example.com/update.php" method="GET">
<input type="hidden" name="demail" value="victim@example.com" />
</form>
<script>
    document.forms[0].submit();
</script>
</body>
</html>

Explanation: This code creates a hidden form with a GET method targeting the update.php script. The demail parameter is set to the email of the intended victim. Upon loading, the embedded JavaScript automatically submits the form without user interaction. If the admin user visits this page — even through a phishing email or social media link — the deletion request is executed.

Impact and Risk Assessment

Because the attack requires only a single click from an authenticated admin user, the consequences are severe:

Data loss: User accounts can be permanently removed from the database.
Privilege escalation: An attacker could delete administrators or key users to destabilize the system.
Reputation damage: Unauthorized actions can lead to trust erosion and legal liability.

This vulnerability is especially dangerous in educational environments where exam data, user credentials, and performance records are sensitive. A single CSRF exploit could compromise the integrity of an entire examination process.

Security Best Practices to Prevent CSRF

Modern web applications must implement robust CSRF protection. The following strategies are essential:

Use POST instead of GET: For actions that modify data, always use POST. GET should be reserved for read-only operations.
Implement CSRF tokens: Generate a unique token per session and include it in forms. The server verifies the token before processing the request.
Validate request origin: Use HTTP headers like Referer or Origin to verify the request comes from a trusted source.
Require user confirmation: For destructive actions like account deletion, prompt users with a confirmation dialog.

Corrected Implementation Example

Here’s how the vulnerable update.php should be redesigned:

<?php
session_start();
if (!isset($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    if (!isset($_POST['csrf_token']) || $_POST['csrf_token'] !== $_SESSION['csrf_token']) {
        die('CSRF token mismatch');
    }
    $email = $_POST['demail'];
    // Proceed with database deletion
    $sql = "DELETE FROM users WHERE email = ?";
    // Execute query securely
    // ...
} else {
    // Render form with CSRF token
    ?>
    <form action="update.php" method="POST">
    <input type="hidden" name="csrf_token" value="" />
    <input type="text" name="demail" placeholder="Enter email to delete" />
    <button type="submit">Delete Account</button>
    </form>
    <?php
}
?>

Explanation: This revised version uses POST, includes a session-based CSRF token, and validates it on the server. Even if an attacker crafts a malicious link, the request will fail unless the token matches. This eliminates the risk of unauthorized actions.

Conclusion: Proactive Security in Open-Source Projects

While the Online Examination System Project 1.0 is a useful educational tool, its lack of CSRF protection underscores a broader issue: many open-source projects prioritize functionality over security. Developers must adopt secure coding practices from the start, especially when handling sensitive operations like user management.

For administrators, always audit third-party applications before deployment. For developers, use frameworks like Laravel or Symfony that include built-in CSRF protection. Security is not a patch — it’s a foundation.