Information disclosure

Applicaties vertellen geregeld meer dan hun bouwers bedoelden: een stack trace na een onverwachte fout, een vergeten .git-map naast de webroot, een API die het hele databaserecord teruggeeft terwijl het scherm drie velden toont. Afzonderlijk oogt zo’n lek onschuldig, maar samen leveren ze een aanvaller de kennis voor zijn volgende stap. Hieronder leest u hoe information disclosure ontstaat en hoe u het dichtzet.

Wat is information disclosure?

Information disclosure, in het Nederlands informatielekkage, is een kwetsbaarheid waarbij een applicatie technische of persoonlijke gegevens prijsgeeft aan iemand die daar geen recht op heeft. Het is geen enkele fout maar een categorie: alles wat een systeem onbedoeld over zichzelf of over zijn gebruikers vertelt.

Een alledaagse vergelijking: een winkel waarvan de deur naar het magazijn op een kier staat. Zolang niemand naar binnen loopt verdwijnt er niets, maar iedereen die langsloopt ziet welke kluis er staat. De inbraak volgt later.

In de praktijk komt het lek uit een handvol bekende hoeken:

• stack traces en uitgebreide foutmeldingen met het framework, het versienummer, een absoluut pad of een mislukte query;
• debug-endpoints die in productie bereikbaar bleven: een profiler, een statuspagina met de volledige configuratie, een routeoverzicht;
• meegedeployde ontwikkelbestanden zoals een .git-map, een .env-bestand of een back-up naast de webroot;
• source maps, die de geminificeerde frontend terugvertalen naar de broncode inclusief commentaar;
• API-responses met meer velden dan de interface toont, doordat het hele model in één keer wordt geserialiseerd.

In de OWASP Top 10 valt dit onder A01:2021 Broken Access Control, met CWE-200 als classificatie.

Hoe werkt een information disclosure-aanval?

Een aanvaller begint zelden met een exploit, maar met verkenning, en information disclosure is de goedkoopste bron. Het meest voorkomende geval is meteen het minst zichtbare: een portaal dat netjes controleert wie een gebruikersrecord mag opvragen, en dat record volledig teruggeeft.

Kwetsbaar:

// Het volledige model gaat over de lijn
app.get("/api/users/:id", async (req, res) => {
  const user = await db.users.findById(req.params.id);
  res.json(user);
});

// En de foutafhandeling stuurt de stack trace mee
app.use((err, req, res, next) => {
  res.status(500).json({ message: err.message, stack: err.stack });
});

De interface toont alleen de naam en de rol, dus in de browser lijkt niets aan de hand. De respons zelf bevat meer:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "J. Jansen",
  "email": "j.jansen@example.com",
  "passwordHash": "$2b$12$Q7l0mR4...",
  "totpSecret": "JBSWY3DPEHPK3PXP",
  "role": "admin",
  "internalNote": "account doorgegeven aan incasso"
}

De aanvaller forceert hier niets: hij opent de ontwikkelaarsconsole en leest de respons voor zijn eigen account. Het hashveld maakt offline kraken mogelijk, het TOTP-geheim (time-based one-time password, de code uit de authenticator-app) maakt de tweede factor waardeloos, en de interne notitie is een persoonsgegeven.

De foutafhandeling doet hetzelfde met technische informatie. Eén verzoek met een parameter van het verkeerde type levert een stack trace met het absolute pad, de gebruikte ORM en het versienummer, soms met de mislukte query. Dat verandert blind gokken in een gerichte aanval.

Buiten de API herhaalt het patroon zich. Wie deployt door een werkmap te kopiëren, zet de hele versiegeschiedenis online. Eén verzoek verraadt het:

curl -s https://app.example.com/.git/HEAD
# ref: refs/heads/main

Komt die regel terug in plaats van een 404, dan is de repository te reconstrueren, inclusief oude commits met een sleutel die later is opgeruimd. Source maps volgen dezelfde logica: een .map-bestand naast uw bundel geeft de onbewerkte broncode terug.

De veilige variant rust op twee principes: elke respons wordt veld voor veld samengesteld (response shaping) en fouten gaan generiek naar buiten, met het detail in het logboek.

Veilig:

// Allowlist van velden: wat hier niet staat, verlaat de server niet
const publicUser = (user) => ({
  id: user.id,
  name: user.name,
  role: user.role
});

