Conseils — 22/10/2012 at 14:50

Sécurité Ecommerce : Les bons réflexes

by

Sécurité du Ecommerce : 10 bonnes pratiques

De plus en plus de propriétaires de sites sont de nos jours victimes de fraudes, scam, phishing et intrusion, il est donc important de donner quelques tips concrets, issue de notre labo sécurité à NBS System, pour vous aider à vous défendre.

1/ Les mots de passe

C’est une des clefs de la sécurité et pas des moindre. Nous avons écrit toute un howto spécifiquement sur le sujet sur le site de NBS. Si vous voulez aller droit à l’essentiel, sans la théorie, vous pouvez directement aller là : construire ses mots de passes.

Pour faire court : On les change tous les 3 mois, on utilise une phrase plutôt qu’un mot si possible et ce mot de passe business ne doit pas être réutiliser ailleurs.

Tips supplémentaire : Utilisez un navigateur spécifique pour votre administration de site, que vous n’utilisez que pour cela. En effet, certaines attaques informatiques permettent de compromettre un site dans un autre onglet à partir d’une page chargée dans un autre onglet.

2/ Un compte = un utilisateur

Cela a aussi une vertue en terme de temps de réponse du back office mais pour ce qui est de cet article, ce point est critique en terme de sécurité.

Un compte ne doit être utilisé que par un utilisateur pour plusieurs raisons, entre autres :

  • Cela permet de tracer les actions (qui/quoi/quand/comment)
  • Cela permet de séparer les rôles (gestion de catalogue, gestion du CMS, de la CRM, des retours, etc.)
  • Cela permet de ne changer qu’un mot de passe si un collaborateur s’est fait compromettre son poste ou quitte l’entreprise
  • Le personnel est plus attentif à ses actions

3/ La protection du backoffice et du Phpmyadmin

En 14 ans de métier, je ne me suis jamais fais compromettre un site et, assez souvent, c’est ce tips qui m’a sauvé.

Quand le framework de votre site contient une vulnérabilité non publique, des petits malins peuvent tenter de s’y introduire. C’est une cible principal des chercheurs en sécurité, comme des pirates. Afin de calmer toute véléité intrusive, mettez une “pré authentification” sur le backoffice. Une simple authentification HTTP. Il en va de même pour le fameux phpmyadmin, qui ne donne rien de moins qu’accès à vos bases de données.

Pour le coup, vous pouvez donner le même login et le même passe à tous les utilisateurs pour cette préauthentification. Pour mettre en place une protection de ce type, c’est très simple (un article ici le décrit), voici un exemple, dans le fichier vhost ou celui de configuration de votre Apache, ajoutez les lignes suivantes :

  1. <Location /phpmyadmin >
  2.   AuthType Basic
  3.   AuthName “Restricted Area”
  4.   AuthUserFile /etc/apache2/access/htpasswd
  5.   Require valid-user
  6. </Location>

Ensuite lancez, en ligne de commande (shell), la commande pour créer le login et le mot de passe :

htpasswd -c /etc/apache2/access/htpasswd backoffice

(Refaire la même manipulation pour votre phpmyadmin.)

Si vous utilisez souvent votre backoffice depuis une même IP fixe, par exemple celle de bureau, vous pouvez ajouter une exception dans le fichier pour ne pas demander d’authentification, afin d’alléger le processus (c’est un peu moins bien mais tolérable et cela améliore l’exploitabilité), voici un exemple sur notre site (en wordpress), avec un accès autorisé pour une IP :

  1. <Location /wp-login.php>
  2.    AuthType Basic
  3.    AuthName “Restricted Area”
  4.    AuthUserFile /etc/apache2/access/htpasswd-nbssystem-public
  5.    Order allow,deny
  6.    Allow from 100.100.100.100
  7.    Require valid-user
  8.    Satisfy Any
  9. </Location>
Tips supplémentaire :Il est possible d’empêcher l’accès à toutes les extensions de fichiers non spécifiquement traités (comme les .php ou .js)

<filesmatch>   Order allow,deny   Deny from all  </filesmatch>

