Security misconfiguration

Niet elke kwetsbaarheid is een programmeerfout. Bij security misconfiguration werkt de software precies zoals bedoeld, alleen staan de instellingen verkeerd. Een vergeten standaardwachtwoord, een debug-modus die in productie aanstaat of een cloud-bucket die publiek leesbaar is: kleine slordigheden met grote gevolgen. In dit artikel leest u wat er onder security misconfiguration valt, hoe aanvallers zulke fouten geautomatiseerd vinden, wat de schade kan zijn en hoe u uw omgeving structureel dichtzet.

Wat is security misconfiguration?

Security misconfiguration is de verzamelnaam voor beveiligingsrisico’s die niet in de broncode zitten, maar in de installatie en afstelling van software: standaardaccounts die nooit zijn gewijzigd, onnodige functies en poorten die openstaan, foutmeldingen die interne details prijsgeven, ontbrekende beveiligingsheaders of cloudrechten die veel te ruim zijn toegekend. De categorie staat als A05:2021 op plek vijf van de OWASP Top 10 en valt onder CWE-16 (Configuration).

Vergelijk het met een gloednieuw kantoorpand met gecertificeerd sluitwerk. Aan de sloten ligt het niet, maar de aannemer heeft alle deuren op de fabriekscode laten staan, de nooduitgang staat nog op een kier voor de verhuizers en in de hal hangt de plattegrond van het alarmsysteem. Er is niets kapot; het pand is alleen nooit veilig afgesteld. Precies dat is security misconfiguration: werkende techniek waarvan de instellingen de deur openlaten.

Het lastige aan deze categorie is de breedte. De fout kan in elke laag van de stack zitten: het besturingssysteem, de webserver, het framework, de database, een container of het cloudplatform. Eén vergeten instelling in één laag is voor een aanvaller al genoeg.

Hoe werkt een aanval via security misconfiguration?

Aanvallers hoeven er zelden moeite voor te doen. Zoekmachines als Shodan en Censys indexeren doorlopend alles wat aan internet hangt, inclusief versienummers, open poorten en beheerinterfaces. Geautomatiseerde scripts proberen bekende paden zoals /admin, /.git, /backup en /phpinfo.php, en werken lijsten met standaardwachtwoorden af. Wie een verkeerd afgestelde server draait, wordt meestal binnen enkele uren gevonden, niet omdat iemand het specifiek op u gemunt heeft, maar omdat het hele internet continu wordt afgetast.

Hoe zoiets er in de praktijk uitziet, laat dit Express-voorbeeld zien: een API waarin drie veelvoorkomende configuratiefouten tegelijk zitten.

Kwetsbaar:

const express = require('express');
const cors = require('cors');
const serveIndex = require('serve-index');
const app = express();

// CORS wagenwijd open: elke website mag de API aanroepen
app.use(cors({ origin: '*' }));

// Directory listing toont elk bestand in /backup
app.use('/backup', serveIndex('backup'), express.static('backup'));

// Foutafhandeling lekt stacktraces en versies naar de bezoeker
app.use((err, req, res, next) => {
  res.status(500).send('<pre>' + err.stack + '</pre>');
});

Een aanvaller die /backup opvraagt, krijgt een keurige lijst van alle bestanden in die map, inclusief dat ene database-exportje van vorig jaar. De wagenwijd open CORS-instelling laat elke willekeurige website vanuit de browser van een bezoeker met de API praten. En elke fout die de applicatie gooit, stuurt een volledige stacktrace terug: bestandspaden, mappenstructuur, frameworkversies en soms zelfs fragmenten van queries. Elk detail versnelt de volgende stap van de aanval.

Veilig:

const express = require('express');
const helmet = require('helmet');
const cors = require('cors');
const app = express();

app.disable('x-powered-by');   // verklap het framework niet
app.use(helmet());             // zet gangbare beveiligingsheaders

// Alleen de origins die u echt vertrouwt
app.use(cors({ origin: ['https://app.example.com'] }));

// Statische bestanden zonder listing, dotfiles geblokkeerd
app.use('/files', express.static('files', { index: false, dotfiles: 'deny' }));

// Generieke fout naar de client, details alleen in het log
app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ error: 'Interne serverfout' });
});

De veilige variant draait elke kraan dicht: CORS werkt met een expliciete allowlist, statische bestanden worden geserveerd zonder mappenoverzicht en met geblokkeerde dotfiles, en de bezoeker krijgt bij een fout alleen een generieke melding terwijl de details in het interne log belanden. Helmet zet daarbovenop de gangbare beveiligingsheaders en de header die het framework verraadt, gaat uit. Belangrijker nog dan de losse regels is het principe erachter: alles wat niet uitdrukkelijk nodig is, staat dicht.

Wat is de impact van security misconfiguration?

De ernst loopt uiteen van laag tot hoog, en dat ziet u terug in de praktijk. Een ontbrekende header of een zichtbaar versienummer is op zichzelf beperkt: het lekt informatie waarmee een aanvaller zijn aanval scherper richt. Maar een beheerpaneel met standaardwachtwoord, een database die zonder authenticatie aan internet hangt of een publiek leesbare opslag-bucket geeft direct toegang tot systemen en gevoelige data. Open Elasticsearch- en MongoDB-instanties zonder wachtwoord hebben de afgelopen jaren herhaaldelijk miljoenen klantgegevens gelekt, zonder dat er één regel code aan te pas kwam.

Daarnaast is misconfiguratie zelden het eindstation. Een uitgebreide foutmelding verklapt paden die een path traversal-aanval mogelijk maken, een XML-parser met standaardinstellingen opent de deur naar XXE, en een vergeten debug-console groeit uit tot remote code execution. Voor de organisatie betekent dat al snel een meldplichtig datalek onder de AVG, herstelkosten, reputatieschade en lastige vragen van klanten en toezichthouders, veroorzaakt door een instelling die in vijf minuten goed had gestaan.

Hoe spoor je security misconfiguration op?

Het goede nieuws: configuratiefouten zijn goed vindbaar. Geautomatiseerde scanners vergelijken headers, TLS-instellingen, bekende paden en versienummers met veilige baselines en vangen daarmee het laaghangend fruit. Maar context blijft mensenwerk: of een bereikbaar endpoint echt een probleem is, hangt af van wat erachter zit. Pentesters volgen daarom onder meer de configuratiehoofdstukken van de OWASP Web Security Testing Guide: ze proberen standaardwachtwoorden, zoeken vergeten test- en beheerinterfaces, lokken foutmeldingen uit, controleren cloudrechten en bucket-permissies en bekijken of omgevingen onderling verschillen. AssistSec neemt deze controles standaard mee in elke penetratietest, juist omdat hier zo vaak de eerste voet tussen de deur zit.

Hoe voorkom je security misconfiguration?

• Maak hardening een herhaalbaar proces: leg de veilige configuratie vast in code (infrastructure as code, golden images) zodat elke omgeving identiek en controleerbaar wordt uitgerold.
• Minimaliseer het aanvalsoppervlak: verwijder of deactiveer voorbeeldapplicaties, ongebruikte functies, poorten, pakketten en accounts.
• Vervang vóór livegang alle standaardwachtwoorden en verwijder default accounts.
• Scheid ontwikkeling, test en productie strikt; zet debug-modi en uitgebreide foutmeldingen in productie uit.
• Toon bezoekers alleen generieke foutpagina’s en schrijf technische details uitsluitend naar interne logs.
• Stuur beveiligingsheaders mee, zoals HSTS, Content-Security-Policy en X-Content-Type-Options.
• Pas least privilege toe op cloudrechten en zet opslag-buckets standaard op privé.
• Controleer de configuratie geautomatiseerd in de CI/CD-pijplijn, toets periodiek tegen benchmarks zoals die van CIS en herhaal de controle na elke wijziging.