Web application firewall

Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.
Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.

Cet article contient une ou plusieurs listes ().

Ces listes gagneraient à être rédigées sous la forme de paragraphes synthétiques, plus agréables à la lecture, les listes pouvant être aussi introduites par une partie rédigée et sourcée, de façon à bien resituer les différents items.
D'autre part, Wikipédia n'a pas pour rôle de constituer une base de données et privilégie un contenu encyclopédique plutôt que la recherche de l'exhaustivité.

Un Web Application Firewall (WAF) est un type de pare-feu qui protège le serveur d'applications Web dans le backend contre diverses attaques. Le WAF garantit que la sécurité du serveur Web n'est pas compromise en examinant les paquets de requête HTTP / HTTPS et les modèles de trafic Web.

Web Application Firewall Architecture.

Définition

Un Web Application Firewall (WAF) est un type de pare-feu qui vérifie les données des paquets afin de protéger la couche application du modèle OSI,,. Dans l'architecture globale du système (serveur web), un WAF est placé avant l'application Web qui doit être protégée. Chaque demande envoyée est d'abord examinée par le WAF avant qu'elle n'atteigne l'application Web. Si cette demande est conforme à l'ensemble de règles du pare-feu, ce dernier peut alors transmettre la demande à l'application. D'une manière générale, un WAF peut être défini comme une politique de sécurité mise en place entre une application web et l'utilisateur final.

Les fonctionnalités qu'il apporte peuvent être implémentées en logiciel ou en matériel. En software, cela se résume souvent à une application installée sur un système d'exploitation tandis qu'en hardware, ces fonctionnalités sont intégrées dans une solution d'appliance. La principale tâche d'un WAF est donc de protéger les programmes web sans les modifier.

Les caractéristiques du WAF

Habituellement, le choix d'un WAF devrait être utilisé pour les caractéristiques attendues, les performances et les environnements.

Liste des caractéristiques du WAF :

Les menaces liées aux applications web

Article principal : Injection de code dans les applications web.

Les serveurs Web sont la source d'information et l'endroit où les informations sont stockées. Ces serveurs Web fournissent au client, sur demande, des données telles que des pages Web, des images, des vidéos et d'autres types de données. En raison du rôle important joué par un serveur, il fait l'objet d'attaques malveillantes perpétrées par des parties et/ou des entités hostiles. Les objectifs habituels de ces attaques vont de la perturbation de la fonction et de la disponibilité du serveur Web à l'accès non autorisé au contenu Web hébergé.

Injection SQL

L'injection SQL est l'une des vulnérabilités les plus dévastatrices qui affecte les systèmes de gestion de bases de données car elle peut conduire à l'exposition de toutes les informations sensibles stockées dans la base de données d'une application. Toutes les requêtes SQL peuvent être utilisées efficacement pour exploiter la logique d'application Web pour accéder à la base de données. L'injection SQL est la plupart du temps le résultat de validations d'entrées insuffisantes. Ce type d'attaque est généralement injectée via des zones de texte qui transmettent des données à l'application Web via des requêtes Web ou parfois en utilisant des URL.

Tautologie ou Injection d'évaluation vraie

L'attaque de tautologie est souvent utilisée en raison de sa simplicité. Le but de l'attaque basée sur la tautologie est principalement de contourner la certification, d'extraire les données ou de découvrir une vulnérabilité peut être injecté.

Exemple :

SELECT * FROM member WHERE field='$1'

Si le code ne contrôle pas la valeur $1 saisie, un utilisateur mal intentionné peut passer comme valeur ' OR 1=1 ;-- qui cause l'exécution du code suivant :

SELECT * FROM member WHERE field='' OR 1=1 ;--'

Dans la requête ci-dessus, 1 = 1 sera toujours vrai. les deux tirets permettent de mettre la quote fermante en commentaires. Si l'application ne valide pas la saisie de l'utilisateur correctement, tous les enregistrements de la base de données seront récupérées par cette requête.

Requêtes illégales ou logiquement incorrectes

Dans ce type d'attaque, l'attaquant injecte des déclarations dans le but de provoquer une erreur de syntaxe ou une erreur logique. Ces erreurs peuvent révéler des informations précieuses sur le type et la structure du backend de la base de données de l'application web. Et aidera l'attaquant à identifier les paramètres injectables. Les erreurs de syntaxe peuvent être utilisées pour déduire les types de données de certaines colonnes ou extraire des données. Les erreurs logiques disent souvent à l'attaquant le nom des tables et colonnes dans la base de données.

Exemple :

SELECT name FROM accounts WHERE member_password='/1'

Requêtes Piggy-Backed

Dans ce type d'attaques, l'attaquant ajoute une requête supplémentaire à la requête originale.

Exemple :

SELECT * FROM members WHERE member_username='admin' and member_password='admin'; DROP TABLE users --

Requête UNION

Cette attaque utilise l'opérateur de l'union qui est effectué permet lier deux ou plusieurs requêtes.

Exemple :

SELECT * FROM members WHERE member_username='user123' UNION SELECT * FROM members WHERE member_username='admin' -- AND member_password=’’

Altération de l'encodage

Dans cette technique, les attaquants modifient la requête d'injection en utilisant un encodage alternatif. Cette attaque modifie le texte injecté sans changer le but de la commande initiale. Les encodages les plus utilisés sont l'hexadécimal, l'ASCII et l'Unicode.

Exemple :

SELECT * FROM members WHERE member_user='user' AND
member_password='user';EXEC(CHAR(0x7368757466J77e))

Cross-site scripting (XSS)

Dans les attaques XSS, l'attaquant tente d'injecter un script côté client sur le serveur distant. XSS attaque généralement le code HTML de la page Web en cours de chargement. ActiveX, JavaScript peut être affecté par cette attaque. XSS peut révéler des informations sur les cookies. Les scripts peuvent être hébergés quelque part par l'attaquant. L'attaquant fournit un lien vers les utilisateurs qui semble authentique, mais a un code de script malveillant. Une fois que l'utilisateur atteint le script de liaison exécuté sur la machine du client, l'attaquant peut obtenir des informations vitales,,.

XSS non persistant

Dans ce type d'attaque, le script d'attaque est conservé ailleurs que sur le serveur de base de données de l'application Web. Ces scripts malveillants sont mis à la disposition des utilisateurs de telle sorte que l'utilisateur semble légitime. Une fois ce script touché, le pirate peut accéder aux informations de l'utilisateur,.

XSS persistant

Comme son nom l'indique, une attaque XSS persistante stocke le script ambigu sur des périphériques secondaires d'application Web, tels qu'une base de données d'application Web à trois niveaux. Ce type d'attaque est possible lorsque l'application web permet à l'utilisateur de stocker des informations telles que des commentaires, des sections de blog, etc. qui sont également visibles par les autres utilisateurs. Le détournement de session peut être effectué en utilisant XSS persistant.

La protection des WAFs face aux menaces liées aux applications web

Les WAFs constituent un mécanisme indispensable conçu pour empêcher certains types d'attaques, tels que l'injection SQL ou le script XSS. Une fois déployé, un WAF examine chaque demande soumise à un système cible pour décider si elle est légitime ou malveillante[réf. incomplète]. Le WAF prend une décision en effectuant un contrôle d'accès en temps réel en se basant sur les informations telles que les URL, les paramètres envoyés ainsi que l'historique de session de l'utilisateur et en vérifiant si la valeur correspond ou non à un modèle d'attaque, en utilisant typiquement un ensemble de règles (par exemple, des expressions régulières),.

Le WAF peut utiliser soit une liste blanche (un modèle de sécurité positif) ou soit une liste noire (un modèle de sécurité négatif) pour prendre ces décisions. Dans le modèle de sécurité positif, le contrôle d'accès est basé sur des comportements positifs connus. Ces comportements peuvent être construits manuellement par l'administrateur ou bien produit automatiquement en observant un trafic réseau légitime. Le modèle de sécurité négatif permet quant à lui de rejeter les requêtes reflétant un trafic dangereux.

Le WAF est donc une méthode pour se protéger de ces genres d'attaques.

Protection contre les SQLi (Injections SQL)

Les WAFs protègent la base de données de l'application en inspectant le trafic HTTP et en appliquant un ensemble de règles de sécurité. Le langage utilisé pour exprimer les règles de sécurité peut explicitement décrire une signature d'une attaque par injection SQL, ou implicitement décrire la façon de détecter ces attaques. Il peut également exprimer une valeur de score d'anomalie qui augmente chaque fois qu'un motif malveillant apparaît dans une requête HTTP. Si la valeur de l'anomalie atteint un seuil prédéfini, la demande sera rejetée.

Les limites

Le WAF peut protéger contre les attaques assez générales, mais il ne peut pas prémunir contre les requêtes entrantes ciblant un bug spécifique dans l’implémentation de l'application web. Il faut bien connaître les services fournis par l'application web que le WAF doit protéger afin de configurer le pare-feu au mieux. Des technologies telles que AJAX (pour créer des pages dynamiques) requièrent d'adapter le WAF en conséquence car par défaut, ils peuvent être bloqués par le WAF.

Références

  1. ↑ Razzaq 2013, p. 2
  2. 1 2 3 4 Desmet 2006, p. 68
  3. 1 2 Rama 2016, p. 2
  4. ↑ Appelt 2015, p. 2.
  5. ↑ Définition simpliste d'un WAFGhanbari 2015, p. 809
  6. 1 2 Ghanbari 2015, p. 809
  7. 1 2 Ghanbari 2015, p. 809
  8. ↑ Endraca 2013, p. 2.
  9. 1 2 Makiou 2014, p. 35
  10. 1 2 3 4 Sonewar 2015, p. 1
  11. 1 2 3 Xiao 2016, p. 650
  12. 1 2 3 4 5 Naga 2012, p. 610
  13. ↑ Pandurang 2015, p. 414.
  14. ↑ Nguyen-Tuong 2005, p. 299.
  15. ↑ Rama 2016, p. 1.
  16. ↑ Rama 2016, p. 2.
  17. 1 2 Appelt 2015, p. 1
  18. 1 2 3 Rama 2016, p. 3
  19. ↑ Desmet 2006, p. 67.
  20. ↑ Ghanbari 2015, p. 811.

Bibliographie

Articles

Document utilisé pour la rédaction de l’article : document utilisé comme source pour la rédaction de cet article.