Broncode publiek benaderbaar

Een applicatie beschermt zich normaal gesproken doordat een aanvaller van buitenaf moet raden hoe ze werkt. Wordt de broncode publiek benaderbaar, dan vervalt dat raden volledig: hij leest gewoon mee. Ook omdat versiebeheer alles bewaart, leest hij ook mee in de fouten die u ooit hebt hersteld. Hieronder leest u hoe dat gebeurt en waarom het opruimen alleen niet volstaat.

Hoe raakt broncode publiek?

Broncode wordt publiek benaderbaar wanneer bestanden die alleen tijdens ontwikkeling nodig zijn, terechtkomen in de map die uw webserver uitlevert. Er zijn een paar terugkerende oorzaken, en die hebben gemeen dat er is uitgerold door een map te kopiëren in plaats van een build te publiceren.

De bekendste is de .git-map. Die bevat het volledige archief van uw project: elke versie van elk bestand, alle commitberichten en alle namen van betrokkenen. Staat die map onder de webroot en blokkeert de webserver hem niet, dan kan iemand met een eenvoudig hulpmiddel het hele project reconstrueren, alsof hij het zelf had gekloond.

Daarnaast zijn er de back-up- en editorbestanden: config.php.bak, index.php~, .env.oud, site.zip. Die ontstaan bij handmatig werk op de server en blijven jarenlang liggen. Het gemene is dat een bestand met een gewijzigde extensie niet meer door de interpreter wordt uitgevoerd maar als platte tekst wordt uitgeleverd, config.php toont niets, config.php.bak toont uw databasewachtwoord.

Vergelijk het met een architect die na de oplevering de bouwtekeningen, de sleutelplannen en alle eerdere ontwerpversies in de hal laat liggen. Het gebouw is af en veilig, maar wie binnenloopt weet precies waar de zwakke plekken zitten.

Hoe haalt een aanvaller uw broncode op?

Kwetsbaar:

De uitrol gebeurt met een git pull in de webroot. De structuur op de server ziet er dan zo uit:

/var/www/portaal/
├── .git/               ← het volledige archief
├── .env                ← databasewachtwoord, API-sleutels
├── index.php
└── config.php.bak      ← handmatige back-up van vorige week

Een aanvaller controleert eerst of het archief bereikbaar is:

GET /.git/HEAD HTTP/1.1
Host: portaal.example

HTTP/1.1 200 OK
ref: refs/heads/main

Dat antwoord is genoeg. Met een hulpmiddel dat de objecten uit .git ophaalt, reconstrueert hij het complete project inclusief geschiedenis. Vervolgens doorzoekt hij die geschiedenis:

$ git log -p --all | grep -iE "password|api_key|secret"
+  DB_PASSWORD=Zomer2019!
+  STRIPE_SECRET_KEY=sk_live_51H8xQ2...

Deze sleutels zijn twee jaar geleden uit de code gehaald, maar staan nog in het archief. En als de databasesleutel destijds niet is gewijzigd, werkt hij nog steeds.

Veilig:

De structurele oplossing is niet uitrollen vanuit een werkmap. Publiceer een gebouwd artefact, of check uit naar een map buiten de webroot en wijs de webserver naar een submap daarvan:

/opt/portaal/            ← code, buiten de webroot
├── .git/
├── .env
└── public/              ← alleen dít is de webroot
    ├── index.php
    └── assets/

Als aanvullende laag, en uitsluitend als vangnet, blokkeert u verborgen mappen en back-upextensies in de webserver:

# Nooit uitleveren, ook niet als er per ongeluk iets belandt
location ~ /\.(git|svn|hg|env) {
    deny all;
    return 404;
}
location ~ ~$|\.(bak|old|orig|save|swp|zip|tar\.gz)$ {
    deny all;
    return 404;
}

Wat is de impact van publiek benaderbare broncode?

De ernst is hoog tot kritiek, en dat komt door de combinatie van twee dingen: volledige kennis van de applicatie en directe toegang tot geheimen.

De kennis alleen is al zwaarwegend. Met de broncode ziet een aanvaller precies hoe de autorisatie is opgezet, welke endpoints er bestaan die nergens in de interface voorkomen, hoe tokens worden gegenereerd, en waar de controles zitten die hij moet omzeilen. Elke andere kwetsbaarheid in de applicatie wordt daarmee aanzienlijk eenvoudiger te vinden en uit te buiten.

De geheimen maken het acuut. Configuratiebestanden bevatten in de praktijk databasewachtwoorden, sleutels voor betaaldiensten, tokens voor e-maildiensten en de sleutel waarmee sessietokens worden ondertekend. Die laatste is bijzonder ernstig: wie de ondertekeningssleutel heeft, kan geldige tokens maken voor elke gebruiker, inclusief beheerders, zonder ooit een wachtwoord te hoeven raden.

De reikwijdte in de tijd maakt het extra lastig. Het archief bevat niet alleen wat er nu in staat, maar alles wat er ooit in heeft gestaan. Een sleutel die drie jaar geleden per ongeluk is vastgelegd en netjes is weggehaald, is nog steeds leesbaar.

Hoe spoor je publiek benaderbare broncode op?

De controle op de bekendste paden is snel gedaan: /.git/HEAD, /.git/config, /.env, /.svn/entries. Een antwoord met inhoud in plaats van een 404 is meteen raak. Belangrijk detail: een 403 betekent dat de map bestaat maar wordt geblokkeerd, wat aangeeft dat de code wél in de webroot staat en de bescherming alleen van een configuratieregel afhangt.

Daarnaast wordt gezocht naar bestanden die niet in de applicatie voorkomen maar er wel liggen. Een tester leidt kandidaten af uit de bekende bestandsnamen (voor elke pagina.php worden varianten als pagina.php.bak, pagina.php~ en pagina.php.old geprobeerd) en zoekt naar archieven met voorspelbare namen zoals backup.zip of site.tar.gz. Ook wordt gekeken of er directory listing aanstaat, want dan is raden helemaal niet nodig. Verder krijgen bronkaarten van JavaScript aandacht: een meegepubliceerd .map-bestand geeft de oorspronkelijke frontendcode terug inclusief commentaar. AssistSec neemt dit standaard mee in de verkenningsfase van een penetratietest, omdat een vondst hier de rest van het onderzoek fundamenteel verandert.

Hoe voorkom je publiek benaderbare broncode?

• Rol uit met een gebouwd artefact of een export, nooit door een werkmap met versiebeheer te kopiëren.
• Zet de code buiten de webroot en wijs de webserver uitsluitend naar een public-submap.
• Blokkeer in uw webserver verborgen mappen en back-upextensies als vangnet.
• Bewaar geheimen niet in de code maar in omgevingsvariabelen of een sleutelkluis.
• Roteer elk geheim dat ooit in versiebeheer heeft gestaan, ook als het later is verwijderd.
• Zet een geheimenscanner in uw ontwikkelstraat, zodat sleutels niet opnieuw worden vastgelegd.
• Publiceer geen bronkaarten van JavaScript in productie, of beperk de toegang ertoe.
• Maak nooit handmatig back-ups in de webroot; gebruik daarvoor een aparte locatie.
• Controleer periodiek wat er werkelijk in de webroot staat in plaats van wat er zou moeten staan.