Can a Front-End Developer Participate in an API Security CTF?

In this article, I’ll share my experience with participating in the APIsec | CON CTF hosted by APIsec University. Fortunately, most of the challenges were approachable, thus I didn't get discouraged to tackle them despite not having had prior experience in CTFs. This allowed me to complete 12 / 17 of them during the competition, even though I joined a day and a half after the event had started. The main win was undoubtedly gaining a better understanding of API security in a short period and improving my problem-solving skills.

What Helped Me Approach the CTF

Although I didn't specifically prepare for this CTF, here are a few recent activities that I believe helped me tackle the challenges:

Completing most of the courses on APIsec University gave me a strong foundation in what to look for in terms of API security testing.
Tanya Janca's course on code security at Semgrep Academy , particularly the SQL injection examples, provided practical insights into common vulnerabilities related to input validation and sanitization, which helped me tackle two injection challenges.
Solving the labs from the PortSwigger Academy API testing learning path gave me a great start with hands-on practice in testing APIs.

My Strategy for API Testing

Inspired by Katie Paxton-Fear's presentation at the APIsec | CON back in February, I followed a simple strategy:

Poked around the app—Clicked on every button and observed what happened.
Took notes of every endpoint I encountered and sent them to Burp Repeater.
Analyzed each endpoint step by step, looking for anything suspicious or interesting.

This approach allowed me to get a feel for how the application worked and locate some of the vulnerabilities. Despite not having extensive practical knowledge of API testing, I found that leveraging my existing skills along with tools like Burp Suite, Postman, and the APIsec Scanner allowed me to find effective solutions to some of the challenges, even if my methods weren't the most technically sophisticated.

Key Vulnerabilities Covered in the CTF

One aspect of the CTF that I really enjoyed was that it provided hands-on practice with OWASP Top 10 API Security Risks I had studied in courses and seen examples of, including:

Broken Object Level Authorization (BOLA)
Broken Authentication (BA)
Broken Object Property Level Authorization (BOPLA)
Unrestricted Resource Consumption
Security Misconfigurations
Improper Inventory Management

How My Front-end Experience Helped Me Solve Challenges

My front-end development experience proved useful during the CTF. For three challenges, I relied on my instinct to open dev tools to inspect the source and network tabs and look for JavaScript files related to APIs, obfuscated functions or API requests. With this approach, I was able to identify a debug token comment and various endpoints that were key to solving the challenges.

As a front-end developer, I’ve noticed that many of us, especially early in our careers, often leave comments in our code or forget to remove them altogether. This can inadvertently lead to the disclosure of sensitive information. My familiarity with this practice helped me quickly identify the debug token in the JavaScript files, allowing me to navigate the first two challenges more efficiently. I will not go through the all challenges that I solved, and focus instead on showcasing two examples where my experience as a front-end developer helped me retrieve the flags.

How I Solved the Challenge Titled API Obscura

The debug API I encountered serves as an example of how non-production APIs may not be protected with the same security rigor as their production counterparts, making them more vulnerable to exploitation. This shadow API is an example of API9 2023 Improper Inventory Management.

When opening dev tools to look at the code, I immediately noticed the app.min.js and api.min.js files. On a quick look in the api.min.js I noticed the

  baseUrl: "/api"

followed by several async functions. I took note of the more interesting endpoints, notably "/debug" and "/admin". Also what stood out was finding a debug token commented out.

On decoding the token with a JWT decoder tool I noticed:

{
  "role": "debugger"
}

From the observation above, the "/debug" endpoint accepted a POST request with the

{
  "debug": true
}

as body. I quickly took to Postman to make the request which allowed me to access the debug mode of the app.

This allowed me to access the system logs via an API call to the /api/logs/system.log endpoint that revealed the admin token.

The next step was to make a GET request to the admin endpoint discovered in the beginning by setting this new JWT token in the authorization header. And the flag was sent back in the response body!

How I Solved the Challenge Titled Massive

Another interesting challenge I solved was the Mass Assignment one allowing user input to alter sensitive object properties to elevate their privileges and perform administrative actions. Mapped to the OWASP 2023, would make it an API3 Broken Object Property Level Authorization (BOPLA).

Upon inspecting the code in dev tools, I took note of all API endpoints I found in the script.js file.

I made a post request in Postman to the /api/auth/register to register as a user, like so:

{
  "role": "user"
}

in the response body caught my attention and I thought of trying to change my role to admin by making a PUT request to another interesting endpoint I discovered initially—/api/profiles/me. This resulted in successfully upgrading my role by leveraging this authorization flaw in the app.

Lastly, to retrieve the flag I made a GET request to /api/admin/dashboard:

Conclusion

The CTF has helped me get a better understanding of not only how APIs can be exploited but also how developers can do better in securing the apps they build. Overall, I had a great time trying to solve these challenges and exchanging insights in the Discord channel with the other participants—that alone was a priceless learning experience!

Liked this article? Share it on: