Vergeten staging- en testservers: het deel waar niemand naar kijkt

Een vergeten staging- of testserver is een kopie van uw website of app die voor de ontwikkeling werd opgezet en daarna online is blijven draaien. Hij staat meestal op een naam als staging.yourcompany.com, dev.yourcompany.com of test2.yourcompany.com, niemand controleert hem nog, en vaak draait er oudere code met zwakkere instellingen dan in productie.

Deze servers doen ertoe omdat ze deel uitmaken van de internetaanwezigheid van uw bedrijf, ook al behandelt niemand ze zo. Ze krijgen niet dezelfde updates, logins of monitoring als de hoofdsite, terwijl ze vaak dezelfde databasekopieën, API-sleutels en beheerdersaccounts delen.

Het goede nieuws: ze zijn makkelijk te vinden, en eenmaal gevonden is de oplossing meestal eenvoudig. Dit artikel laat zien hoe u ze opspoort en wat u met elk ervan doet.

Waarom stagingservers vergeten worden

Een stagingserver wordt met een goede reden opgezet: om een release te testen voordat klanten die zien. Dan gaat de release live, de ontwikkelaar gaat naar een ander project of het contract met het bureau loopt af, en de server blijft draaien omdat uitzetten nooit op iemands takenlijst stond. Veelvoorkomende patronen:

• Een volledige kopie van productie, inclusief een recente databasedump, zodat het testen realistisch oogt.
• Debugmodus die aan is blijven staan en stack traces, configuratiewaarden of details van het framework toont.
• Standaard- of gedeelde beheerderswachtwoorden die "alleen voor het testen" waren.
• Oude versies van het CMS, plug-ins of bibliotheken die in productie allang bijgewerkt zijn.
• Geen HTTPS, of een certificaat dat maanden geleden verlopen is.
• Indexering door zoekmachines die nooit werd geblokkeerd, zodat de testsite naast de echte opduikt.

Op zich is niets hiervan dramatisch. Samen levert het een host onder uw eigen domein op die zwakker is dan alles eromheen.

Hoe deze servers zichtbaar worden

U hoeft geen link te publiceren om een stagingserver vindbaar te maken. 3 gebruikelijke manieren:

1. Certificate Transparency. Wanneer een door browsers vertrouwd certificaat wordt uitgegeven voor staging.yourcompany.com, wordt de naam vastgelegd in logs die voor iedereen in te zien zijn (het protocol staat beschreven in RFC 9162). Iedereen kan in die logs zoeken, zoals uitgelegd in Certificate Transparency-logs uitgelegd.
2. DNS-records. Een record dat nog naar de server wijst, maakt hem bereikbaar via de naam, en voor de hand liggende namen als dev, test en beta worden als eerste geprobeerd.
3. Zoekmachines en archieven. Een testsite zonder indexeringsregels kan in zoekresultaten verschijnen, en oude pagina's blijven in webarchieven bewaard.

Zo vindt u uw eigen vergeten servers

Begin met de namen en controleer daarna elke naam.

1. Zoek op crt.sh naar %.yourcompany.com en verzamel alle hostnamen.
2. Loop uw DNS-zone na op namen als dev, stage, staging, test, uat, beta, old, demo, preview.
3. Zoek voor elke naam op waarnaar die verwijst en bekijk het antwoord:

dig +short staging.yourcompany.com
curl -sI https://staging.yourcompany.com

1. Open elke host in een browser en vraag u af: toont hij echte klantgegevens, een inlogformulier, een debugpagina, een standaard serverpagina of een foutmelding van een hostingplatform?
2. Zoek naar bestanden die nooit geserveerd mogen worden. De testgids van OWASP behandelt dit in WSTG-CONF-04 en merkt op dat back-upbestanden doorgaans als platte tekst worden geleverd in plaats van uitgevoerd. Ons artikel over bereikbare .env-, .git- en back-upbestanden somt de gebruikelijke namen op.

Wijst een naam naar een hostingplatform dat een pagina "no such app" of "bucket not found" toont, behandel dat dan als dringend: dat is de klassieke situatie voor een subdomain takeover.

Wat u met elke server doet

Kies voor elke staging- of testhost een van 3 uitkomsten.

Verwijderen. Kan niemand de eigenaar en het doel noemen, zet de server dan uit en verwijder het DNS-record. Verwijder het record na de server, niet ervoor, en laat nooit een CNAME staan die wijst naar een dienst waarvoor u niet meer betaalt.

Afschermen. Heeft het team hem nog nodig, zet hem dan achter authenticatie of een IP-allowlist. HTTP Basic-authenticatie is snel toegevoegd, maar MDN wijst erop dat die alleen via HTTPS gebruikt mag worden, omdat de inloggegevens enkel base64-gecodeerd zijn. Een VPN of een identity-aware proxy is op lange termijn een betere keuze.

Opschonen. Staging hoort geen echte klantgegevens te bevatten. Gebruik gegenereerde of gemaskeerde gegevens, aparte API-sleutels met beperkte rechten, en schakel debuguitvoer uit.

Zoekmachines weghouden is nuttig, maar het is geen beveiliging. Google documenteert noindex als manier om pagina's uit de resultaten te houden, via <meta name="robots" content="noindex"> of een X-Robots-Tag-header (Google Search Central). De pagina blijft bereikbaar voor iedereen die het adres kent.

X-Robots-Tag: noindex

Korte checklist

• Elke niet-productiehost heeft een benoemde eigenaar en een einddatum.
• Geen echte klantgegevens op staging.
• Staging vraagt om een login of staat achter een VPN.
• Debugmodus uit, aparte sleutels, geen gedeelde beheerderswachtwoorden.
• Geldig certificaat, of de host is verwijderd.
• DNS-records worden verwijderd samen met de server.
• De lijst wordt na elk afgerond project nagelopen, niet één keer per jaar.

De rol van Datahorses

Datahorses bewaakt uw bedrijf elke dag van buitenaf, inclusief nieuwe hostnamen onder uw domeinen, vergeten subdomeinen en testservers, en bestanden die daarop bereikbaar zijn. Bij elke bevinding horen exacte herstelstappen voor uw ontwikkelaar, en wij gaan uw systemen niet binnen en hebben geen toegang nodig. Bekijk wat wij bewaken en wat er gebeurt als wij iets vinden.