app.get("/api/users/:id", async (req, res) => {
  const user = await db.users.findById(req.params.id);
  if (!user) return res.status(404).json({ error: "Niet gevonden" });
  res.json(publicUser(user));
});

app.use((err, req, res, next) => {
  const ref = crypto.randomUUID();
  logger.error({ ref, err });
  res.status(500).json({ error: "Interne serverfout", ref });
});

De gebruiker krijgt een korte melding met een referentienummer, waarmee uw supportafdeling de stack trace in het logboek terugvindt. Belangrijk is dat de lijst positief is: een nieuwe databasekolom verschijnt niet stilletjes in de API, terwijl een lijst van te verbergen velden bij elke schemawijziging stukloopt.

Wat is de impact van information disclosure?

De ernst loopt sterk uiteen, en juist daarom wordt deze categorie vaak weggewuifd. Aan de onderkant staat een X-Powered-By-header of een versienummer op een foutpagina: op zichzelf laag, want er gaan geen gegevens verloren. Toch vertelt het een aanvaller welke exploits de moeite waard zijn.

In het midden zitten de gevallen die een andere aanval mogelijk maken. Een stack trace met een mislukte SQL-query versnelt het uitbuiten van een injectie, en een verschil tussen de melding voor een onbekende gebruiker en die voor een verkeerd wachtwoord verraadt welke e-mailadressen een account hebben, wat gerichte phishing en credential stuffing voedt.

Aan de bovenkant is de impact hoog. Een API die persoonsgegevens aan een onbevoegde geeft, is een datalek in de zin van de AVG, met een meldplicht bij de Autoriteit Persoonsgegevens en mogelijk bij de betrokkenen. Een bereikbare .git-map of een .env-bestand met databasewachtwoorden is geen lek meer maar een sleutelbos. Die spreiding van laag tot hoog maakt dat elke bevinding op haar eigen inhoud moet worden beoordeeld.

Hoe spoort u information disclosure op?

Het opsporen begint bij het uitlokken van fouten. Stuur een letter waar een getal wordt verwacht, of laat een verplichte parameter weg, en kijk wat er terugkomt. Een nette applicatie antwoordt met een korte melding, een lekkende met een stack trace.

Loop daarna de bekende paden langs: /.git/HEAD, /.env, /server-status, /actuator, /debug en back-ups die naar het domein zijn vernoemd. Controleer de responsheaders Server en X-Powered-By, en zoek in de frontendbundel naar verwijzingen naar .map-bestanden en naar commentaar dat de build heeft overleefd.

De waardevolste bevindingen komen echter niet uit een scanner. Leg een API-respons naast het scherm dat hem gebruikt en tel de velden: alles wat de interface niet toont, is een kandidaat. Roep daarna hetzelfde endpoint aan als beheerder en als gewone gebruiker; identieke responses betekenen dat de API velden voor de beheerder lekt. Dat werk vraagt begrip van het datamodel, en daar lopen scanners op vast. AssistSec neemt dit onderzoek mee in een penetratietest en legt per bevinding vast welk veld of bestand zichtbaar was.

Hoe voorkomt u information disclosure?

• Zet debugmodus uit in productie en geef generieke fouten terug. Eén korte melding met een referentienummer voor de gebruiker, het detail alleen in het logboek.
• Stel elke respons expliciet samen. Bouw de uitvoer op uit een vaste lijst velden, via een DTO (data transfer object) of een serializer, in plaats van het databasemodel te serialiseren.
• Houd ontwikkelbestanden buiten de webroot. Rol een build-artefact uit in plaats van een werkmap en blokkeer paden als .git en .env ook in de webserver of het CDN.
• Publiceer geen source maps. Upload ze naar uw error monitoring in plaats van ze naast de bundel te laten staan.
• Sluit debug- en beheerinterfaces af. Profilers, metrics- en health-endpoints en beheerroutes horen achter authenticatie of netwerksegmentatie.
• Beperk wat uw infrastructuur en uw meldingen verklappen. Schakel serverbanners en directory listing uit, en gebruik bij inloggen dezelfde melding voor een bestaand en een niet-bestaand account.
• Behandel gelekte gegevens als openbaar. Roteer sleutels die zichtbaar zijn geweest en laat de correctie in een hertest bevestigen.