Si vous avez un fichier de backup “.save” ou “.inc~”, Apache refusera de le servir avec cette commande “catch all”.

4/ Limiter le nombre de plugins / extensions

Avoir 200 plugins, c’est s’exposer à de nombreuses failles de sécurité. En effet, chacun fait son bout de code dans son coin, ne mène quasi jamais d’audit de sécurité et au final, vous importer ce code vulnérable dans votre site. Inviteriez vous un malade de la peste à diner avec votre petite famille ? Non, donc vérifiez bien la provenance de vos plugins (ils peuvent aussi contenir des backdoors volontairement) et prenez des précautions dans le choix.

Tips supplémentaire : Plus le nombre de plugins est grand, plus la surface de code exposée à des vulnérabilité est importante. Enfin, votre site ne s’en portera pas plus mal en terme de performances non plus.

5/ Les droits des fichiers

Ca ne fonctionne pas ? “Met tout en 777……..”

Non. Ce n’est pas la solution. Mettez le bon utilisateur, le bon groupe (avec la commande chown) et limitez les droits à l’essentiel.

Ce n’est pas toujours une menace directe, mais ca peut considérablement faciliter une intrusion.

  • Pour les fichiers PHP : chmod 644
  • Pour les médias, css et js : chmod 644
  • Pour les fichiers html : chmod 644
  • Pour les répertoires : 755

Si vous avez un répertoire d’upload, de sessions ou de cache, vous pourriez avoir à mettre des droits spéciaux, mais c’est le seul cas à ma connaissance.

Si vous cherchez allinurl:/app/etc/local.xml dans Google vous aurez des exemples de ce qu’il en coûte de ne rien faire à ce sujet…

6/ Les paramètres PHP

Certains mécanismes sont disponibles dans PHP pour limiter les risques de sécurité.

Couper les fonctions suivantes peut être une bonne idée si votre framework peut s’en passer :

  • show_source
  • system
  • shell_exec
  •  passthru
  • exec
  • phpinfo
  • popen
  • proc_open
  • proc_nice

Dans votre php.ini, ajouter : disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open, proc_nice

Ajoutez aussi register_globals = Off (évite que vos variables get & posts soient toutes globales et donc accessibles)

allow_url_fopen = Off & allow_url_include = Off éviterons que vos pages puissent inclurent des contenus externes (donc non contrôlés)

open_basedir = "/var/www/:/opt/www"

vous permet de limiter l’execution de PHP à ces deux directory.

safe_mode = On

Le problème du safe mode est que lorsqu’il est mis à ON, il est très restrictif et ne laisse que les fichiers php possédé (chown) par l’utilisateur faisant tourner apache se lancer. Cela à beau être le meilleur niveau, il peut être intéressant en cas de contributeur multiples d’avoir un safe_mode à Off mais un safe_mode_gid = On.

display_errors = Offexpose_php = Off

vous permettent eux de ne pas en révéler plus que nécessaire.

Au final, ajoutez à votre fichier php.ini (et testez si tout fonctionne après, au besoin alléger le durcissement) :

  1. disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open, proc_nice
  2. register_globals = Off
  3. allow_url_fopen = Off > allow_url_include = Off
  4. open_basedir = “/var/www/:/opt/www” 
  5. safe_mode = On                    # au pire : safe_mode=Off et safe_mode_gid = On
  6. display_errors = Off
  7. expose_php = Off

7/ Le filtrage des adresses IP

Cela n’est pas toujours nécessaire de laisser les fonctions d’accès Shell et FTP/SCP/SFTP ouvert à tous, pas plus que les accès backoffice, depuis toutes les IP.

Pour limiter les accès SSH / FTP / SCP / SFTP, votre hébergeur peut le faire sur son Firewall, vous pouvez souvent le faire aussi “en local” dans votre Shell :

En pratique, vous pouvez faire une ligne de commande :

  1. iptables -I INPUT -[MON_IP] -j ACCEPT
  2. iptables -P INPUT DROP

Pour protéger le backoffice par IP, faire une variante du point 3 de cet article.

Pour rendre cela plus permanent (après un reboot par exemple), n’oubliez pas de faire un fichier rc3.d et un dans le rc6.d.

