kcgi : sécuriser une application web en C

Pourquoi choisir une bibliothèque dédiée ?

Au début, une application web en C peut sembler presque triviale : lire des variables d'environnement, analyser une chaîne, écrire quelques en-têtes et renvoyer du texte. Le problème arrive vite quand il faut couvrir plusieurs méthodes HTTP, gérer les encodages, les cookies, les corps de requête, et les cas invalides. Les erreurs « isolées » finissent par coûter cher : en maintenance, mais aussi parce qu'elles deviennent une surface d'attaque.

Une bibliothèque dédiée apporte une structure commune et des fonctions documentées pour ces opérations. Avec kcgi, le parsing de la requête passe par khttp_parse en CGI. En FastCGI, l'initialisation et le traitement sont séparés entre khttp_fcgi_init et khttp_fcgi_parse.

Pour la référence, on s'appuie sur les pages de manuel, notamment kcgi(3). Sur un projet réel, elles comptent plus qu'un extrait de code : elles précisent les contrats des fonctions, les paramètres et le cycle de vie des requêtes.

Pour quels projets est-ce adapté ?

kcgi vaut le coup si votre équipe travaille déjà en C ou en C++, si votre cible de déploiement est compatible avec CGI ou FastCGI, et si isoler le traitement d'entrées non fiables fait partie de vos exigences. La bibliothèque a été portée sur plusieurs Unix, dont GNU/Linux, les BSD, Solaris et macOS.

En revanche, c'est moins intéressant si votre objectif principal est de livrer rapidement un service web « standard », sans contrainte liée au langage. Dans ce cas, le coût d'exploitation (et le recrutement autour de la pile C) peut dépasser le bénéfice. Le bon critère, ce n'est pas le prestige technique : c'est l'adéquation entre vos compétences, votre modèle d'hébergement, vos besoins de sécurité et la durée de vie du service.

Séparer le parsing du traitement métier

Le flux logique ressemble à ceci :

1. Le serveur web transmet une requête CGI ou FastCGI.
2. kcgi analyse les données HTTP et applique les validations dans le contexte sandboxé.
3. Les éléments traités sont envoyés au processus parent.
4. L'application exécute la logique métier et construit la réponse.
5. La requête est libérée avec khttp_free.

Cette séparation demande un minimum de discipline. Les validations faites dans le processus sandboxé doivent rester prévisibles, sans s'appuyer sur des ressources externes. Si une validation doit ouvrir un fichier, contacter un service réseau ou consulter un état système, ça risque de ne pas coller aux restrictions du sandbox. Dans ce cas, séparez clairement la validation « syntaxique » de la validation « métier » qui dépend de l'environnement.

Par exemple : vérifier qu'un identifiant ne contient que des caractères autorisés, c'est une validation locale. Vérifier ensuite que cet identifiant correspond à un compte actif dans une base de données, c'est autre chose : ça dépend d'un service externe et des règles d'autorisation.

Ce que le sandbox ne règle pas

Le sandboxing ne remplace pas l'échappement des sorties, le contrôle des droits, ni la protection contre les erreurs métier. Même si la valeur est correctement analysée, elle peut rester dangereuse si vous l'insérez sans précaution dans du HTML, une commande ou une requête SQL. De la même façon, une requête valide côté HTTP peut demander une action que l'utilisateur n'a pas le droit de faire.

Donc, il faut garder une approche en couches :

• Parser les données avec une bibliothèque éprouvée.
• Valider leur format et leurs limites.
• Autoriser l'action selon l'identité et le contexte.
• Échapper/encoder selon la destination.
• Limiter les privilèges du processus et les dépendances.
• Tester les erreurs, pas seulement le scénario nominal.

Pour aller plus loin sur ces réflexes, vous pouvez aussi consulter la sécurisation d'une application web et la validation des entrées côté serveur. L'isolation apportée par kcgi complète ces pratiques, elle ne les remplace pas.

Compiler et lier le programme

Une fois la bibliothèque installée, pkg-config vous aide à récupérer les options de compilation et d'édition de liens :

cc `pkg-config --cflags kcgi` -c votreprogramme.c
cc votreprogramme.o `pkg-config --libs kcgi` -o votreprogramme

Le détail peut changer selon votre environnement, mais l'objectif reste le même : éviter de recopier à la main les chemins d'inclusion et les bibliothèques nécessaires. Sur un projet maintenu, gardez ces options dans votre système de build, pas dans des commandes éparpillées.

