Path traversal: gebruik ID's, geen bestandsnamen, controleer het pad

Path traversal komt voor overal waar uw code externe input gebruikt om een padnaam samen te stellen en niet voorkomt dat die padnaam buiten de bedoelde map uitkomt. CWE-22 is de bijbehorende vermelding. Zoek elke plek waar dit gebeurt, laat gebruikers geen bestandsnamen meer aanleveren en controleer voor de input die overblijft het herleide pad.

Wat een aanvaller bereikt

Lezen is pas het begin. Afhankelijk van wat de code met het pad doet, kan een aanvaller onverwachte bestanden lezen en gevoelige gegevens blootleggen, programma's en bibliotheken aanmaken of overschrijven en daarmee code uitvoeren, of bestanden beschadigen totdat het product niet meer werkt of gebruikers buitensluit. OWASP noemt broncode en configuratie van applicaties onder de bestanden die bereikbaar kunnen zijn.

Bestanden achter een beveiligingsmechanisme zijn de gevaarlijkste doelwitten. Het lezen van een wachtwoordbestand maakt brute force-aanvallen op accounts mogelijk, en wie er een nieuw account aan toevoegt, kan authenticatie omzeilen.

Het bereik hangt af van het platform. Op Windows kan een aanvaller alleen binnen de partitie bewegen waarop de web root staat, op Linux over de hele schijf. Daar bovenop gelden nog altijd de toegangsbeperkingen van het besturingssysteem.

De plekken vinden waar paden worden samengesteld

Begin bij de sink, niet bij de URL. Maak een lijst van elke aanroep die een bestand opent, leest, serveert, include of schrijft, en herleid vervolgens elk padargument naar de oorsprong. Alles wat met de request in aanraking komt, komt op de lijst, ook aanroepen die verstopt zitten achter uw eigen wrapperfuncties en framework-helpers, dus controleer ook de aanroepers daarvan.

De input is breder dan de query string. De OWASP-voorbeelden bevatten onder meer get-files.jsp?file=report.pdf, get-page.php?home=aaa.html en some-page.asp?page=index.html, en ook een cookie. Dit fragment is aangepast uit het voorbeeld van OWASP (oorspronkelijk van Wikipedia):

$template = 'blue.php';
if ( isset( $_COOKIE['TEMPLATE'] ) )
    $template = $_COOKIE['TEMPLATE'];
include ( "/home/users/phpguru/templates/" . $template );

Een cookie met TEMPLATE=../../../../../../../../../etc/passwd laat include() omhoog klimmen naar de rootmap en het wachtwoordbestand teruggeven. Parameters met namen als file, page, template of f zijn de gebruikelijke verdachten, maar namen zijn geen betrouwbare wegwijzer. Volg de data.

Controleer drie vormen:

• Relatieve traversal: ../-reeksen die uit de bedoelde map klimmen.
• Absolute paden: ?f=/etc/passwd of ?f=/var/www/html/get.php, die werken wanneer de input als volledig pad wordt gebruikt.
• Remote includes: ?page=http://other-site/... wanneer het include-mechanisme URL's accepteert.

Uitgebreide foutmeldingen helpen de aanvaller, omdat ze echte paden prijsgeven waarop kan worden gegokt. Controleer wat uw applicatie teruggeeft als een bestand ontbreekt.

Waarom blocklists falen

Het verwijderen van ../ werkt niet, omdat dezelfde traversal op veel manieren te schrijven is:

• %2e%2e%2f, ..%2f en %2e%2e/ betekenen allemaal ../.
• ..%5c en %2e%2e%5c betekenen ..\, wat van belang is op Windows, waar beide scheidingstekens werken.
• %252e%252e%255c is de dubbel gecodeerde vorm van ..\. Webcontainers decoderen één niveau, dus de waarde komt nog gecodeerd binnen. Als uw code of een bibliotheek hem opnieuw decodeert, wordt het alsnog traversal nadat de controle al is uitgevoerd.
• ..%c0%af en ..%c1%9c zijn nog meer coderingen van ../ en ..\.
• Een nulbyte, zoals in ?file=secret.doc%00.pdf, kan ervoor zorgen dat een Java-applicatie .pdf ziet terwijl het besturingssysteem .doc ziet. Aanvallers gebruiken dit om validatie te omzeilen.

