jump to navigation

Comment une mauvaise configuration d’application peut affecter la sécurité de votre réseau … 16 juillet 2012

Posted by frnetworker in Diagnostic Réseau, OmniPeek.
Tags: , , , ,
trackback

Développer et déployer des applications est bien plus facile depuis quelques années et la tendance ne fait que s’accélérer avec les kits d’outils de développement, le cloud computing et les plateformes de services (Paas). De ce fait, les problèmes d’erreur de configuration augmentent proportionnellement en particulier pour les applications Web.

Il faut garder en mémoire que le fonctionnement logique et le contrôle de l’application doivent être (et rester) au niveau du serveur lors que l’interface utilisateur est elle doit être gérée du coté clients. Pour faire une analogie, pensez à un supermarché : même si le client peut se promener le long des allées et placer des articles dans son chariot, l’essentiel du business se passe à la caisse qui est, dès lors, un passage obligé.

Les exemples ne manquent pas !

Par exemple en 2009, les Pizza Domino’s ont lancé une campagne d’actions marketing et publicitaire pour gagner de nouveaux clients. Une application écrite en Flash fut ajoutée au site en ligne pour permettre aux clients de passer commande en ligne. Cette application, affichait un champ permettant d’entrer un coupon pour recevoir une pizza pour 5$.

Une nuit du week-end, un pirate a désassemblé l’application Flash pour voir comment elle fonctionnait et s’aperçu que la validité du coupon était contrôlée par l’application elle même. Pire encore, il a constaté que le plan marketing prévoyait même un coupon pour obtenir gratuitement une pizza. Comme le code se trouvait dans l’application Flash, il l’essaya sans délai et moins de 30 minutes plus tard, il se régalait d’une pizza gratuite. Le pirate s’empressa alors de poster le code coupon sur un forum. Ce n’est que le lundi matin que l’entreprise se rendit compte que son secret avait été percé et qu’elle avait livré gratuitement 11.000 pizza pour un coût d’environ 50.000$. Heureusement pour une compagnie de cette taille, cela n’a pas porté de préjudice majeur, mais cela reste une somme qui aurait pu ne pas être perdue si le contrôle des coupons avait été réalisé sur le serveur.

De nombreux exemples similaires peuvent être trouvés où une substitution relativement simple dans un formulaire de soumission (de commande en ligne) ont permis à un pirate de modifier le prix : Le serveur envoi une page web sur le poste utilisateur avec le prix de chaque article … et le bouton ‘Ajouter au panier’ renvoi la quantité et le prix au serveur … Un expert en sécurité a fait la démonstration d’achat d’un article coutant plusieurs milliers de dollars, pour 1 unique dollars. Pourtant cette faille était simple à éviter : il suffisait à l’application de retourner le code article, et non pas le prix, depuis le poste utilisateur vers le serveur, ce dernier se chargeant de trouver le prix de l’article dans sa base de données.

Ces 2 exemples portent sur des solutions de vente en ligne, mais ce type de faille peut affecter n’importe quelle application web. Lorsqu’une application compte de telles failles, cela affaiblit directement la sécurité réseau et rend l’entreprise vulnérable. Ces vulnérabilités offrent potentiellement un accès au système d’information voir même à la configuration système. Dans le mesure ou les attaques de type DoS (Denial of Service) visent justement à mettre à terre un système, les failles applicatives sont une incitation au piratage.

L’une des principale méthode d’attaque en 2012

Une mauvaise implémentation de l’application peut rendre le système vulnérable aux attaques du type injection de code SQL. En 2012, l’injection de code SQL fut l’une des méthodes les plus utilisées selon un rapport de Verizon Data Research Investigations. Le scénario type d’une injection SQL survient lorsque le pirate est à même d’inclure des instructions de contrôle SQL dans les champs d’un formulaire. Lorsque le formulaire est validé, le serveur SQL ne se contente pas de stocker les informations, il reconnait et exécute les instructions SQL. Les résultats peuvent être dramatiques : En juin 2012, plus de 6 millions de mots de passe de LinkedIn ont été postés en ligne. Même si la société n’a pas souhaité faire de commentaires, un article de SC Magazine indique de le site a été victime de ce type d’attaques depuis plusieurs mois. D’un certain point de vue, LinkedIn a eu de la chance : les injections de code SQL auraient pu permettre aux pirates d’effacer la plus grande partie des informations du site. En conséquence, le site a pu analyser et corriger ses failles de sécurité … A comparer avec Nortel Networks  dont les données sont restées vulnérables pendant plus de 10 ans …

Les injections de code SQL sont pourtant relativement simples à éviter. Lorsque le serveur reçoit des informations de l’utilisateur, il doit encapsuler les données de sorte que le serveur SQL ne reçoive/perçoive que des données. (autrement dit, aucune instruction SQL).  Si par malheur chaque page web peut se connecter directement au serveur SQL plutôt que d’envoyer ces données à une fonction (sur le serveur) qui s’assurera d’analyser (et de nettoyer le cas échéant) les données reçues, la phase de correction peut être titanesque et fort couteuse. C’est la raison pour laquelle, ces réflexions de sécurisation doivent être menées en amont, dès la phase de conception de l’application web.

Alors, même si les exemples cités sont caricaturaux, la plupart des entreprises sont de tailles plus modeste.

Une récente étude auprès de 501 PME, montrent que 85% d’entre elles ne prennent aucune précaution, en estimant, À TORD, qu’elle sont trop petite pour être une cible. Si vous même qui lisez ce billet pensez que votre entreprise est trop petite pour être la cible d’actes de piratage ou de vandalisme gardez en mémoire qu’un très grand nombre de pirates utilisent des logiciels automatiques qui scanner l’internet à la recherche de vulnérabilités ou de failles applicatives. Certains de ces logiciels se concentrent sur des sociétés de plus petites tailles car elles ont le plus souvent des protections moindres que les géants du marché. La prise de contrôle d’une petite société peut être un point d’entré idéal pour en attaquer d’autres. Les hackers utilisent parfois des sites d’entreprises pour diffuser des informations illégales comme des malwares ou des contenus pornographiques illicites. Pire encore, ces piratent utilisent parfois votre serveur pour envoyer du spam. Etre une entreprise de taille modeste ne vous protège pas ! cela fait juste de vous une cible d’un autre type (que les mastodontes de l’internet) et mettre en œuvre un minimum de sécurité est un excellent investissement.

Utiliser des outils comme OmniPeek pour contrôler la bonne application des règles de sécurité de part et d’autre des firewall est essentiel pour renforcer votre sécurité. OmniPeek simplifie également la visualisation des échanges « poste client » <-> « serveur » pour vous permettre de contrôler les informations échangées. (par exemple que notre serveur ne devrait pas recevoir le prix de l’article mais son code produit).

En fait votre sécurité informatique est comme une porte blindée … plus elle est résistante, et plus vous avez de chance que les hackers abandonnent les attaques à votre encontre, une une porte blindée trop longue à forcer décourage les visiteurs indésirables.

•  •

Librement inspiré de l’article : How Application Flaws Can Affect Your Network Security

Advertisements

Commentaires»

No comments yet — be the first.

Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :