Comment le site proxys améliore la sécurité de votre application Web

Ce n'est un secret pour personne que les entreprises utilisent de plus en plus d'applications web à notre époque. Les applications web permettent de rationaliser les opérations de l'entreprise, d'améliorer l'efficacité et donc d'économiser des dépenses pour des tâches qui seraient autrement effectuées manuellement. Malgré leur popularité croissante, les applications web sont exposées aux risques et aux cyberattaques. Cet article donne un aperçu

Ce n'est un secret pour personne que les entreprises utilisent de plus en plus d'applications web à notre époque. Les applications web permettent de rationaliser les opérations de l'entreprise, d'améliorer l'efficacité et donc d'économiser des dépenses pour des tâches qui seraient autrement effectuées manuellement.

Malgré leur popularité croissante, les applications web sont exposées à des risques et à des cyberattaques. Cet article donne un aperçu des principales attaques auxquelles une application web est vulnérable. Vous découvrirez ensuite comment intégrer un proxy inverse pour minimiser les menaces.

Mais avant d'aborder les aspects liés à la sécurité, examinons l'architecture d'une application web typique.

Vue d'ensemble de l'architecture des applications web

Application Web

Dans la plupart des cas, les applications web se composent de serveurs web et de pages web. Les serveurs web acceptent les demandes des clients (vos navigateurs web), qu'un serveur web traite et renvoie la réponse au client.  

Alors que le côté serveur est codé à l'aide de langages de programmation dynamiques tels que PHP, Python, ASP.NET, etc., le côté client est codé à l'aide de HTML, CSS et JavaScript.

Vous pouvez vous référer à cet article pour plus d'informations sur la structure des applications web. La figure ci-dessous illustre une communication client-serveur typique.

Dans le diagramme ci-dessus, toutes les communications semblent simples, les requêtes faisant l'objet d'un va-et-vient entre le client et le serveur. Cependant, ce n'est pas toujours le cas.

Malheureusement, les applications web utilisant la conception ci-dessus sont sujettes à des cyberattaques par des personnes extérieures entre le client et le serveur.

Avant de nous pencher sur la nature de ces attaques, examinons quelques-unes des statistiques les plus passionnantes en matière de cyberattaques.

Quelles sont les principales menaces qui pèsent sur une application Web ?

Des statistiques passionnantes sur les cyberattaques

Selon les données de Positive Technologies sur les vulnérabilités des applications web en 2018, les secteurs de la finance et de la banque ont représenté 28 % de toutes les applications web attaquées. Le rapport indique également que 14 % des cyberattaques ciblent des applications en ligne dans les secteurs des télécommunications et de la fabrication, et 11 % des applications de transport.

Les institutions gouvernementales (11 %), les technologies de l'information, le commerce électronique et les médias sont également exposés à des risques.

En ce qui concerne les types d'attaques, un autre rapport, celui de F5, indique que les attaques par scripts intersites (de 4 % à 54 %) et par injection SQL (SQLi) (de 15 % à 76 %) sont en augmentation. 

Ces statistiques nous permettent de conclure que des mesures rigoureuses sont nécessaires pour protéger les applications web contre les vulnérabilités. Certaines failles de sécurité sont dues à des problèmes de codage, tandis que d'autres peuvent être dues à une infrastructure inadéquate utilisée par l'application web. C'est là qu'intervient le pare-feu d'application web (WAF), qui peut réduire les vulnérabilités en filtrant les paquets, en bloquant le trafic HTTP et la journalisation non autorisée. 

Nous l'étudierons plus en détail ci-dessous. Avant cela, un bref aperçu des principales menaces qui pèsent sur la sécurité.

Injection SQL (SQLi)

SQLi - L'injection SQL est une vulnérabilité de sécurité web qui permet à l'attaquant de manipuler les requêtes SQL qu'une application adresse à la base de données. Ce faisant, il accède à des informations potentiellement précieuses que personne ne peut atteindre facilement. 

Un exemple simple et très familier consisterait à tirer parti d'une entrée utilisateur non aseptisée à l'avantage du pirate. Supposons qu'une zone de texte demande l'identifiant de l'utilisateur. Sur la base de l'ID de l'utilisateur, la requête récupère toutes les informations appartenant à cet utilisateur.

Supposons donc que, dans la zone de texte, l'utilisateur ait saisi le texte suivant :

Id. d'utilisateur : 228 ou 1=1

La requête résultante serait alors la suivante :

SELECT * FROM Users WHERE UserId = 228 OR 1=1 ;

Il récupère ensuite toutes les données de la table de l'utilisateur, y compris les mots de passe si la table en contient.

Pour plus d'informations sur SQLi, vous pouvez vous référer à cette page.

Scripts intersites (XSS)

Un XSS se produit lorsqu'un utilisateur injecte un script malveillant, principalement en javascript, par l'intermédiaire de champs de saisie non nettoyés. En général, un attaquant envoie ce script malveillant à un utilisateur qui ne sera pas soupçonné. Le navigateur de l'utilisateur final ne sait pas que ce script est nuisible et l'exécute. 

Par conséquent, ce script malveillant peut accéder à toutes les données associées aux cookies, aux jetons de session ou à toute autre information sensible. En outre, ces scripts peuvent réécrire le code HTML d'une page web.

Authentification et gestion de session défaillantes

Supposons qu'un utilisateur doive se connecter à une application web en utilisant ses identifiants de connexion. Dans ce cas, l'algorithme propriétaire du site web génère un identifiant de session unique pour l'ensemble de la communication entre l'utilisateur et le serveur web pour cette session.

Si les développeurs web n'ont pas crypté les données sécurisées qui circulent entre l'utilisateur et le serveur web, il y a de fortes chances qu'un intrus les vole et se fasse passer pour l'utilisateur. Ce scénario se produit principalement lorsque vous vous connectez à l'internet en utilisant le WiFi public dans les cafés.

Vous pouvez vous référer à cet article pour plus de détails.

Quelles sont les méthodes pour prévenir les attaques sur le web ?

Pare-feu pour applications web

Le WAF est une défense de couche 7 dans le modèle OSI qui peut être placée au point d'entrée du serveur de destination, comme le montre le diagramme ci-dessous. Il protège le réseau interne du serveur contre les attaques et cache la topologie du réseau du serveur.

Pour que le WAF fonctionne, vous devez effectuer des configurations supplémentaires sur le serveur. Comme les pare-feu, le WAF filtre le trafic HTTP entrant et sortant qui semble dangereux pour le réseau interne du serveur s'il ne satisfait pas aux règles que vous avez définies sur le WAF.

Le WAF est également un type de proxy inverse dont nous parlerons dans la section suivante.

Proxy inversé

Le rôle d'un serveur proxy est de cacher votre adresse IP et de la remplacer par celle du serveur proxy. Un proxy inverse fait de même et renforce la sécurité du serveur web en cachant l'adresse IP ainsi que la topologie du réseau interne du serveur.

Le client ne connaît que l'adresse du serveur proxy, et le serveur réel lui est donc caché.

Idéalement, vous pouvez utiliser un proxy inverse comme un pare-feu d'application Web (WAF) dont nous avons parlé plus haut. Vous pouvez mettre en place un WAF pour les applications web sur des appareils dont le proxy inverse est configuré. Par conséquent, le champ d'application du WAF en matière de renforcement de la sécurité s'élargit. L'attaquant ne peut pas non plus voir l'emplacement réel du serveur web.

Vous pouvez vous référer à cet article pour plus d'informations fondamentales sur proxys. Dans la prochaine section, nous examinerons l'utilisation d'un proxy inverse pour atténuer les risques liés à l'application. Mais avant cela, nous allons vous donner un aperçu de ce que fait un proxy inverse.

Comment fonctionne le reverse proxy ?

Tous les sites proxys inversés effectuent les opérations fondamentales suivantes :

1. Le navigateur du client envoie une requête HTTP à une URL publique. Supposons que l'URL soit www.host.com sur le port 80.
2. Ensuite, comme d'habitude, le nom d'hôte se résout autour du serveur mandataire inverse. Ce serveur mandataire inverse écoute cette adresse et reçoit la demande.
3. Ensuite, le reverse proxy examine l'URL pour déterminer où il doit acheminer la requête. En général, un reverse proxy peut utiliser n'importe quel composant de l'URL pour décider où acheminer la requête. Par exemple, il peut utiliser l'hôte, le protocole, le chemin, le port ou la chaîne de requête. En général, le chemin d'accès est le principal composant qui décide du routage.
   1. Les paramètres de configuration du proxy inverse déterminent l'URL de sortie à laquelle la demande doit être envoyée. Cette URL sortante est généralement le serveur dorsal responsable de la fourniture du contenu. Le serveur mandataire inverse peut réécrire les parties de la demande. Il peut, par exemple, modifier ou ajouter des segments d'itinéraire.
   2. Le reverse proxy doit également mettre à jour certaines informations de l'en-tête HTTP afin d'indiquer le serveur web interne, en plus du remappage de l'URL. L'en-tête "Host :", par exemple, contient le nom d'hôte à partir duquel l'URL est demandée.
   3. Pour conclure le mappage d'URL, http://www.host.com pourrait être remappé en http://realhost.com:8080.As, vous pouvez voir dans ce cas que le nom d'hôte a changé en realhost. Le numéro de port a également été modifié en 8080.

