Mises à jour de la sécurité #2016

La protection des données dans le domaine RH en mode Saas (Software As A Service) est primordiale. Nous avons adopté depuis plusieurs années un processus d’amélioration continue dans ce domaine.

Voici les dernières évolutions de la plate-forme et des applications :

La protection des mots de passe

Dans le domaine du hachage et du stockage des mots de passe, les bonnes pratiques sont les suivantes :

  • Utiliser un algorithme de hachage irréversible et lent
  • Rendre unique le hachage en salant les mots de passe
  • Ne pas accepter les mots de passe « simples »

Nous avons choisi un algorithme de hachage éprouvé et connu pour le paramétrage de la lenteur de chiffrage. La non réversibilité des mots de passe signifie qu’à partir du mot de passe chiffré (empreinte ou hash) stocké sur notre plateforme, il est impossible de retrouver le mot de passe d’origine. Un vol de ces données est donc inexploitable directement.

Nous avons ajouté du sel dans le processus. Ajouter du sel, c’est ajouter une clé qui nous est propre. En effet, l’algorithme de hachage est certes éprouvé, mais sans sel, les empreintes de mots de passe seraient exploitables avec l’utilisation des tables « rainbow ». Ces tables permettent de comparer les empreintes de mots de passe volées avec des empreintes préalablement générées. Grâce au salage, nos empreintes de mots de passe sont uniques.

Enfin, nous avons durci nos exigences en matière de complexité de mot de passe. Plutôt que de simplement exiger un nombre et une variété de caractères, nous calculons la complexité du mot de passe grâce à une librairie embarquée dans Lucca. C’est ce système qui permet d’afficher la dureté du mot de passe choisi lors de la saisie. Ceci dit, un minimum de 8 caractères est tout de même exigé.

Le chiffrement des e-mails

Il existe une version sécurisée de chaque protocole. Certains mieux connus que d’autres.

  • https pour le http : correspond à l’activité principale de votre navigateur internet
  • ftps ou sftp pour le ftp : ce protocole est utilisé pour le transfert de fichiers à des fins d’import ou d’export automatisés
  • smtps ou smtp TLS pour le smtp : c’est la version sécurisée du protocole utilisé pour émettre des mails.

Nous utilisons depuis plusieurs années les versions sécurisées des protocoles ftp et http. Par contre, la version sécurisée du protocole smtp est moins connue et certains de nos clients (4%) ne sont pas compatibles.

Nous avons changé de serveur smtp pour être capable de s’adapter à chacun, en fonction de son niveau d’exigence. En effet, notre nouveau serveur SMTP négocie avec le serveur mail du client le plus haut niveau de chiffrement commun. Une fois la communication établie, nous émettons les mails par ce canal sécurisé. Pour nos clients non équipés, les mails sont envoyés de façon non sécurisée.

À l’occasion de cette mise en place, nous avons aussi amélioré notre réputation auprès des systèmes anti-spam.

Mise en place d’un WAF (firewall applicatif)

Le firewall applicatif est une protection permettant de se prémunir des attaques de type injection SQL. Cette attaque est toujours au rang 1 du classement des vulnérabilités de l’organisation OWASP. 

Le WAF permet d’analyser les requêtes entrantes et de bloquer les attaques. Le paramétrage du WAF a été assez long à affiner pour réduire le taux de faux positifs (le blocage d’un usage normal) tout en gardant une protection optimale. C’est maintenant chose faite. Le WAF est donc configuré en liste blanche.

Nous détectons une tentative d’attaque par injection SQL en moins de 5 minutes.

Transmission des cookies uniquement en https

Nous avons appliqué une recommandation du rapport d’un audit de sécurité réalisé sur notre plate-forme : bloquer le transfert des cookies lorsque le transfert est non sécurisé.

En effet, lors du premier appel, il est courant que l’utilisateur ne saisisse pas le “s” dans l’adresse httpS://client.ilucca.net.

S’il a déjà visité le site, il est probable qu’il ait des cookies de session.

Un cookie de session est une information nécessaire au bon fonctionnement d’une application web. Cette information est stockée sur l’ordinateur de l’utilisateur par son navigateur, et transmis à notre serveur à chaque échange.

Cet échange est sécurisé si le protocole https est utilisé. Par contre, lors du premier appel, le cookie était envoyé de façon non sécurisé.

Désormais, les cookies sont absents des échanges non sécurisés.

Lien vers le problème décrit par OWASP : https://www.owasp.org/index.php/HttpOnly

Protection contre le clickjacking

Le clickjacking est une attaque qui consiste à intégrer un site dans un autre, via une iframe, de façon à masquer l’adresse du sous site.

Pour protéger nos clients de ce type d’attaques, nous avons suivi les recommandations d’OWASP en interdisant l’intégration de nos applications dans des iframes.

En amont, nous avons détecté puis contacté l’ensemble des clients concernés par une telle intégration.

Lien vers le problème décrit par OWASP : https://www.owasp.org/index.php/Clickjacking

 

 

Cet article vous a-t-il été utile ?
Utilisateurs qui ont trouvé cela utile : 0 sur 0
Vous avez d’autres questions ? Envoyer une demande

Commentaires