8/ Enlevez vos github et autre

Laisser traîner des fichiers sensibles dans vos répertoires est une mauvaise idées. Un petit fichier de configuration config.php de wordpress oublié, avec un ~à la fin et tous les mots de passes sont révélés… Mon ami Sébastien Lepers de Meliweb me soulignait récemment, et à raison, que laisser aussi les github dans les répertoires n’est pas l’idée du siècle. Je quote le mail qu’il m’a envoyé à ce sujet :

Par exemple, si on accède à http://www.monserveur.com/.git/COMMIT_EDITMSG qui est un fichier toujours présent si le projet est versionné sous Git, on a des infos du type :

# Changes to be committed:
 # (use "git reset HEAD <file>..." to unstage)
 #
 # modified: js/jquery/library.js
 #
 # Changed but not updated:
 # (use "git add <file>..." to update what will be committed)
 # (use "git checkout -- <file>..." to discard changes in working directory)
 #
 # modified: .htaccess
 # modified: .htpasswd
 #
 # Untracked files:
 # (use "git add <file>..." to include in what will be committed)
 #
 # backup-20120927.sql.gz
 # media.tar.gz
 # media/import/
 # medias

Et hop, une base de données téléchargeable… Dommage.

9/ Surveiller votre Framework

Il existe de nombreux sites, mailing listes et autres systèmes de surveillance. Les CERT, les systèmes de veilles sécurité, la bugtraq (security focus) et pléthore de blogs à ce sujet. Regardez donc si vos systèmes de Ecommerce n’ont pas de temps à autres une faille de sécurité, c’est toujours très dangereux et ca arrive une à deux fois par an par framework, même au meilleur.

Magento, pourtant très propre sur ces aspects en a connu (la dernière en date était dû à Zend et pas à Magento lui même cependant), Joomla est un récidiviste, les plugins WordPress se font souvent allumer, Prestashop en a connu et corriger, tout le monde y a droit…

Regardez le blog de l’éditeur de temps a autres également et demander à votre hébergeur de rester attentif sur le sujet.

Tips supplémentaire : Un petit Google Alerts par exemple pourra vous aider à rester informer sur le sujet. Mettez par exemple : ”votre framework” et “faille de sécurité” ou “security” ou “flaw” ou “vulnerability”. Quand rien ne se passe, pas de mail, sinon, vous êtes alerté. Avec 4 alertes, vous êtes sûr de ne rien rater :

10/ Phishing

Le Phishing, c’est une plaie.

Si votre site est un peu connu, il n’est pas impossible qu’un petit malin tente de frauder vos clients en envoyant un mail “de votre part” pour essayer d’obtenir ses accès. Dans ce cas, il faut rester attentif au retour des utilisateurs du site (qui le signale en général) et avoir un ou deux faux clients avec des emails à vous (sur un Gmail par exemple) dans votre bases (au cas où elle aurait été volée).

Il est aussi possible de souscrire à des services de détection de Phishing et de garder une boite à spam, que l’on va inscrire sur tout ce qu’il est possible de compter comme site de pollueurs du web, mettre en commentaire dans des blogs et laisser cette boite se faire pourrir de mails de spam et de phishing. Mais si un de ces mails vient de votre nom de domaine ou vous cite dans son corps de message, faite une règle qui vous en informe.

Conclusion

Pour finir, il n’est pas illégitime de parler de ce que l’on fait non plus. Vous pouvez donc choisir un hébergeur qui a une sensibilité particulière à la sécurité, comme NBS System, puisque nous faisons du tests d’intrusion depuis 13 ans, c’est même l’ADN d’origine de la société. Nous développons aussi NAXSI, un WAF opensource tout à fait gratuit et très performant, largement utilisé.

Enfin, NBS System lance CerberHost, une offre d’hébergement de sites LAMP en très haute sécurité, avec plus de 15 mécanismes de protections participants ensemble à une sécurisation profonde des sites.

2 Comments

  1. Pingback: Sécurité Ecommerce : Les bons r&e...

  2. This is my first time pay a visit at here and i am actually impressed to read
    everthing at alone place.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>