Skip to main content
In dit onderdeel ging het over applicaties die te veel vertrouwen leggen bij client-side waarden of verouderde componenten. Een belangrijk onderscheid uit de les: encoding maakt data leesbaar in een ander formaat, maar is geen encryptie.

In een oogopslag

Technieken in detail

Gevoelige informatie kan in cookies terechtkomen.
  • Relevante plekken: Application -> Cookies in DevTools, of Set-Cookie in een HTTP-response
  • BASE64 eindigt vaak op = of ==
  • ASCII-hex bevat alleen 0-9a-f en heeft meestal een even lengte
  • Soms is het resultaat na een eerste decode-stap opnieuw encoded
Encoding is geen beveiliging. Wie de cookie kan lezen, kan de inhoud vaak ook decoderen.
Een hex- of BASE64-token kan soms naar leesbare velden decoderen.
Typische onderdelen:
  • username, user ID of e-mailadres
  • rol, groep of applicatierechten
  • oplopend nummer
  • IP-adres of datum
  • hash gecombineerd met leesbare velden
Bij zwakke tokenformats kan een applicatie zelf een bruikbaar formaat tonen wanneer ze een nieuw account of nieuwe sessie aanmaakt.
Bij sessies is randomness belangrijk. In de les kwamen meerdere zwakke patronen aan bod.
Als een response de cookie opnieuw leegmaakt, is het verschil tussen request-cookie en response-cookie belangrijk om te bekijken in Burp of curl.
Horizontal escalation betekent dat een gebruiker data of acties van een andere gebruiker kan bereiken zonder een hogere rol te hebben.Veelvoorkomende client-side signalen:
  • basket ID
  • order ID
  • profile ID
  • user ID in een request body
  • resource-ID in een URL
Het concept draait rond de koppeling tussen identiteit en resource. Die koppeling hoort server-side gecontroleerd te worden.
Verouderde libraries, plugins of CMS-versies kunnen bekende kwetsbaarheden bevatten.Bronnen voor versiesignalen:
  • <meta name="generator">
  • HTTP headers
  • Wappalyzer
  • JavaScript- of CSS-bestandsnamen
  • WordPress REST endpoints zoals /wp-json/wp/v2/users
  • directory listing onder /wp-content/
Bestanden zoals .env, wp-config.php.bak, wp-config.php~, db.sql en backup.zip waren voorbeelden van gevoelige exposed files.
CORS bepaalt welke origins browserdata mogen opvragen. Een foutieve configuratie kan gevoelige data cross-origin beschikbaar maken.
Een belangrijk signaal is een response die de externe origin terugkaatst in combinatie met:

Encoding herkennen

Burp Decoder en CyberChef Magic waren handige hulpmiddelen om encoded waarden sneller te herkennen.

Handige parameters

curl

WPScan

Patronen uit de les

1

Cookie met rare waarde

Mogelijk encoded data, bijvoorbeeld BASE64 of hex.
2

Role of admin in cookie

Mogelijk client-side trust in autorisatie-informatie.
3

Session ID verandert voorspelbaar

Mogelijk zwakke randomness of een patroon in de sessiewaarde.
4

Functie toont data per ID

Mogelijk horizontale autorisatiebug als de server de eigenaar niet controleert.
5

Herkenbare CMS- of libraryversie

Mogelijke link met bekende CVE’s of exposed configuratiebestanden.
6

Cross-origin request

Mogelijke CORS-misconfiguratie bij reflected origins en credentials.

Tools

Browser DevTools

Referentie voor cookies, storage, network requests en response headers.

curl

Terminaltool voor cookies, headers en handmatige HTTP-requests.

Burp Suite

Proxytool voor HTTP history, Decoder, Sequencer, Repeater en Intruder.

CyberChef

Tool voor BASE64, hex, URL encoding, HTML entities en Magic.

WPScan

Scanner voor WordPress-versies, plugins, users en bekende kwetsbaarheden.

CVE

Referentie voor bekende kwetsbaarheden in softwareversies.