Certains serveurs web tournent dans un chroot. Dans ce scénario, un binaire dynamique peut ne pas trouver ses bibliothèques partagées dans l'environnement isolé. Deux options : intégrer les bibliothèques dans la racine du service, ou produire un binaire statique si la plateforme et votre politique de distribution le permettent. La liaison statique peut simplifier le déploiement, mais elle complique aussi la gestion des mises à jour. Choisissez selon votre mode d'exploitation, pas « par défaut ».

Le cycle de vie d'une réponse CGI

Voici un exemple minimal inspiré de la documentation. Il déclare une page connue, analyse la requête, écrit les en-têtes HTTP, démarre le corps de réponse, puis libère les ressources :

#include <sys/types.h>
#include <stdarg.h>
#include <stddef.h>
#include <stdint.h>
#include <kcgi.h>
int main(void) {
struct kreq r;
const char *page = "index";
if (khttp_parse(&r, NULL, 0, &page, 1, 0) != KCGI_OK)
return 1;
khttp_head(&r, kresps[KRESP_STATUS], "%s", khttps[KHTTP_200]);
khttp_head(&r, kresps[KRESP_CONTENT_TYPE], "%s",
kmimetypes[KMIME_TEXT_PLAIN]);
khttp_body(&r);
khttp_puts(&r, "Bonjour, monde !");
khttp_free(&r);
return 0;
}

L'exemple est volontairement minimal : il ne valide pas de champs utilisateurs et renvoie toujours une réponse texte. Dans une vraie application, vous devrez gérer les méthodes HTTP, les routes demandées, les erreurs de parsing et le type de contenu. L'ordre compte : les en-têtes doivent être émis avant d'appeler khttp_body.

Le projet fournit aussi des exemples C++, CGI et FastCGI. Pour une intégration réelle, partez de l'exemple correspondant au mode de déploiement choisi, au lieu de transposer mécaniquement ce CGI minimal.

CGI ou FastCGI : choisir le bon mode

En CGI, le serveur web lance un processus pour traiter une requête. C'est simple à intégrer, mais le coût de création et d'arrêt des processus peut vite devenir un facteur limitant sous charge. En FastCGI, un processus (ou un gestionnaire) peut traiter plusieurs requêtes : le coût et le cycle de vie du service changent du tout au tout.

Le bon choix dépend donc de l'architecture d'hébergement. Certains serveurs lancent directement les applications FastCGI ; d'autres passent par un gestionnaire externe. La documentation kcgi mentionne notamment des déploiements avec Apache, nginx et httpd(8) d'OpenBSD. Avec ce dernier, FastCGI peut être associé à kfcgi(8) ou au wrapper slowcgi, selon le montage.

Ne comparez pas CGI et FastCGI uniquement sur le nombre de requêtes par seconde. Regardez aussi la supervision, le redémarrage, l'isolation, la configuration des sockets, la qualité des journaux et la façon dont les secrets sont transmis. Une option « plus rapide » sur le papier peut coûter plus cher à exploiter si l'équipe ne maîtrise pas le cycle de vie.

Le prix de la sécurité et les points de contrôle

Isoler le parsing sandboxé a un coût. kcgi doit créer un processus enfant, appliquer les restrictions de la plateforme, puis transmettre au parent les éléments analysés. En CGI, la création et la récupération de processus peuvent peser. En FastCGI, le transfert des données devient un point à mesurer.

Il n'y a pas de formule magique universelle. Les performances dépendent du système, du serveur web, de la taille des requêtes, de la fréquence des appels et du travail effectué après le parsing. Le mieux est de mesurer sur votre cible de production avec des données représentatives. Un test local sur une machine de développement ne suffit pas pour estimer le comportement sous charge.

Avant de passer en production, vérifiez au minimum :

• la version de la bibliothèque et la provenance des paquets ou des archives ;
• la vérification de l'archive si vous compilez depuis les sources ;
• le serveur web et le mode CGI/FastCGI réellement configurés ;
• les restrictions effectivement appliquées au processus sandboxé ;
• le comportement en cas de requête invalide, de timeout ou d'échec du processus ;
• la journalisation, la supervision et la stratégie de redémarrage ;
• les résultats des tests de régression et, si pertinent, du fuzzing ;
• les performances mesurées avec le trafic et les tailles de requêtes attendus.

Au final, la décision est pragmatique : si l'isolation des entrées non fiables répond à un risque concret et que votre équipe sait exploiter la pile, le surcoût peut être justifié. Si vous n'avez ni contrainte C/C++ ni exigences spécifiques de déploiement, une autre approche sera souvent plus simple à maintenir. La sécurité « utile » est celle que vous pouvez vérifier, exploiter et faire évoluer.