Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants








télécharger 56.16 Kb.
titreRésumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants
date de publication24.10.2016
taille56.16 Kb.
typeRésumé
ar.21-bal.com > droit > Résumé

INFOSEC 2002

Résumé

Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants.

Cependant, la présence d'un firewall procure un faux sentiment de sécurité, car il est trop souvent perçu comme la panacée de la sécurité. Or un firewall ne protège pas de certains types d'attaques provenant d'Internet, et on observe actuellement une recrudescence de ces types d'attaques.

Ainsi, les applications Web mises en ligne par de plus en plus d'entreprises ne sont en rien protégées par la présence d'un firewall. De nombreuses attaques ne sont pas arrêtées par celui-ci, et la sécurité de l'application Web doit être gérée ailleurs.

Cette présentation se propose de présenter les différentes attaques capables d'outrepasser un firewall et d'effectuer une intrusion sur une application Web, puis de montrer quelles sont les mesures à prendre afin de sécuriser une telle application, aussi bien au niveau de son architecture que de son implémentation.

Abstract

Thanks to a better knowledge of IT security than a few years ago, the connections between the enterprises and the Internet are better and better secured. Particularly, firewalls are common, nowadays.

However, the presence of a firewall brings a false feeling of security, because it is considered as the best of security. But a firewall cannot protect a network against some kinds of attacks originating from the Internet, and we can observe a worsening of such kinds of attacks.

Thus, Web applications developed by more and more enterprises are not protected by the single presence of a firewall. Numerous attacks are not stopped by it, and the security of a Web application must be managed elsewhere.

This briefing intends to present the various attacks that can go beyond a firewall and perform a penetration in a Web application, then to show the necessary measures to secure such an application, at the architecture and at the implementation levels.

Vulnérabilités et solutions de sécurisation

des applications Web :

pourquoi les firewalls ne couvrent pas

tous les aspects de protection ?

Patrick CHAMBET

patrick.chambet@edelweb.fr

EdelWeb – ON-X Consulting

15 Quai de Dion Bouton

92816 PUTEAUX Cedex

Tél: 01.41.20.31.55

contact@edelweb.fr

Actuellement, aucune entreprise n’envisagerait sérieusement d’ouvrir sur Internet un nouveau service en ligne sans avoir pensé à évaluer la sécurité de celui-ci. En effet, la culture de la sécurité commence à faire son chemin dans l’esprit des chefs de projets et des directeurs informatiques, et la dangerosité des attaques provenant d’Internet est quelque chose dont ils sont désormais conscients.

Grâce à ces acquis, les plates-formes hébergeant les applications Web sont de mieux en mieux sécurisées. En particulier, l’utilisation d’un firewall est maintenant considérée comme une condition sine qua non.

Cependant, la présence d'un firewall procure un faux sentiment de sécurité, car il est trop souvent perçu comme la panacée des solutions de sécurité. Or il ne couvre que certains aspects de la protection globale que nécessite une application Web complexe ouverte sur Internet. En particulier, certaines attaques ne peuvent être arrêtées par un firewall, pour la simple raison qu’elles sont noyées au milieu des requêtes de pages Web, qui sont bien sûr autorisées à travers le firewall.

On observe actuellement une recrudescence de ces types d'attaques, car elles sont bien souvent les seules à fonctionner sur une plate-forme bien sécurisée, et elles fonctionnent d’ailleurs extrêmement bien.

Nous allons, dans les paragraphes qui suivent, définir les caractéristiques d’une application Web, et passer en revue les différentes sortes d’attaques auxquelles elle peut être sensible, ainsi que les parades respectives permettant de sécuriser une telle application.

Qu’est-ce qu’une application Web ?

Une application Web est une application qui n’a besoin que du protocole HTTP pour être pilotée par un utilisateur. Celui-ci utilise un simple navigateur Web ou bien une application propriétaire utilisant le protocole HTTP.






Client

Web

Serveur

Web

Composant

applicatif





Composant

applicatif





Firewall


