Overview
Path traversal vulnerabilities revolve around file paths, so understanding how paths work is the foundation. This lesson reviews file paths in the context of web applications that read or serve files based on user input.
Learning objectives
- Review absolute vs relative paths in the file-access context.
- Explain how applications map user input to file paths.
- Identify where user-controlled paths create risk.
Core concept
A path identifies a file's location. Recall:
- Absolute paths start from the filesystem root and are unambiguous.
- Relative paths are interpreted from a base/current directory and can include
..to move up a level.
Web applications frequently build a file path from user input — for example, serving a document whose name comes from a request parameter — by combining a base directory with the user-supplied name. If the user can influence the path with traversal sequences (..), they may escape the intended directory.
How it works
An application typically has an intended base directory (e.g. a folder of downloadable files) and appends a user-provided filename to it. The danger is that path resolution honors .. to move up the tree: if the user-supplied portion contains traversal sequences, the resolved path can point outside the intended base directory to arbitrary files the application never meant to expose. The vulnerability is not paths themselves but building a file path from untrusted input without ensuring it stays within the intended directory — the topic developed across this module.
Practical example
A download feature serves files from a base directory, using a file parameter: conceptually base_dir + user_input. For a normal request like file=report.pdf, this resolves inside the base directory as intended. But because path resolution honors .., a crafted value could resolve above the base directory toward other files. The safe design ensures the final resolved path remains within base_dir — the defenses (canonicalization, allowlists, safe APIs) follow in later lessons.
Cybersecurity relevance
Understanding paths is the prerequisite for grasping path traversal, a vulnerability that can expose sensitive files (configuration, credentials, source code, system files) far outside an application's intended scope. Any feature that maps user input to a file path — downloads, includes, template loading, log viewers — is a candidate. Recognizing this pattern is the first step; the module then builds the defenses (canonicalize-then-validate, allowlists, safe file APIs) that keep resolved paths within bounds.
Common mistakes
- Building file paths from untrusted input without ensuring the result stays in the intended directory.
- Forgetting that path resolution honors
.., allowing upward traversal. - Overlooking file-path features (downloads, includes, log viewers) as traversal candidates.
Key takeaways
- Paths locate files; relative paths honor
..to move up the tree, which is central to traversal. - Applications often build a file path by combining a base directory with user input — risky if the input can influence the path.
- Any feature mapping user input to a file path is a traversal candidate; the goal is ensuring the resolved path stays within the intended directory (defenses follow).
Check your understanding
- How does the
..sequence in a path enable moving outside an intended directory? - What kinds of web features are candidates for path-traversal vulnerabilities?