Filteren werkt ook op zijn eigen voorwaarden averechts. Verwijdert u ../ achtereenvolgens uit .../...//, dan vormen de overgebleven tekens opnieuw ../. Alleen / filteren is nutteloos als het bestandssysteem \ accepteert.

Oplossing één: accepteer geen paden meer

De beste maatregel is om gebruikersinput uit het pad te halen. Gebruik indexen in plaats van delen van bestandsnamen. Het voorbeeld van OWASP is een taalbestand: de gebruiker stuurt 5 mee en de server koppelt dat aan de taal, in plaats van een teruggestuurde naam te vertrouwen.

Sla bij downloads bestanden op onder een ID en serveer ze op ID, zodat de gebruiker nooit een naam of extensie aanlevert. Het voorbeeld met de template wordt dan:

$templates = [1 => 'blue.php', 2 => 'red.php'];
$id = (int) ($_COOKIE['TEMPLATE'] ?? 1);
$template = $templates[$id] ?? 'blue.php';
include '/home/users/phpguru/templates/' . $template;

Moet u toch een naam accepteren, valideer die dan tegen bekende goede waarden en wijs de rest af. Gebruik een strikte allowlist van tekens, hoogstens één . in de bestandsnaam, geen mapscheidingstekens en een lijst met toegestane extensies. Wijs slechte input af in plaats van te proberen die te saneren.

Oplossing twee: canonicaliseer en controleer dan

Moet input een bestands-API bereiken, decodeer die dan één keer en herleid hem met een ingebouwde canonicalisatiefunctie voordat u valideert:

Deze functies verwijderen ..-reeksen en symbolische links. Controleer na het herleiden of het resultaat nog steeds binnen uw basismap valt en weiger de request als dat niet zo is. Een PHP-schets, waarbij $name de allowlist al is gepasseerd:

$base = realpath('/home/users/phpguru/templates');
$full = realpath($base . '/' . $name);
if ($full === false || strpos($full, $base . DIRECTORY_SEPARATOR) !== 0) {
    http_response_code(404);
    exit;
}

Houd elke controle op de server. Validatie aan de clientzijde is triviaal te omzeilen.

Beperk de schade

Houd gevoelige configuratiebestanden buiten de web root. Zet op Windows IIS de web root niet op de systeemschijf, zodat traversal geen systeemmappen kan bereiken. Chrooted jails en code access policies beperken waar bestanden gelezen of geschreven kunnen worden, en ze beperken de schade wanneer een controle is gemist.

Voor het testen speelt u de bovenstaande coderingen opnieuw af tegen elke parameter die u hebt gevonden, samen met een absoluut pad en een remote URL. Een pentest doet dit systematisch.

Waar te beginnen

1. Maak een lijst van elke bestandsgerelateerde aanroep in uw code, voeg de wrappers en framework-helpers eromheen toe en herleid elk padargument naar de bron, inclusief cookies en headers.
2. Vervang door gebruikers aangeleverde bestandsnamen door ID's die op de server aan bestanden zijn gekoppeld, te beginnen met downloads en de keuze van templates of talen.
3. Decodeer voor elk resterend geval één keer, canonicaliseer met de functie van het platform en weiger alles wat buiten de basismap uitkomt.
4. Verwijder blocklist-code die ../ of / wegfiltert en vervang die door een allowlist van tekens, extensies en, waar mogelijk, waarden.
5. Verplaats gevoelige configuratie buiten de web root en stop met het teruggeven van foutmeldingen die bestandspaden prijsgeven.
6. Test elke parameter met de gecodeerde, dubbel gecodeerde, absolute en remote varianten en bewaar de testgevallen als regressietests.