La plupart des applications Web sont accessibles depuis Internet, mais un grand nombre d’entre elles sont situées sur des intranets, qui ne peuvent pas non plus être considérés comme des réseaux sûrs.

Pour permettre l’utilisation d’une application Web, il suffit que le firewall protégeant celle-ci ne laisse entrer que le protocole HTTP sur le port 80 (et éventuellement HTTPS sur le port 443). Dans ces conditions, il semble difficile d’attaquer une application Web. Pourtant, nous allons voir qu’à travers ce seul port 80, considéré comme « amical » mais devenu un port « fourre-tout » par lequel passent de plus en plus de flux et de protocoles, il est possible de lancer des attaques extrêmement dangereuses.

Les différentes sortes d’attaques sur les applications Web sont les suivantes :

  1. Interprétation des URLs

  2. Mauvais contrôle des données entrées par l’utilisateur

  3. Injection de code SQL

  4. Attaques sur les identifiants de session

  5. Autres attaques


1.Interprétation des URLs


Les URLs utilisées dans le cadre d’une application Web sont du type :

http:// www.monserveur.com /chemin/ fichier.ext? param1=toto & param2=alaplage

Une URL de ce type est composée de plusieurs parties :

- http:// : protocole utilisé

- www.monserveur.com : adresse du serveur

- chemin : arborescence de répertoires sur le serveur Web

- fichier.ext : fichier lu ou exécuté (son extension .ext est très importante)

- param1 et param2 : paramètres d’exécution.

Chacune de ces parties est susceptible d’être attaquée :

  • Protocole : on peut essayer de remplacer le protocole https:// par http://, par exemple, afin de désactiver une authentification par certificat client.

  • Serveur : on peut le remplacer par son adresse IP ou par les noms de domaines d’autres sites hébergés sur le même serveur, afin d’avoir accès à d’autres parties du site.

  • Chemin : on peut tenter de naviguer dans l’arborescence pour accéder à des parties du site non autorisées ou pour remonter dans l’arborescence par l’utilisation de /../../, ou en utilisant des vulnérabilités particulières (le bug Unicode sur IIS, par exemple).

  • Fichier : son extension va déterminer de quel type d’exécutable il s’agit : CGI, scripts ASP, HTR ou autre code exécutable, etc… Plusieurs types de fichiers ont connu des vulnérabilités attachées à leur mode d’exécution.

  • Paramètres : la manipulation des noms de paramètres et de leur contenu peut conduire à des effets dangereux. Par exemple, supposons que l’URL suivante prend comme paramètre un fichier afin d’en afficher la taille :

http://www.maisjemesoigne.com/cgi-bin/getsize.cgi?fichier=test.txt

En modifiant l’URL ainsi :

http://www.maisjemesoigne.com/cgi-bin/getsize.cgi?fichier=*

vous obtenez la liste des fichiers contenus dans le répertoire cgi-bin !

Les conséquences de ces attaques peuvent être la divulgation d’informations importantes, l’accès au code source des scripts ou au contenu des fichiers, ou l’exécution de commandes sur le serveur. Des attaques dérivées peuvent être ensuite menées d’après la lecture du code source obtenu ou grâce à des pages d’exemples laissées sur le serveur et trouvées par exploration de l’arborescence.

Pour contrer les attaques ci-dessus, il convient de prendre en compte les recommandations de sécurisation suivantes :

  • Sécuriser le système d’exploitation et le serveur Web (appliquer en particulier les derniers patches)

  • Installer l’arborescence Web sur une partition séparée

  • Contrôler strictement l’arborescence Web et supprimer les répertoires inutiles

  • Désactiver le « directory browsing » sur l’ensemble du site Web

  • Supprimer tous les filtres, interpréteurs de scripts, CGI et autres exécutables inutiles

  • Supprimer tous les fichiers inutiles sur un serveur de production, notamment les pages d’exemples

  • Appliquer des permissions d’accès sur les fichiers au niveau du serveur Web mais aussi du système de fichiers

  • Désactiver le protocole http sur les pages qui nécessitent HTTPS

  • Enfin, contrôler les entrées des utilisateurs au niveau des paramètres dans l’URL : c’est l’objet du paragraphe suivant.


