Sécurité des développements Internet et intranet

A l'ère du Web 2.0 et des applications en ligne, il convient de prendre en compte un phénomène croissant et largement négligé par les DSI : les failles de programmation.

Tout un chacun sait maintenant sécuriser un système d'information avec anti-virus, pare feu, anti-spyware, anti-spam et mises à jour des systèmes d'exploitation et logiciels réguliers.

Un point est cependant très régulièrement négligé : La sécurité des applications en ligne. Elle devient essentielle dès qu'il y a une notion d'e-commerce ou de back-office avec informations propriétaires.

Voici un exemple concret : Vous êtes une banque; vous disposez d'une infrastructure sécurisée permettant à vos clients d'accéder à des données sensibles telles que leurs mouvements de comptes, leurs demandes de virement... Vous avez réalisé des tests d'intrusion indépendants qui se sont avérés négatifs et vous pensez votre système d'information est à l'abris.

Cependant la liste de tous vos comptes est actuellement analysée par un de vos clients et ce dernier effectue des virements sauvages ! Comment est-ce possible ? Principalement à cause de la conception même des navigateurs et surtout du manque de prise en compte par les équipes de développement de ces problèmes de sécurité.
Les applicatifs internet ont un défaut : leur authentification. Cette dernière est souvent basée sur les sessions mais les paramètres sont très souvent envoyés, et ce de façon lisible, d'une page à l'autre.

Pour notre exemple, cela signifie que l'utilisateur malicieux une fois connecté sur son compte va modifier son adresse de page qui envoie normalement sa référence de compte et va envoyer un autre compte et donc pouvoir consulter, si cela n'a pas été anticipé par l'équipe de développement, le compte d'un autre client.

Voici une liste d'attaques potentielles susceptibles d'apparaître si une politique n'a pas été clairement mise en place :
- Pouvoir télécharger un morceau musical depuis le compte de quelqu'un d'autre.
- Récupérer des identifiants de sessions sur les moteurs de recherche ou sur les outils de statistiques et accéder à des webmails sans login/mot de passe.
- Étendre une version d'essai en ligne en une version complète.
- Faire un achat en simulant une commande bancaire.
- Consulter des données confidentielles.
- Fausser des statistiques.
- Utiliser un serveur Web pour envoyer des spam ou effectuer des attaques par deni de services.

Voici quelques points techniques essentiels (non exhaustifs) pour éviter ce genre de désagrément :
- Chaque page sensible doit disposer d'une session liée au connecté.
- Vérifier pour chaque page que les paramètres entrant sont liés au client courant.
- Vérifier la gestion des caractères d'échappement (pour éviter les injections de code dynamique)
- Avoir recours aux Captcha (image de texte aléatoire permettant de détecter qu'un humain est derrière l'écran) dans les zones ultra-sensibles.
- Analyser régulièrement vos logs et loguer toutes les actions de vos clients.

Sécuriser une application en ligne déjà existante pourra prendre un certain temps et nécessitera un développement dynamique qui n'est pas toujours simple. Un avis/audit extérieur indépendant est bien entendu toujours conseillé.