Writeup: Existential Loading Bar

Indledende Observationer

Jeg tilgik websitet og blev mødt af en admin-login side med en loadingbar der aldrig kom videre.

Wappalyzer viste at backend kørte:

  • Flask 3.1.5

  • Python 3.12.12

Der var ingen yderligere hints i UI’et, så jeg fortsatte med at undersøge koden.

Recon / Kortlægning

Jeg åbnede koden via View Source.

I bunden af HTML’en fandt jeg følgende JavaScript:

1
2
3
4
5
6
7
8

<script>
  // Admin credentials (view source to see – don’t do this in production.)
  var ADMIN_USER = "admin";
  var ADMIN_PASSWORD = "vibe_coding_ftw_2024";
  if (window.location.search.indexOf("error=1") !== -1) {
    document.getElementById("err").textContent = "Nope. Try again. (Or just view source.)";
  }
</script>

Her lå admin credentials hardcoded direkte i klient-side kode.

Kommentaren indrømmede endda eksplicit:

“view source to see – don’t do this in production.”

Dette indikerede, at applikationen stolede på frontend som en form for “hemmelighed”, hvilket aldrig er et sikkerhedsboundary.

Analyse

Sårbarheden var:

Client-Side Credential Exposure

Admin-brugernavn og password var:

1
2

ADMIN_USER = "admin"
ADMIN_PASSWORD = "vibe_coding_ftw_2024"

Frontend-kode leveres fuldt ud til brugeren og kan altid inspiceres via:

  • View Source

  • DevTools → Sources

  • Network tab

Derfor var credentials ikke hemmelige.

Angrebet

Jeg brugte de fundne credentials og loggede ind via login-formen:

1
2

Username: admin
Password: vibe_coding_ftw_2024

Login lykkedes uden yderligere beskyttelse.

Flaget

Efter succesfuldt login blev flaget vist:

1

DDC{br0_f0rg0t_th3_s4lt}

Konklusion

Jeg demonstrerede, at applikationen ikke implementerede reel adgangskontrol.
Admin-credentials var hardcoded i JavaScript og kunne tilgås via View Source.

Applikationen var et klassisk eksempel på “trust me bro”-sikkerhed.

Flag:

1

DDC{br0_f0rg0t_th3_s4lt}