2.Mauvais Contrôle des données entrées par l’utilisateur


Nous rencontrons encore trop souvent des applications Web où le contrôle des entrées par l’utilisateur se fait uniquement côté client. Dans ce cas, il faut toujours considérer qu’un attaquant pourra outrepasser le contrôle côté client et donc envoyer les données qu’il désire au serveur.

Par exemple, considérons le cas d’une page Web permettant d’effectuer un virement bancaire. Par précaution, la banque limite les virements par Internet à 10000 Euros. D’ailleurs, un script Javascript contenu dans la page contrôle en temps réel le montant saisi et empêche toute validation avant que le montant soit correct.

Dans ces conditions, il suffit de modifier le script, ou même simplement de désactiver Javascript, pour pouvoir saisir un montant de 200 000 Euros et valider le formulaire.

La recommandation qui s’impose est donc de toujours contrôler la validité des données fournies par l’utilisateur au moins côté serveur. Ce contrôle peut bien sûr être doublé côté client pour des raisons d’ergonomie, mais le contrôle final devra toujours avoir lieu côté serveur.

D’autre part, il existe des caractères spéciaux dont la signification, au sein d’une chaîne alphanumérique, peut respecter une syntaxe particulière au niveau d’un langage de programmation ou d’un système d’exploitation, ce qui peut conduire à l’exécution de commandes hostiles. Ces caractères figurent parmi les suivants :

! @ $ % ^ & * ( ) - _ + ` ~ \ | [ ] { } ; : ' " ? / , . > <

Ainsi, dans l’exemple fourni au paragraphe 1, le caractère « * » était interprété comme l’ensemble des fichiers contenus dans le répertoire courant. De même, le caractère « ; » est un séparateur, les caractères « < » et « > » effectuent des redirections, « % » permet d’entrer des caractères par leur code hexadécimal, etc…

Il est donc indispensable de filtrer ces caractères à l’intérieur des données fournies par l’utilisateur, en les codant en leurs équivalents en HTML (« > » devient > ; , « < » devient < ;, etc…), en leur ajoutant un caractère d’échappement (« \ » par exemple), en les supprimant, ou en demandant à l’utilisateur de modifier sa saisie.

Pour résumer, les recommandations nécessaires pour contrer la saisie de données hostile par un utilisateur sont les suivantes :

  • Comptage du nombre de paramètres et de leur nom

  • Neutralisation des caractères spéciaux

  • Contrôle de la longueur des données

  • Validation du type des données (date, chaîne, nombre)

  • Contrôle de l’intervalle de validité des données (dans l’absolu)

  • Vérification de la validité réelle des données (en relatif, dans une base de données)

  • Limitation du nombre de saisies de données par unité de temps.


3.Injection SQL


L’injection SQL peut être une conséquence directe d’un mauvais contrôle des données entrées par l’utilisateur. En effet, les caractères « ‘ » et « ; » peuvent être utilisés pour enchaîner plusieurs requêtes SQL à la suite. Considérons par exemple une page HTML comprenant un champ de saisie nommé « Name » permettant d’obtenir les coordonnées des clients d’une entreprise. La requête SQL tournant sur le serveur est la suivant :

SELECT * FROM table_Clients WHERE champ_Nom=Name

Si maintenant un attaquant saisit la chaîne suivante dans le champ Name :

1; INSERT INTO table_Users VALUES ('Mon_login’, ‘Mon_password’)

La requête exécutée au final sera la suivante:

SELECT * FROM table_Clients WHERE champ_Nom=1; INSERT INTO table_Users VALUES ('Mon_login’, ‘Mon_password’)

Le résultat est l’affichage des données concernant le client 1, suivi par l’ajout dans la base de données d’un utilisateur dont le couple login/mot de passe permettra à l’attaquant de se connecter à l’application comme un utilisateur authentifié.

Cependant, le filtrage des caractères spéciaux ne suffit pas à se protéger de l’injection de code SQL. Considérons par exemple la saisie suivante :

1 UNION ALL SELECT champ_Password FROM table_Users WHERE champ_Login LIKE admin

Aucun caractère spécial (autre que le “_” utilisé pour des raisons de lisibilité) n’est utilisé, et pourtant la requête obtenue affichera la liste des mots de passe des administrateurs.

Il existe beaucoup d’autres techniques d’injection de code SQL. Pour contrer ce type d’attaques, il est donc nécessaire d’effectuer un filtrage beaucoup plus précis du contenu des données saisies par les utilisateurs. Il faudra en particulier interdire les mots clés comme SELECT, INSERT, UNION, LIKE, etc… L’utilisation de fonctions de substitution et les expressions régulières sont ici très utiles.

4.Attaques sur les identifiants de session


La plupart des systèmes d’authentification et de maintien du contexte des sessions Web des utilisateurs repose sur un identifiant de session, échangé à chaque page entre le client et le serveur, que ce soit au niveau du cookie, de l’URL ou d’un champ caché de formulaire.

Une attaque classique consiste à voler la session d’un utilisateur qui vient de s’authentifier sur le système en essayant de deviner la valeur de son identifiant de session. Si la valeur de celui-ci est découverte, un attaquant peut alors utiliser l’application Web en lieu et place de l’utilisateur légitime.

Un identifiant de session se présente par exemple ainsi :

0001WVWSDWAAAAB4EMYPBIB0NXA

Si on essaie de récupérer un grand nombre d’identifiants successifs, on obtient par exemple les valeurs suivantes :

0001WVWSDWAAAAB4EMYPBIB0NXA

0001WV0WPSQAAACS4MYPBIAQZTY

0001WVXXHLQAAAB4YMYPBIB0NXA

0001WV2FYBYAAACUCMYPBIAQZTY

0001WV2VIRYAAACUKMYPBIAQZTY

0002YEQH5FYAAAPYWMYPBIAQ20I

0002YFAQGDYAAAPWMMYPBIAQ20I

0002YMUBB2AAABS4GMYPBIAQ20I

0003ZAM00NAAABV0AMYPBIA4JZQ

On remarque immédiatement que cet identifiant de session semble codé en base 32, et qu’il possède de nombreuses parties fixes ou variant lentement. De plus, d’autres parties sont rapidement identifiées comme étant des adresses IP et des ports. Enfin, il semble que des parties varient comme une horloge interne.

A l’aide de ces simples constatations, il est possible de développer un outil qui va nous permettre de diminuer considérablement l’espace de valeurs de cet identifiant, et qui va automatiser la recherche d’une valeur correcte de celui-ci. On peut ainsi augmenter les chances de trouver une bonne valeur à une sur 1000 à 3000, ce qui est extrêmement peu : quelques minutes seulement permettront de voler la session d’un utilisateur authentifié !

Il est donc indispensable d’écrire une fonction de génération des identifiants de session extrêmement robustes. En particulier, la qualité du générateur aléatoire doit être vérifiée, et l’espace de valeurs doit être suffisamment étendu pour qu’une attaque en brute force ne puisse être menée dans un délai réduit. Il est déconseillé d’utiliser les fonctions de génération d’identifiants fournies en standard avec certains logiciels ou environnements de développement du marché (cf l’exemple réel ci-dessus, obtenu avec un logiciel utilisé dans le domaine bancaire).

5.Autres attaques


D’autres attaques peuvent être menées contre des applications Web :

Mécanismes d’authentification basés sur Java, JavaScript ou ActiveX :

Les applications utilisant ces technologies sont sujettes à des manipulations effectuées côté client permettant à un attaquant d’outrepasser le mécanisme d’authentification.

Manque de ré-authentification :

Le manque de ré-authentification au niveau de certaines fonctionnalités critiques (comme le changement de mot de passe par exemple) permet souvent à un attaquant de prendre le contrôle d’un compte utilisateur.

Mauvaise gestion du contexte utilisateur :

La mauvaise gestion du contexte utilisateur peut permettre une augmentation progressive de privilèges conduisant à la prise de contrôle total de l’application par un attaquant.

Attaques côté client:

Il s’agit d’attaquer les utilisateurs de l’application plutôt que l’application elle-même. Ce genre d’attaques est rendu possible principalement par les langages exécutés côté client :

  • VBScript

  • Flash

  • DHTML

  • XML

  • JavaScript

  • Applets Java

  • ActiveX

  • CSS

Man in the middle:

Une attaque dite “man in the middle” consiste à intercepter les requêtes du client et à les relayer vers le serveur distant légitime et inversement à intercepter les réponses du serveur et à les relayer vers le client. Il est possible au passage, si nécessaire, de modifier à la volée les données fournies par le client et/ou les réponses du serveur.

Cette attaque est même possible si le serveur de destination utilise un chiffrement par SSL : il suffit que le serveur intercepteur possède lui aussi un certificat serveur et que le client clique sur « Accepter » lorsque son navigateur lui propose d’utiliser ce certificat pour dialoguer avec le serveur distant légitime. Il ne reste plus alors au serveur intercepteur qu’à déchiffrer d’un côté et rechiffrer de l’autre, à la volée.

Le seul moyen de se prémunir contre ce type d’attaque est d’imposer une authentification côté client par l’utilisation de certificats clients. Le serveur intercepteur ne pourra alors plus se faire passer pour le client auprès du serveur distant légitime.

En conclusion, nous avons vu que le nombre de types d’attaques qu’il est possible de mener contre une application Web et qui traversent les firewalls est considérable. Il est donc extrêmement important de prendre en compte la sécurité le plus en amont possible lors du développement d’une application Web. L’idéal est de considérer les contraintes sécuritaires dès la conception de l’architecture de l’application. Les recommandations exposées au cours de cette présentation permettront alors de bloquer la plupart des attaques. Cependant, il reste indispensable de faire procéder à un test d’intrusion applicatif par une société spécialisée, à la fin du développement et juste avant la mise en production de l’application Web.

Références :

http://www.sqlsecurity.com

http://www.owasp.com

http://www.hammerofgod.com/download.htm

http://heap.nologin.net/aspsec.html

http://www.microsoft.com/technet/itsolutions/security/database/database.asp

http://www.securityfocus.com

Patrick CHAMBET - -

similaire:

Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants iconConnected Drive – une plus-value grâce à l’interconnexion. Introduction. 3
«Dynamic Light Spot». Grâce à son faisceau ponctuel, les piétons sont encore mieux visibles de nuit et les accidents sont évités

Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants iconRésumé : Cette étude utilise une variété de courants de la littérature...

Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants iconEn particulier les sonnets ''France, mère des arts'' [page 31]
«J'ai passé l'âge de mon enfance et la meilleure part de mon adolescence assez inutilement, lecteur, mais, par je ne sais quelle...

Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants iconLes Sept Courants de la Grace
...

Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants iconRésumé La sécurité est un enjeu majeur des technologies numériques...
«Public Key Infrastructure» pour l’authentification, le vpn «Virtual Private Network» – ipsec pour le cryptage des données et les...

Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants iconRéunion statutaire tenue au siège du club (royal mansour) L’attente...
«séjour parisien» durant lequel IL a été opéré de la cataracte, a hâte de revoir les amis, d’autant plus qu’il peut les «voir» mieux...

Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants icon1/Ce sont les distances sur les cartes/plans, celles en réalité peut-être sont plus longues

Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants iconCliquez sur l’une des carrières suggérées. (Celles du haut de la...

Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants iconCertificat de qualification professionnelle «Ouvrier qualifié en...
«Réalisation et entretien de plantations ornementales». Les entreprises du paysage ont connu leur essor à partir des années 70. Elles...

Résumé Grâce à une meilleure prise en compte de la sécurité que par le passé de la part des entreprises, les interconnexions à Internet de celles-ci sont de mieux en mieux sécurisées. En particulier, les firewalls sont maintenant devenus courants iconCompte rendu seance du 25 septembre 2013 Sécurité Routière – Centre Bourg – Analyse des offres
«noodo» qui permet un accès Internet via le réseau région aster haut débit, avec contrôle sécurisé des connexions, et connexion par...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com