Path Traversal in Echo Go with Api Keys

Path Traversal occurs when an endpoint uses user-supplied input to build file system paths without proper validation or sanitization. In an Echo Go service that also exposes an Api Keys authentication mechanism, the combination can amplify risk if keys are handled inconsistently or if endpoints mistakenly treat key values as part of a file path.

Consider an Echo Go route that retrieves configuration or logs based on an identifier provided by the caller. If the identifier is directly concatenated into a filesystem path, an attacker can supply sequences like ../../../etc/passwd to traverse directories. When Api Keys are used for authorization but the endpoint does not strictly separate authentication from authorization logic, a key value might be logged, stored, or reflected in error messages, inadvertently exposing secrets. Worse, if the key itself is used to derive a file path—such as storing per-key artifacts in a directory named after the key—an attacker who can guess or leak one valid key might traverse out of that key’s intended directory to access other keys or system files.

For example, an endpoint like /files/:key/:filename might resolve key to a directory and then append filename without cleaning path segments. A request with key=abc123 and filename=../../../prod/secrets.json could return files outside the intended scope. If the service logs each request with the key and the resolved path, sensitive keys may be written to logs, enabling further lateral movement. This pattern aligns with common web vulnerabilities such as OWASP API Top 10 path traversal and improper logging, and may intersect with Broken Function Level Authorization if key-based access controls are bypassed via path manipulation.

Echo Go does not inherently protect against these issues; developers must ensure path construction uses clean base directories and validates that resolved paths remain within allowed locations. MiddleBrick’s checks for Path Traversal include verifying that user input is sanitized before being used in filesystem operations and that frameworks like Echo do not inadvertently expose directory structures through error handling.

Remediation focuses on strict input validation, canonical path resolution, and separation of authentication from file access logic. Avoid using key values directly in filesystem paths, and never construct paths by simple string concatenation.

Below are two concrete, syntactically correct examples for Echo Go that demonstrate insecure patterns and their secure alternatives.

Insecure pattern: direct concatenation with key and user filename

func getFile(c echo.Context) error {
    key := c.Param("key")
    filename := c.Param("filename")
    // UNSAFE: path traversal possible
    path := filepath.Join("/var/data/"+key, filename)
    data, err := os.ReadFile(path)
    if err != nil {
        return c.String(http.StatusInternalServerError, "error reading file")
    }
    return c.Blob(http.StatusOK, "application/octet-stream", data)
}

This approach is unsafe because key and filename are concatenated into a path without ensuring the result stays within the intended directory tree. An attacker can supply ../../../otherkey/config.json as filename and escape the per-key directory.

Secure pattern: canonical base directory plus strict filename validation

func getFileSecure(c echo.Context) error {
    key := c.Param("key")
    filename := c.Param("filename")

    // Validate key format to prevent injection via key
    if !isValidKey(key) {
        return c.String(http.StatusBadRequest, "invalid key")
    }

    // Canonical base: do not concatenate key into the base path
    baseDir := "/var/data"
    // Ensure key subdirectory exists and is within baseDir
    keyDir := filepath.Join(baseDir, key)
    absBase, err := filepath.Abs(baseDir)
    if err != nil {
        return c.String(http.StatusInternalServerError, "server error")
    }
    absKeyDir, err := filepath.Abs(keyDir)
    if err != nil {
        return c.String(http.StatusInternalServerError, "server error")
    }
    // Ensure resolved key directory is within baseDir
    if !strings.HasPrefix(absKeyDir, absBase+string(os.PathSeparator)) && absKeyDir != absBase {
        return c.String(http.StatusForbidden, "access denied")
    }

    // Validate filename: allow only alphanumeric, underscore, dash, and a single dot for extension
    if !isValidFilename(filename) {
        return c.String(http.StatusBadRequest, "invalid filename")
    }

    path := filepath.Join(absKeyDir, filename)
    // Double-check that resolved path remains within key directory
    absPath, err := filepath.Abs(path)
    if err != nil {
        return c.String(http.StatusInternalServerError, "server error")
    }
    if !strings.HasPrefix(absPath, absKeyDir) {
        return c.String(http.StatusForbidden, "invalid path")
    }

    data, err := os.ReadFile(absPath)
    if err != nil {
        return c.String(http.StatusNotFound, "file not found")
    }
    return c.Blob(http.StatusOK, "application/octet-stream", data)
}

func isValidKey(key string) bool {
    // Example: allow only lowercase hex strings of fixed length
    matched, _ := regexp.MatchString(`^[a-f0-9]{32}$`, key)
    return matched
}

func isValidFilename(name string) bool {
    // Allow only safe filename characters
    matched, _ := regexp.MatchString(`^[A-Za-z0-9._-]+$`, name)
    return matched
}

In this secure version, the key is validated against a strict pattern, the base directory is resolved to an absolute path, and the final file path is verified to remain within the intended directory. Logging should avoid printing the key value or resolved paths that could leak secrets. MiddleBrick’s scans can help detect remaining path traversal risks and improper handling of Api Keys in request flows.