4. Enfin, le mandataire inverse envoie la demande au serveur réel, qui la traite.
5. Après avoir traité la demande, le serveur envoie la réponse au proxy inverse.
6. Le proxy inverse effectue alors les opérations suivantes :
   1. Il modifie la réponse pour qu'elle soit envoyée correctement au client. Cela inclut le champ "Location :", qui contient l'emplacement du fichier sur le serveur.
   2. Le mandataire inverse réorganise les en-têtes et envoie finalement la réponse au client.

Comment sécuriser votre application web avec un proxy inverse

Comme notre objectif est de surmonter les cyberattaques mentionnées précédemment, le proxy inverse doit exécuter des fonctions supplémentaires en plus des étapes mentionnées ci-dessus.

Valider le contenu de la demande

Lorsqu'un client envoie une requête au serveur, le proxy inverse assainit l'entrée en la comparant à sa base de données de signatures. Les programmeurs développent ces signatures à l'aide d'expressions régulières très avancées. La décision du mandataire inverse d'autoriser la requête avec l'entrée de l'utilisateur sera uniquement basée sur l'approche du filtre de la liste de blocage et du filtre de la liste blanche.

Approche du filtre de liste noire

Le filtre de la liste noire stocke les demandes nuisibles connues. Il compare ensuite chaque demande aux entrées de la liste. S'il découvre une correspondance, il rejette la demande. Les différentes variantes d'une même agression doivent être enregistrées séparément dans la liste. Les listes noires permettent d'empêcher uniquement les agressions connues. L'exhaustivité de la liste noire contribue à son efficacité. 

Approche du filtre de liste blanche

Un filtre de liste blanche capture l'ensemble des demandes valides pour un site spécifique. Par conséquent, la liste blanche prévient les attaques en n'autorisant que les demandes connues à atteindre le serveur. Le processus de construction d'une liste blanche, en revanche, prend du temps et nécessite la connaissance de l'ensemble des demandes légitimes qu'un utilisateur peut potentiellement envoyer à un serveur. 

En outre, il peut être écrasant de créer toutes les demandes valables auprès des centaines de milliers de fournisseurs de bases de données en cas d'injection SQL.

Toute modification apportée à une application web sécurisée nécessite une mise à jour de la liste blanche. Par conséquent, la tenue d'une liste blanche alourdit la charge administrative. 

Valider le contenu de la réponse

Avant de renvoyer la réponse du serveur au client, le mandataire inverse la valide. Une liste noire est généralement utilisée à cet effet. Le filtre de la liste noire peut cacher des réponses connues aux clients qui n'ont pas besoin de les voir. Les messages d'erreur sont un exemple de ce type de données ; le reverse proxy peut remplacer l'erreur par un message d'erreur générique ne contenant aucune donnée sensible.

Enregistrement des demandes et des réponses

Le reverse proxy peut également enregistrer la demande pour un examen ultérieur. La meilleure approche consiste à configurer la journalisation uniquement pour les demandes que le mandataire inverse a bloquées dans un premier temps. Il est conseillé d'examiner attentivement les journaux au cours des premières étapes de l'installation. C'est essentiel pour vérifier que le mandataire inverse ne bloque pas les demandes authentiques.

Conclusion

Dans cet article, nous espérons que vous comprendrez les vulnérabilités d'une application web et comment vous pouvez utiliser un reverse proxy pour résoudre ces menaces. En effet, le reverse proxy n'éliminera pas toutes les vulnérabilités possibles associées aux applications web.

Cependant, ce serait une excellente stratégie pour atténuer la plupart des menaces que vous rencontrez dans une application web. Enfin, nous espérons que vous appliquerez les concepts présentés dans cet article si vous rencontrez des problèmes de sécurité dans votre application web.