Portail / Sujets autour de la programmation / Programmation C/C++ sous Linux / Serveur d'application avec Qt 6 / Documentation technique(Sommaire)

Organisation du code de lancement du serveur d'application.

Mise à jour du 05/08/2024.

La réalisation d'un programme capable de lancer plusieurs applications comporte plusieurs étapes qui doivent être exécutées dans un ordre précis. Cet aricle vise à décrire cet ordre. Le serveur lui-même s'articule autour de la classe WebServer.

Etapes du codage du serveur d'application.

• Construction des applications supportées par le serveur d'application. Chaque application est représentée par un objet de classe WebApp.
• Pour chaque application, construction des services à invoquer et enregsitrement de chacun d'eux auprès de l'application via la méthode WebApp::insertService()
• Création de l'agent de sécurité chargé de contrôller la validité des URL reçus. Cet agent est notamment chargé de charger les règles dites "externes" qui interdit les requêtes dont l'URL ou les paramètres répondent à une expression régulière. Ces règles de sécurité sont à charger depuis le fichier de la configuration du serveur.
• Construction du serveur Web support des applications. Il s'agit d'un objet de classe WebServer. Le fichier de configuration du serveur est transmis au constructeur de cette classe.
• Enregistement de chaque application auprès du serveur via la méthode insertApp de ce dernier.
• Lancement de l'écoute du serveur (méthode WebServer::listen()). Notez que l'écoute ne peut se faire que sur la base du protocole HTTPS ce qui impose de disposer d'un certificat X.509 et de sa clef privée.

Construction de chaque application.

Chaque application dispose de son propre fichier de configuration. Toutefois, cette configuration n'est pas prise en compte lors de la construction de l'objet "application". Une fois la construction de la classe WebApp terminée, il faut invoquer impérativement la méthode init(). C'est cette classe qui permet, entre autres, de charger les paramètres de configuration et de préciser à l'application auprès de quel serveur elle est enregistrée.

Rôle de l'agent de sécurité.

Toute requête HTTP reçue par le serveur est analysée par un agent de sécurité en vue :

• de vérifier que la méthode HTTP transmise est soit GET, soit POST ;
• de vérifier la validité syntaxique de l'URL ;
• de vérifier l'absence de caractères illégaux dans l'URL ou la liste des paramètres. Le jeu des caractères autorisé est celui des caractères du codage Base64 augmenté de quelques uns :

  &()+-./0123456789=ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz

• de vérifier que le débit des requêtes est inférieur à 20 requêtes par seconde ;
• de vérifier que l'URL ainsi que la liste des paramètres ne rentrent pas en correspondance avec une des règles de filtrage par expression régulière.

La librairie webapp fournit un agent de sécurité par défaut.

L'agent de sécurité exerce un contrôle "amont" des requêtes HTTP, c'est à dire que ce contrôle est exercé avant leur interprétation par le serveur d'application. Le fait de tracer les requêtes refusées peut ne pas être suffisant. Tout d'abord, cela consomme de la ressource et certains attaquants n'hésitent pas à émettre des centaines de requêtes en espérant faire "bonne pioche".

Pour bloquer les adresses IP à l'origne de requêtes refusées, il est possible de dériver la classe SecurityAgent et de surcharger les méthodes virtuelles trace(). Sous Linux par exemple, on peut ajouter ces adresses IP à un jeu de blocage de la commande ipset pris en compte par les règles de la commande iptables. Notez qu'il est recommandé lorsque l'on utilise ce type de mécanisme de créer une "liste blanche" d'adresses IP non blocables (cela évite de se bloquer soi-même ou les stations de son organisation).

Sous d'autres systèmes moins souples comme Windows, on peut créer un programme dédié charger de surveiller les modifications du fichier des adresses bloquées pour les convertir en règles de pare-feu via un script ou tout autre moyen.

Cette capacité permet d'identifier et filtrer les "intrus" cherchant à pirater votre serveur tout en les bloqant dès leur première demande.

Pour aller plus loin.

Un article est dédié à l'agent de sécurité fourni par la librairie. Vous pouvez réaliser le votre par héritage de la classe SecurityAgent.