Qu’est-ce qu’Azure Web Application Firewall ?
Vous allez découvrir ici les bases d’Azure Web Application Firewall. Cette vue d’ensemble vous permettra de déterminer si Azure Web Application Firewall est un outil qu’il convient d’ajouter à la stratégie globale de sécurité réseau de Contoso.
Vue d’ensemble d’Azure Web Application Firewall
Vous pensez peut-être que les utilisateurs malveillants ne se soucient pas de vos applications web. Toutefois, des tests indiquent que les nouvelles applications web sont analysées par des bots ou des utilisateurs malveillants à la recherche de points faibles dans les minutes suivant leur déploiement. Si vous placez une application sur le web, vous devez partir du principe qu’elle va être testée presque immédiatement par des auteurs de menaces à l’affût de vulnérabilités. Attendez-vous également à ce que ces tests se poursuivent pendant toute la durée de vie de l’application.
La plupart des tests malveillants ciblant des applications web cherchent à détecter une ou plusieurs vulnérabilités courantes. Si une vulnérabilité est trouvée, un auteur de menaces utiliser ces vulnérabilités pour effectuer des attaques comme les codes malveillants exploitant une faille de sécurité suivants :
- injection SQL
- Attaque par scripts intersites (XSS)
- Inclusion de fichiers locaux et distants
- Saturations HTTP/HTTPS
- Attaques de bot malveillantes
Dans le cycle de développement d’une application web, l’écriture de code pour boucher les failles de sécurité les plus courantes est une tâche commune. L’écriture du code de sécurité nécessite du temps, de l’expertise et des tests.
Azure Web Application Firewall est un service Azure qui offre une protection centralisée aux applications web hébergées sur Azure. Azure Web Application Firewall protège les applications web contre les menaces courantes telles que l’injection de code SQL et le scripting inter-site.
Vous pouvez déployer Azure Web Application Firewall en quelques minutes. Vos applications web bénéficient immédiatement d’une protection efficace contre les menaces connues, sans que vous ayez besoin d’écrire une seule ligne de code de sécurité.
Fonctionnalités clés d’Azure Web Application Firewall
Pour vous aider à évaluer Azure Web Application Firewall, voici quelques-unes des fonctionnalités importantes :
Règles managées : les règles utilisées par Azure Web Application Firewall pour détecter et empêcher les codes malveillants exploitant une faille de sécurité courants sont créées, gérées et mises à jour par l’équipe de sécurité de Microsoft. En cas de modification d’une règle ou d’un ensemble de règles (voir description suivante), Microsoft met à jour Azure Web Application Firewall de façon automatique et transparente.
Notes
Vous ne pouvez pas modifier ni supprimer les règles managées offertes par Azure Web Application Firewall. Toutefois, si une règle particulière pose problème dans votre environnement (par exemple, si elle bloque le trafic légitime vers votre application web), vous pouvez créer des exclusions ou désactiver la règle ou l’ensemble de règles. Vous pouvez également créer des règles personnalisées pour remplacer le comportement par défaut.
Règles de bot : les règles de bot identifient les bons bots et protègent des mauvais bots. Les mauvais bots sont détectés par Microsoft Threat Intelligence.
Règles personnalisées : si les règles managées offertes par Azure Web Application Firewall ne couvrent pas une menace spécifique pour votre application web, vous pouvez créer une règle personnalisée.
Modes : Azure Web Application Firewall peut fonctionner dans un des deux modes suivants : le mode détection consigne seulement les requêtes qui violent une règle, tandis que le mode prévention consigne et bloque les requêtes qui violent une règle.
Listes d’exclusions : vous pouvez configurer Azure Web Application Firewall pour qu’il ignore des attributs spécifiques quand il vérifie des requêtes.
Stratégies : une stratégie Azure Web Application Firewall vous permet de combiner un ensemble de règles managées, de règles personnalisées, d’exclusions et d’autres paramètres d’Azure Web Application Firewall. Vous pouvez ensuite appliquer cette stratégie à plusieurs applications web pour faciliter la gestion et la maintenance.
Limites de taille des requêtes : vous pouvez configurer Azure Web Application Firewall pour qu’il signale les requêtes trop petites ou trop grandes.
Alertes : Azure Web Application Firewall s’intègre à Azure Monitor. Cette intégration vous permet d’obtenir des alertes en quasi-temps réel quand le pare-feu d’applications web détecte une menace.
Attaques courantes bloquées par Azure Web Application Firewall
Le tableau suivant décrit les menaces malveillantes les plus courantes contre lesquelles Azure Web Application Firewall vous protège.
| Menace | Description |
|---|---|
| Attaque par scripts intersites (XSS) | Un auteur de menaces utilise une application web pour envoyer du code malveillant au navigateur web d’un autre utilisateur. Le navigateur exécute le code, lequel donne au script l’accès aux données de session, aux cookies et à d’autres informations sensibles appartenant à l’utilisateur. |
| Inclusion de fichier local (LFI) | Un attaquant exploite les vulnérabilités liées au traitement par un serveur des instructions include, le plus souvent dans des scripts PHP. En passant un texte spécialement configuré à l’instruction include d’un script, l’attaquant peut inclure des fichiers qui sont présents localement sur le serveur. L’attaquant peut alors accéder à des informations sensibles et exécuter des commandes serveur. |
| Injection de code PHP | L’attaquant insère un texte spécialement configuré pour amener le serveur à exécuter des commandes PHP. Ces commandes permettent à l’attaquant d’exécuter du code PHP local ou distant. L’attaquant peut alors accéder à des données sensibles et exécuter des commandes sur le serveur. |
| Attaques de protocole | Un attaquant insère un texte spécialement configuré dans un en-tête de requête HTTP/HTTPS. En fonction du texte spécifique injecté dans l’en-tête, l’attaquant peut amener le serveur à afficher des données sensibles ou à exécuter du code. |
| Exécution de commande à distance | L’attaquant amène un serveur à exécuter des commandes associées au système d’exploitation du serveur. Par exemple, sur un système UNIX, l’attaquant peut demander au serveur d’exécuter ls pour obtenir une liste de répertoires. |
| Attaque par inclusion de fichier distant | Identique à l’inclusion de fichier local, à la différence près que l’attaquant envoie au serveur un texte spécialement configuré qui passe un fichier distant, c’est-à-dire un fichier situé sur un serveur distant contrôlé par l’attaquant, à l’instruction include d’un script. |
| Fixation de session | Un attaquant exploite une vulnérabilité d’application web qui lui permet d’obtenir un ID de session valide. L’attaquant amène un utilisateur à authentifier une nouvelle session avec cet ID. L’attaquant détourne ensuite cette session validée par l’utilisateur. |
| injection SQL | Dans un champ de formulaire web, l’attaquant insère (ou « injecte ») un texte spécialement configuré pour amener le serveur à exécuter des commandes SQL. Ces commandes permettent à l’attaquant d’accéder aux données sensibles, d’insérer, de mettre à jour ou de supprimer des données, ou encore d’exécuter des opérations SQL. |
Tous les codes malveillants exploitant une faille de sécurité listés dans le tableau précédent ne sont possibles que si le serveur fait confiance aux entrées qu’il reçoit. Il serait difficile et fastidieux d’écrire le code nécessaire pour rechercher et assainir ne serait-ce que ces exploits. En effet, seule une fraction des exploits qu’une application web peut rencontrer figurent dans le tableau précédent. Azure Web Application Firewall est conçu pour empêcher ces attaques et bien d’autres.
Assainissement des entrées
Les menaces auxquelles font face les applications web modernes sont variées et sophistiquées. Toutefois, dans la plupart des cas, un exploit aboutit parce que l’application web fait implicitement confiance aux entrées qu’elle reçoit.
Prenons par exemple un formulaire web qui permet à un utilisateur autorisé d’une application web de se connecter à son compte. Le formulaire comprend uniquement trois éléments :
- Une zone de texte Nom d’utilisateur
- Une zone de texte Mot de passe
- Un bouton Connexion
Quand un utilisateur autorisé remplit le formulaire et sélectionne Connexion, un script d’application web stocke le nom d’utilisateur et le mot de passe dans des variables. Supposons que ces variables soient nommées userName et userPassword, respectivement. Le script exécute ensuite l’instruction suivante :
sql = "SELECT * FROM users WHERE username='" + userName + "' AND password='" + userPassword + "'"
Par exemple, si le nom d’utilisateur est support et que le mot de passe est 1234ABCD, la variable sql a la valeur suivante :
SELECT * FROM users WHERE username='support' AND password='1234ABCD'
L’application web exécute cette instruction SQL. Si la requête retourne un enregistrement, l’application web connecte l’utilisateur.
Supposons à présent qu’un attaquant entre admin'-- dans le champ Nom d’utilisateur et laisse le champ Mot de passe vide. Dans ce cas, l’instruction SQL résultante est la suivante :
SELECT * FROM users WHERE username='admin'--' AND password=''
Sur de nombreux systèmes SQL, les tirets doubles (--) marquent le début d’un commentaire. Tout ce qui se trouve après -- étant ignoré, l’instruction précédente est équivalente au code suivant :
SELECT * FROM users WHERE username='admin'
Si un utilisateur nommé admin existe, cette commande connecte l’attaquant en tant qu’utilisateur administrateur, ce qui constitue une violation grave !
L’exemple précédent est une instance d’un code malveillant exploitant une faille de sécurité appelé injection de code SQL. Les attaquants peuvent tirer parti de l’injection de code SQL et d’autres exploits dans les applications web qui font confiance à toutes les entrées.
Azure Web Application Firewall crée une barrière de non-confiance entre une application web et ses entrées utilisateur. Il part du principe que toutes les entrées sont potentiellement malveillantes et assainit donc ces entrées.
L’assainissement des entrées peut avoir une signification différente selon le contexte. Par exemple, l’assainissement des entrées peut signifier la suppression d’éléments de texte clairement dangereux, comme les indicateurs de commentaire SQL. Quelle que soit le mode d’assainissement, les entrées résultantes ne peuvent nuire ni à l’application web ni à ses données de back-end.