Sprocket Line

Room Description

https://dashboard.webverselabs-pro.com/challenges/sprocket-line

Scenario

After a phishing near-miss, Sprocket Line's owner hired someone to "add security." He got one line of PHP that strips <script> from input — and a two-page invoice. The owner feels much better now.

Objective

A bike-parts shop paid good money for a filter that strips 'script'. Only that.

Initial Analysis

We have a web application that acts a bike customization service.

We have the following endpoints exposed and available to us:

<a class="sl-tab sl-tab-active" href="/">00 · Shop</a><a class="sl-tab" href="/fit">01 · Fit Calc</a><a class="sl-tab" href="/parts">02 · Parts</a><a class="sl-tab" href="/warranty">03 · Warranty</a>

There's a similar setup to other XSS challenges on the platform, but there's not much looking around to find our entrypoint.

Finding the bug

We have 3 endpoints we can look at, and most (from the three hahahaha) are static.

/parts

This is just a list of parts that the company "holds".

/warranty

This is just an exposed support e-mail that maybe you can send phishing attacks to if this was a real client.

/fit

Now this looks interesting! We can input our bike model, let's start by entering values and see what it looks like.

This means we have several fields we can control.

Exploitation

Now, the challenge description states:

He got one line of PHP that strips from input

but is this the case? We have to check.

Let's use our typical payload.

<script>alert(0)</script>

As we can see, there is some sort of a filter that strips the value away completely, since we are missing <script> from our tag.

There are numerous ways around this, as well as different payloads.

https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

Since we know <script> specifically is being targeted, we can try to use:

<img src=x onerror=alert(0)>

And we get the flag!

From the frontend code, we can see that nothing is getting stripped from the field we need: