HIGH command injectionchibasic auth

Command Injection in Chi with Basic Auth

Command Injection in Chi with Basic Auth — how this specific combination creates or exposes the vulnerability

Command Injection occurs when an attacker can cause an application to execute unintended system commands. In the Chi framework, this typically arises when user input is passed to shell commands without proper validation or escaping. When Basic Authentication is used, credentials are transmitted in the Authorization header as base64-encoded username:password. While base64 is not encryption, the presence of Basic Auth may encourage developers to treat the endpoint as "internal" or "authenticated," leading to insufficient input validation on parameters that are later used in command execution.

Chi is a lightweight HTTP router for Go that does not inherently provide command injection protections; developers must ensure that any external data used in command construction is sanitized. A vulnerable pattern looks like:

import (
    "net/http"
    "os/exec"
    "strings"
)

func handler(w http.ResponseWriter, r *http.Request) {
    user := r.URL.Query().Get("user")
    cmd := exec.Command("sh", "-c", "echo hello "+user)
    out, _ := cmd.Output()
    w.Write(out)
}

An attacker could supply user as ; cat /etc/passwd and achieve command injection. If the same endpoint is protected only by Basic Auth, an attacker who obtains or guesses a valid credential pair can repeatedly probe the endpoint, increasing the likelihood of discovering such a flaw. middleBrick scans this unauthenticated attack surface by testing inputs across the 12 security checks, including Unsafe Consumption and Input Validation, to detect whether user-controlled data reaches the command execution layer.

Because Basic Auth sends credentials in every request, automated scanners can reliably authenticate and then test authenticated behavior, exercising code paths that are otherwise hidden. This combination means a command injection vulnerability behind Basic Auth may remain undetected if testing does not validate both authentication correctness and input handling. middleBrick performs active probe sequences and output scanning to identify whether injected commands alter behavior or leak unintended data, regardless of the authentication wrapper.

Basic Auth-Specific Remediation in Chi — concrete code fixes

To remediate command injection in Chi when Basic Auth is used, avoid constructing shell commands with user input entirely. If shell commands are necessary, use Go’s exec package without a shell, and strictly validate and whitelist inputs. Below are two concrete approaches with code examples.

1. Avoid the shell and pass arguments directly

By not invoking a shell, metacharacters such as ;, &, or | lose their special meaning, preventing injection.

import (
    "net/http"
    "os/exec"
)

func safeHandler(w http.ResponseWriter, r *http.Request) {
    user := r.URL.Query().Get("user")
    // Validate input: allow only alphanumeric and limited symbols
    if user == "" || !regexp.MustCompile(`^[a-zA-Z0-9_-]+$`).MatchString(user) {
        http.Error(w, "invalid user", http.StatusBadRequest)
        return
    }
    // Execute without shell: arguments are passed directly, no parsing by shell
    cmd := exec.Command("echo", "hello", user)
    out, err := cmd.Output()
    if err != nil {
        http.Error(w, "command failed", http.StatusInternalServerError)
        return
    }
    w.Write(out)
}

2. Use an allowlist for commands and parameters

If you must invoke functionality that resembles command-like behavior, map user input to predefined internal actions rather than constructing dynamic commands.

import (
    "net/http"
)

func mappedHandler(w http.ResponseWriter, r *http.Request) {
    action := r.URL.Query().Get("action")
    // Basic Auth can be extracted and verified here if needed
    // For example: user, pass, ok := r.BasicAuth(); validateUser(user, pass)
    switch action {
    case "status", "health", "version":
        // Execute internal logic, no shell involved
        w.Write([]byte("ok: " + action))
    default:
        http.Error(w, "unknown action", http.StatusBadRequest)
    }
}

For authentication, use r.BasicAuth() and validate credentials against a secure store. Do not rely on the presence of Basic Auth alone to protect against injection; treat it as transport-layer identity and enforce input controls independently.

middleBrick’s Authentication and Unsafe Consumption checks can validate whether your Chi endpoints correctly handle credentials and whether inputs reach command execution paths. The CLI (middlebrick scan <url>) and Web Dashboard allow you to track these findings and iterate on fixes, while the GitHub Action can enforce a minimum score before merging changes that involve sensitive endpoints.

Related CWEs: inputValidation

CWE IDNameSeverity
CWE-20Improper Input Validation HIGH
CWE-22Path Traversal HIGH
CWE-74Injection CRITICAL
CWE-77Command Injection CRITICAL
CWE-78OS Command Injection CRITICAL
CWE-79Cross-site Scripting (XSS) HIGH
CWE-89SQL Injection CRITICAL
CWE-90LDAP Injection HIGH
CWE-91XML Injection HIGH
CWE-94Code Injection CRITICAL

Frequently Asked Questions

Does using Basic Auth in Chi prevent command injection?
No. Basic Auth only provides transport-layer identity; it does not sanitize inputs. Command injection depends on how the application uses user-controlled data, so validation and safe execution patterns are required regardless of authentication.
Can middleBrick detect command injection behind Basic Auth?
Yes. middleBrick tests the unauthenticated attack surface and, when configured with credentials, can exercise authenticated paths. Its Unsafe Consumption and Input Validation checks identify whether user input propagates into command execution, even when protected by Basic Auth.