Directory traversal and file inclusion

Objective 4.4 in this course covers web application attacks — SQL injection, cross-site scripting and directory traversal. This is the third. Runs against your own deliberately-weak application, in the lab from lesson 2.

Why this matters

These flaws come from an application trusting the client to say which file to open. Directory traversal is named explicitly by CompTIA, and file inclusion is its more dangerous relative — the difference between reading a file you should not and running code you should not. Both are examinable and both remain common wherever an application maps user input onto the filesystem.

The lesson

Path handling that trusts the client

The root cause is an application that takes a filename or path from the user and uses it to locate a file, trusting that the input names only what the developer intended.

The problem is that filesystem paths have navigation built in: a relative reference can climb out of the intended directory and reach elsewhere on the system. If the application concatenates user input into a path and opens the result, the user can steer it out of the web directory and into files the application can read but should never serve.

The same trust appears in reverse when an application decides which code to load based on user input — that is file inclusion, below — and the underlying mistake is identical: a decision the application should make is delegated to the client.

Traversal, local inclusion and remote inclusion

Three related flaws, escalating in severity:

• Directory traversal (path traversal) reads files outside the intended directory. The impact is disclosure — configuration files, source, the password-hash file, application data — anything the application's account can read.
• Local file inclusion goes further: the application includes and executes a file it is tricked into loading, and if an attacker can influence the contents of a local file the application then includes, that becomes code execution. The classic path is to get attacker-controlled content into a file the server writes — a log, an upload — and then include it.
• Remote file inclusion is the most severe and, mercifully, rarer now: the application includes a file from a location the attacker controls entirely, giving direct code execution. Modern defaults disable the loading of remote resources that made this easy, which is why it is less common than it was.

The progression to carry: traversal reads, local inclusion can escalate to execution, remote inclusion is execution outright.

Reading a file you were not meant to read, in your lab

The applied lab, on the deliberately-weak application from lesson 2, using files you placed so you know the answer.

1. Find a parameter that names a file — a download, a template selector, a language file, an image loader.
2. Test whether it honours navigation out of its directory, reading a file you planted outside the web root as the marker.
3. Characterise the reach — what can the application's account read? That defines the impact.
4. Look for a path from read to execution (local inclusion), where content you can influence gets included.
5. Capture traffic and read the logs, the defender's half.

Keep the demonstration to a marker file you planted, not the system's real sensitive files — the finding is that arbitrary read is possible and what it can reach, proved with the minimum from lesson 18.

Escalating from file read to code execution

The step that turns a disclosure into a compromise, and the reason traversal is rated more seriously than "just reading files":

• Read leads to further attack. A configuration file exposes database credentials (feeding lesson 30), source reveals other flaws, a key file grants access elsewhere.
• Read plus write-somewhere leads to execution. If the attacker can get controlled content into any file the application will then include or execute — a log they can write to, an upload directory, a session file — traversal or inclusion becomes code execution.
• Chaining is the norm here. Lesson 40's attack narrative is often built on exactly this: a traversal flaw that reads a credential that reaches a database that holds a session. Reported individually these look like a medium and a low; reported as a chain they are a critical, which is why recognising the chain is the tester's value.

So the finding characterises not just the read but where it leads, and the severity reflects the chain rather than the single step.

Canonicalisation and allow-lists as the fix

Remediation at the cause:

• Canonicalise, then validate. Resolve the path to its real, absolute form first — collapsing all the navigation — and then check that the result is inside the permitted directory. Validating before resolving is the common mistake, because the navigation has not been collapsed yet and the check is fooled.
• Prefer an allow-list or an indirection. Rather than accepting a filename at all, map a user-supplied identifier to a known file server-side. The user picks from a set you control; they never name a path. This closes the class by construction.
• Run with least privilege, so that even a successful traversal reaches as little as possible — the application's account cannot read what it has no permission to.
• Disable remote resource loading for inclusion, which is a default now but worth confirming.
• Do not rely on filtering the navigation sequences. Stripping the obvious climb sequence is defeated by encoding and by variations; it is the escaping mistake from lessons 30 and 31 in a new place.

The message to the client is consistent with the whole domain: fix the cause (canonicalise and confine, or use indirection), and the class closes; filter the input, and it returns wherever the next path is built.

What to take into the exam

• The cause is an application trusting the client to name which file to open.
• Traversal reads outside the intended directory; local file inclusion can escalate to execution; remote file inclusion is execution outright.
• Read escalates to compromise via what it exposes, and to execution if attacker-controlled content can be written somewhere then included — report the chain, not the single step.
• Fix by canonicalising then validating against a permitted directory, or by indirection through a server-side allow-list; filtering the navigation sequences is not the fix.