Pare-feu d'application Web
Les pare-feu d'applications Web (WAF) sont un type de système de détection et de prévention des intrusions et peuvent être une solution matérielle ou logicielle. Il est spécifiquement conçu pour inspecter HTTP (s) et analyser les requêtes GET et POST en utilisant la logique de détection épouvantable expliquée ci-dessous. Le logiciel de pare-feu d'application Web est généralement disponible en tant que plugin de serveur Web.
Le WAF est devenu extrêmement populaire et diverses sociétés offrent une variété de solutions dans différentes catégories de prix, des petites entreprises aux grandes sociétés. Le WAF moderne est populaire car il a un large éventail de tâches couvertes, de sorte que les développeurs d'applications Web peuvent compter sur lui pour divers problèmes de sécurité, mais en supposant que cette solution ne peut pas garantir une protection absolue. Un flux de travail WAF de base est illustré ci-dessous.
Sa fonction principale est la détection et le blocage des requêtes dans lesquelles, selon l'analyse WAF, il y a quelques anomalies, ou un vecteur d'attaque est tracé. Une telle analyse ne devrait pas rendre difficile pour les utilisateurs légitimes d'interagir avec une application Web, mais, en même temps, elle doit détecter avec précision et en temps opportun toute tentative d'attaque. Afin de mettre en œuvre cette fonctionnalité, les développeurs WAF utilisent généralement des expressions régulières, des jetons, une analyse comportementale, une analyse de réputation et un apprentissage automatique, et, souvent, toutes ces technologies sont utilisées ensemble.
En outre, WAF peut également fournir d'autres fonctionnalités: protection contre les DDoS, blocage des adresses IP des attaquants, suivi des adresses IP suspectes, ajout d'un indicateur HTTP uniquement au cookie ou ajout de la fonctionnalité des jetons CSRF. Chaque WAF est individuel et possède une disposition interne unique, mais il existe certaines méthodes typiques utilisées pour l'analyse.
Expression régulière
La plupart des WAF existants sont basés sur des règles basées sur des expressions régulières. Pour les créer, certains ensembles d'attaques bien connus sont étudiés par le développeur WAF et, par conséquent, des constructions syntaxiques clés sont déterminées, dont la présence peut être revendiquée pour mener à bien l'attaque. Sur la base des résultats obtenus, des expressions régulières sont écrites qui peuvent trouver de telles constructions. Par exemple, en analysant les en-têtes HTTP tels que Server: Apache Tomcat / 7.0.x, WAF peut bloquer une réponse et ainsi empêcher la fuite d'informations sur le serveur ou, sinon, déclencher une alerte.
Cependant, cette approche présente un certain nombre d'inconvénients. La plage d'applicabilité d'une expression régulière est limitée à une requête, et souvent même à un paramètre de requête spécifique, ce qui réduit évidemment l'efficacité de ces requêtes. Deuxièmement, la syntaxe des expressions régulières, la logique complexe des protocoles de texte, permettant le remplacement de constructions équivalentes et l'utilisation de différentes représentations de symboles, entraînent des erreurs lors de la création de telles règles. Le tableau ci-dessous présente les techniques de bypass les plus courantes.
Obfuscation SQL. Il est possible de modifier l'expression de sorte que, en utilisant la syntaxe du langage, elle puisse se débarrasser des espaces. Par exemple, en SQL, vous pouvez utiliser des crochets et des étoiles:
s / * / e / ** // * e * // * / l / * le * c * // * / ect ~~ / ** / 1 ou / id = 1 + un / ** / ion + sel / ** / ect + 1,2,3--
L'autre est basé sur l'utilisation de différents encodages de telle manière que le WAF ne décode pas les données à certains endroits. Par exemple, après avoir remplacé un caractère par son code URL dans le processus de normalisation, WAF ne pourra pas comprendre qu'il est nécessaire de décoder les données et d'ignorer la demande, tandis que le même paramètre sera accepté et décodé avec succès par le Web application.
Recherche de constructions syntaxiques équivalentes atypiques. Cette méthode est utilisée pour trouver un mode de fonctionnement qui n'a pas pu être envisagé par les développeurs de WAF, ou le vecteur était absent dans l'échantillon d'étude pour l'apprentissage automatique. L'une de ces constructions est la représentation du code Javascript non alphanumérique, dont un exemple est illustré ci-dessous.
Méthode de construction des scores
Cette approche ne détecte pas les attaques, mais elle complète d'autres méthodes, les rendant plus précises et flexibles. La raison de l'introduction de l'outil est que la présence dans la requête d'une conception suspecte est insuffisante pour détecter une attaque, ou, au contraire, elle peut conduire à un grand nombre d'erreurs faussement positives. Ce problème est résolu en introduisant un système de notation. Par exemple, chaque règle basée sur des expressions régulières est complétée par des informations sur la criticité de son fonctionnement; Après avoir identifié toutes les règles travaillées, leur criticité est résumée. En cas de dépassement d'une certaine valeur seuil, l'attaque est détectée et la demande est bloquée.
Analyse comportementale
La détection des tentatives d'exploitation des vulnérabilités dans les paramètres de requête n'est pas la seule tâche de WAF. Il est important d'identifier la procédure de recherche de vulnérabilité elle-même, qui peut se manifester par des tentatives d'analyse, la force brute du répertoire, le fuzzing de paramètres et d'autres méthodes de détection de vulnérabilité qui sont souvent utilisées par des outils automatisés, et réagir en conséquence. Les WAF plus avancés savent même comment créer un fichier XML avec des chaînes de requête typiques du comportement normal de l'utilisateur et bloquer les tentatives d'envoi de requêtes dans un ordre différent du comportement standard. Ce mécanisme contrecarre non seulement les attaques, mais complique également le processus de recherche d'une vulnérabilité.
Analyseurs d'analyseur Tokeniser
Cette approche de détection des attaques est un concept complexe; cependant, il n'est pas facile de le démonter sur l'amorce C ++ de la bibliothèque Libinjection, ce qui permet de détecter rapidement et précisément les attaques par injection SQL. À l'heure actuelle, pour la bibliothèque Libinjection, il existe des ports pour divers langages de programmation, y compris Java, C et Python. Le mécanisme se réduit à la recherche de signatures, représentées comme une séquence de jetons. Certaines signatures sont ajoutées à la liste noire intégrée et sont considérées comme inacceptables ou malveillantes. En d'autres termes, avant d'analyser une requête, cela conduit d'abord à un ensemble de jetons. Les jetons sont divisés en différents types, chaîne, caractère, opérateur régulier, nombre, commentaire, variable, etc.
L'un des principaux inconvénients de cette méthode est qu'il est possible de construire une telle conception qui conduira à la formation incorrecte de jetons; par conséquent, la signature de la demande sera différente de celle attendue.
Les attaques dirigées contre les jetons sont associées à des tentatives de briser la logique en décomposant la demande en jetons à l'aide de briseurs de jetons. Ce sont de tels symboles qui vous permettent d'influencer le choix d'un élément de chaîne pour correspondre à un jeton spécifique et, ainsi, de contourner la recherche par des signatures. En accès libre, il y a quelques tricheurs, obtenus par fuzzing Mysql et vérification des requêtes subséquentes dans Libinjection.
Analyse de réputation
Le mécanisme de réputation est directement hérité des pare-feu et antivirus. Aujourd'hui, presque tous les WAF incluent des listes d'adresses de services VPN, d'anonymiseurs, de nœuds de réseau Tor et de participants au botnet qui peuvent être utilisés pour bloquer les demandes provenant d'adresses suspectes. Des WAF plus avancés peuvent mettre à jour automatiquement leurs bases de données et effectuer des entrées supplémentaires en fonction du trafic analysé.
Résumé
En général, le pare-feu d'application Web est un outil de protection moderne et efficace, et il ne sera jamais superflu pour les applications Web. L'idée principale de trouver des moyens de contourner WAF est d'amener la requête demandée sous une forme dans laquelle elle est toujours compréhensible pour l'application Web attaquée, mais elle n'est pas compréhensible ou ne semble pas inoffensive pour WAF.
Cependant, il existe plusieurs classes de vulnérabilités que WAF ne peut pas détecter. Cela peut être une vulnérabilité logique, dans ce cas, il n'y a pas de comportements anormaux dans les demandes. De plus, certaines études menées pour optimiser les règles WAF montrent également des méthodes d'exclusion des demandes légitimes du processus d'inspection, qui peuvent être potentiellement dangereuses. Le WAF est également le plus susceptible de ne pas être utile pour identifier les concurrents, tels que la condition de concurrence et l'authentification utilisateur non sécurisée.
Référence
Vladimir Ivanov (2016) Tables de symboles autorisés dans différentes entrées d'expression SQL, résultat de l'analyse des tables fuzz. Disponible sur: www.blackhat.com/docs/us-16/materials/us- 16-Ivanov-Web-Application-Firewalls-Analysis-Of-Detection-Logic.pdf
Torrano-Gimenez, C., Perez-Villegas, A. et Alvarez, G. (2009) `` A Self-learning Anomaly-Based Web Application Firewall '', Springer, Berlin, Heidelberg. doi: doi.org/10.1007/978-3-642-04091-7_11 .
Ramsingh, C. et Centonze, P. (2017) `` Program Analysis For Database Injections '', JOURNAL INTERNATIONAL DES ORDINATEURS ET DE LA TECHNOLOGIE, 16 (6), pp. 6977 à 6986. Doi: 10.24297 / ijct.v16i6.6332.
Prokhorenko, V., Choo, KKR et Ashman, H. (2016) `` Web application protection techniques: A taxonomy '', Journal of Network and Computer Applications, 60, pp. 95-112. doi: 10.1016 / j.jnca.2015.11.11.017.
Prandl, S., Lazarescu, M. et Pham, D. (2015). Une étude des solutions de pare-feu d'applications Web. Sécurité des systèmes d'information, pp. 501-510. doi: 10.1007 / 978-3-319-26961-0_29.
Positive-Technologies (2016a) 'Pare-feu d'applications Web: attaque des mécanismes logiques de détection'. Disponible sur: www.blackhat.com/docs/us-16/materials/us-16-Ivanov- Web-Application-Firewalls-Analysis-Of-Detection-Logic.pdf.
OWASP (2017) SQL Injection Bypassing WAF. Disponible sur: www.owasp.org/index.php/SQL_Injection_Bypassing_WAF .