fév 27

Et voila, ca nous arrive tous un jour ou l’autre, moi c’est aujourd’hui.

Grâce à la publication différée d’article, je peux vous faire le pied de nez d’être dans l’avion au moment où ces lignes sont rendues visibles sur le site.

Je vous reviendrai après une dizaine de jours dans la savane Béninoise (si aucune lionne ne me trouve à son goût).
Inutile de vous dire qu’au Bénin, dans la brousse, la 3G ce n’est pas ça et c’est tant mieux !

Dans l’intervalle, je vous confie aux bons offices de mes camarades auteurs de Wikigento, qui vont occuper un peu le terrain en mon absence, j’en suis sûr !

écrit par Philippe Humeau

fév 26

Le but de cet article est de vous faire découvrir un aspect très important de Magento et pourtant  peu sexy car il s’adresse plus aux développeurs qu’aux marchands.

Cette petite bête s’appelle Web Service ou API et derrière ce nom d’insecte se cache l’une des fonctionnalités les plus importantes de Magento dans le cadre de l’intégration d’une boutique Magento à un système d’information.

Lire la suite »

écrit par Fabrice Beck \\ tags: , , , , , , , , ,

fév 25

La méthode est un peu « rustre », très système et réseau et pas réellement dans les méthodes des développeurs mais parfois, elle peut faire gagner un temps phénoménale…

Mais de quoi il parle…?

Appliquer une modification dans des pages de code. Par exemple remplacer un mot par un autre ou même appliquer le patch de Gabriel contre les XSS de Magento super rapidement dans tout le code de Magento. Si si c’est possible, Adrien (un collègue en charge des infrastructures Magento), nous offre un peu de ligne de commande qui colle aux dents mais qui rend bien service. Bon, vous avez besoin d’un shell sous unix avec des droits décents et quelques utilitaires qui sont installés par défaut sous presque tous les BSD et Linux. (Avec la remise en forme du texte par WordPress, je ne sais pas si ca se copie/collera correctement, mais voici les synthaxes, les quotes ‘ vont probablement mal passer en CTRL C/CTRL V)

find /var/www/htdocs -type f -print0 | xargs -r -0 sed SED_EXPRESSION

On va chercher avec la commande « find » dans le répertoire qui nous intéresse (ici /var/www/htdocs), les fichers uniquement et envoyer tout cela à « sed ». Pour ceux qui ne sont pas familier de la ligne de commande unix et de bash en général, c’est un peu abstrait, ca fait peut mais c’est pas bien méchant.  (pour les connaisseurs, on pourrait aussi utiliser –exec) Il faut découper :

find /var/www/htdocs -type f -print0

touve moi tous les fichiers dans le répertoire /var/www/htdocs et ses sous directory et affiche le résultat.

| (prononcer païpe, comme un tuyau en anglais)

et passe le résultat de tes recherches (donc la liste de tous les fichiers) à  :

xargs -r -0

qui est un programme qui reformatte les lignes de commandes (en l’occurence pour son copain sed)

sed SED_EXPRESSION

et lance sed avec l’expression qui va bien, sans effectuer les modifications (il faut ajouter -i pour cela)

Justement… L’expression. C’est là que se situe la magie de ces syntaxes de barbares. Car avec la bonne expression, on va appliquer un traitement à tous les fichiers !!! Si on trouve l’expression cherché, on va la remplacer par une autre, c’est ca le boulot de sed. On cherche et on remplace avec ce que l’on appel une Regexp (pour régular expression), c’est une grammaire descriptive pour décrire une chaine de caractère. Je n’ai pas réellement le temps de vous l’expliquer en détail, googlez un peu et vous trouverez.

Allez, on applique le patch de Gabriel à tout ce qui ressemble de prêt ou de loin à un retour d’erreur non filtrée.

si on cherche ça : « <?php echo $* ?> » et qu’on veut le remplacer par ça : « <?php echo htmlentities($*) ?>« 

l’expression c’est ça : ‘s/<?php echo $\([a-zA-Z0-9_]\+\) ?>/<?php echo htmlentities($\1) ?>/g’
(et on ne touche pas à *, en gros au nom de la variable)

donc sed 's/<?php echo $\([a-zA-Z0-9_]\+\) ?>/<?php echo htmlentities($\1) ?>/g' ou si on réinsère ca dans notre recherche avec find :

find /var/www/htdocs -type f -print0 | xargs -r -0 sed ‘s/<?php echo $\([a-zA-Z0-9_]\+\) ?>/<?php echo htmlentities($\1) ?>/g’

Le petit inconvénient, c’est que la synthaxe est stricte, à l’espace pret. Donc si c’est écrit différemment à deux endroits du code, ca ne remplacera pas tout. Deuxième chose, si le paramètre remplacé est un tableau ou une fonction, la synthaxe sera peut être différente. Pour ne pas avoir de doute, on peut utiliser ou grep -ro pour vérifier avant que tout est bon, ceci affichera ce qui va être traiter avant de faire quoique ce soit :

grep -hro ‘<?php echo $\([a-zA-Z0-9_]\+\) ?>’ /var/www/htdocs

Pour le cas de l’url du downloader (le XSS en GET pas beau) voici la synthaxe sed :

find /var/www/htdocs -type f -print0 | xargs -r -0 sed ‘s/\$this->set(‘return_url’, \$_GET[[]‘return’[]])/\$this->set(‘return_url’, htmlentities(\$_GET['return']));/

Et vous savez quoi ?

L’inconvénient, c’est que le patch de Gabriel est efficace mais il n’est pas persistent (lorsque vous mettrez à jour Magento, les correctifs vont sauter alors que Varien n’aura peut être pas patché les vulnérabilité.

Le deuxième défaut, c’est que seul 3 failles ont été révélées, si ca se trouve, il en existe d’autres.

La bonne nouvelle c’est que la méthode de bourrin proposée, elle ne fait pas de quartier. Elle trouve, elle remplace que ce soit sur les fichiers et failles identifié ou non. Elle vous remplacera donc potentiellement aussi des failles non encore dévoilées ;)

Deuxième avantage, si vous montez de version, vous pouvez relancer la même commande, elle refera le boulot sans que vous ayez à éditer quoique ce soit. Vu le rythme de publication des versions de Magento, ca peut être confortable.

Merci à Adrien pour les regexp ;)

écrit par Philippe Humeau \\ tags:

fév 25

Alors, puisque la sécurité semble venir sur le devant de la scène Magento et que, par pur hasard, votre serviteur a fait un peu de sécurité avant de faire de l’hébergement Magento. Puisque de surcroit vous avez des questions sur le sujet, un petit article s’impose. On va faire simple car la sécurité n’est pas le thème de ce blog et donc il ne faut pas lasser le lectorat mais on va réadapter une pensée de Lao Tseu pour l’occasion :

« Montre à un développeur une XSS, il l’a corrigera. Apprends lui comment ça marche, il n’en fera plus ! »

Du moment que la pensée de Lao Tseu débattue n’est pas :
« Quand le sage montre une XSS du doigt, l’idiot regarde le doigt »

ca ne sera pas du temps perdu !

Plus sérieusement : une XSS, ça fait peur! C’est un peu comme une maladie honteuse dont on ne saurait pas trop ce qu’elle fait et à quoi ça peut bien mener. Certains diront que l’on crie au loup, d’autres savent la portée et le résultat de ce genre de faille.

Principes généraux

XSS pour Cross Site Scripting. Soit en gros, répandre du code dans un site. Le but (pour le pirate) c’est de faire s’afficher, non pas du html que votre navigateur affichera, mais de renvoyer du langage de script (javascript notamment) que votre navigateur interprétera.

Si on fait simple, imaginons que quelqu’un post dans ce blog un commentaire en Javascript qui soit <script>alert(123)</script> et que mon blog ne soit pas protégé contre ca. Quand vous allez afficher le commentaire dans votre navigateur, il ne va pas mettre le texte <script>alert(123)</script> dans une page HTML et vous montrer le texte mais il va lancer ce code Javascript et ouvrir une boite de dialogue qui contiendra le texte « 123 ».

Pour la démonstration, les experts en sécurité ne se prennent pas la tête à mettre un code complexe, il suffit de prouver que la boite d’alerte s’affiche, si elle le fait, on peut ensuite mettre ce que l’on veut comme script à la place et que la XSS est présente.

L’exemple est bénin, mais…

Si à la place d’une gentille popup box qui affiche 123, mon navigateur se met à faire des choses plus discrète et plus gênante ? Par exemple, créer une Iframe invisible en surimpression de la page que je consulte ? Iframe qui va envoyer les informations vers un autre site contrôlé par un pirate ? Ce n’est pas de la science fiction, c’est même très simple à faire pour un professionnel. Mais le Javascript, surtout couplé à Ajax, c’est encore plus puissant que ca. On peut écouter les frappes clavier, scanner le réseau local de la victime, altérer son affichage de page web, effectuer des opérations sur les sites ou il est authentifié, lui voler ses sessions, bref, ca peut être très dangereux, selon les cas, les circonstances etc…

Le cas des trois XSS de Magento

Ok, vous avez compris, le XSS ce n’est pas du tout anodin. Dans le contexte des 3 failles Magento, on risque quoi plus précisément ? Pour les  deux premières présentées dans cet article, pas grand-chose. Disons que le risque est présent mais que l’exploitation est complexe car la méthode utilisée est un POST et non un GET. En gros, à la place de l’administrateur légitime, il faudrait saisir « > <script>alert(123)</script> dans le champ login. Et à la place de (123), mettre le code source Javascript d’un cheval de Troie. (ca existe, ca se trouve sans soucis)

Comme l’administrateur légitime ne le fera pas de lui-même, ça implique, si l’utilisateur est déjà loggé sur son backoffice, de l’amener à se connecter à un site contrôlé par le pirate, qui va faire du scripting dans son dos avec la faille XSS, pour tenter de prendre le contrôle de sa session. (Le POST sera alors « transparent »)

Si l’utilisateur n’est pas loggé, ca implique toujours de l’envoyer vers un site contrôlé par le pirate et à utiliser ce site pour lancer un javascript qui va écouter les frappes clavier, pour obtenir son password de backoffice, en espérant qu’il ne ferme pas l’onglet du site compromis (et ne fasse pas de reload ou de back) pendant qu’il se loggera sur son backoffice. Le taux de réussite est moyen, la patience est de rigueur mais ce n’est pas infaisable. Disons que pendant nos tests d’intrusion, on a un taux d’environ 20% sur ce type d’attaque.

Dans les deux cas, exploiter ces XSS en méthode « POST » c’est un peu complexe et ca s’assimile plus à une exploitation de type CSRF. Ce n’est pas infaisable mais le script kiddie du coin ne maîtrise pas ce genre d’attaque un peu complexe (heureusement). Ca reste mal mais pas catastrophique puisque la barre d’entrée est assez élevée.

Par contre, la troisième, le downloader… Ça c’est très dangereux.

Quand j’appelle :
http://mon_site_magento/ downloader/?return=%22%3Cscript%3Ealert(123)%3C/script%3E

Je fais un GET et non un POST et ca change tout ! En fait ca simplifie tout !

Par exemple, un simple fakemail (usurpation d’identité) permettra à l’attaquant d’envoyer un lien piégé, contenant du Javascript nuisible et adapté, ce qui lui donnera le contrôle des prochaines actions qui seront effectuées. L’idée est simple, le mail affiche un lien normal vers le backoffice, le lien en réalité contient le XSS et donc du Javascript d’écoute du clavier (par exemple) et ensuite vous vous loggé… Perdu.

Ecrire un fakemail, c’est le paragraphe 1 du chapitre 1, du manuel du pirate. Vous pouvez même le faire en changeant votre nom dans outlook, c’est déclaratif… Je peux vous envoyer un mail de la part de [email protected] en 10 secondes. Alors si un pirate se fait passer pour le patron de la boite et demande par mail à la personne en charge du backoffice de se connecter (lien dans le mail) et de contrôler les ventes, vous pensez qu’elle va faire quoi la personne en question ?

C’est une attaque très simple à mener donc très dangereuse et là, le script kiddie peut prendre le contrôle de votre backoffice.

Où Varien a t’il fait un oubli ?

Well, pour les deux premières, l’explication vient d’un oubli dans le contrôle des sorties d’erreur. Je tape n’importe quoi dans la case « nom d’utilisateur » et le système me réaffiche ce que j’ai tapé pour me dire que ce n’est pas le bon login.

Si l’utilisation du framework Zend avait été uniforme et/ou si les retours d’erreurs avaient été nettoyés avec une fonction PHP du nom de htmlentities(), le problème n’aurait même pas existé. Ce qui est vrai pour Varien l’a été pour un nombre hallucinant de soft et ne riez pas avant d’avoir relu vos propres codes sources.

Cela peut-il se reproduire ?

Ouiiiiii, bien sûr.

Un oubli, une fois, un lendemain de soirée arrosée ou encore un « ballmer peak » d’un développeur et hop…
C’est la XSS. J’exagère un peu dans le sens ou, normalement, on code dans le framework Zend et on applique une revue de code, on test tout, on utilise des vérificateurs statiques ou dynamiques de code source etc… Cela devrait donc se produire très rarement voir pas. Varien a été sensibilisé cette fois ci, ca éveille leur attention sur ce point, la chasse est lancée et les consignes passées je pense. De plus, en un an, c’est la première alerte sécurité.

Mais… Si Varien gagnait un peu plus sa vie ? Si Magento leur rapportait plus d’argent, qu’ils avaient plus de partenaires etc… Ils auraient pu s’acheter les outils d’analyse statiques et dynamique dont je parle. Ma boite fait (aussi) du test de sécurité sur des soft/site Web, donc forcément on a  ce genre d’outils, mais ca coûte cher, très cher, or pour le moment, Varien à des moyens limités, une roadmap à respecter et pas des milliers de dollars à lancer par les fenêtres pour acheter ce genre de prestations ou d’outils.

Je vais voir si mon équipe de tests de sécurité aurait le temps de se pencher un peu dessus au prochain creux de production.

Allez, on applique les correctifs maintenant qu’on sait que c’est dangereux !

Celui de Gabriel de Fragento : ICI
ET (OU seulement dans le pire cas)
Celui de Wikigento : ICI

écrit par Philippe Humeau \\ tags:

fév 25

Correctifs des XSS Magento

1°) Mettre à jour en 1.2.1.1 ne résoud pas le problème.

2°) Gabriel de Fragento a préparé un Patch correctif pour Magento

Voici une solution de la maison, en 3 étapes, qui fonctionne de suite si vous avez le moyen de modifier les réglages de votre VirtualHost Apache ou de le faire faire par votre hébergeur.

(De tête, mais ça devrait marcher sous la plupart des Linux, avec un shell root)

Etape 1 :

CTRL+C (copier) de ce qu’il y a ci-dessous :

<LocationMatch “/admin » >
AuthUserFile /var/www/htdocs/.htpasswd
AuthType Basic
AuthName “Magento Backoffice Login”
Require valid-user
</LocationMatch>


<LocationMatch “/downloader » >
AuthUserFile /var/www/htdocs/.htpasswd
AuthType Basic
AuthName “Magento Backoffice Login”
Require valid-user
</LocationMatch>

Insérez ca dans la configuration du virtualhost de votre site (par exemple)
cat >> /etc/apache2/sites-available/magento

CTRL+V (coller)
CTRL+D (ça stop la saisie dans le fichier et le sauve)

Remplacez /var/www/htdocs/.htpasswd par le bon chemin de votre site et /etc/apache2/sites-available/magento par le chemin vers le fichier de virtualhost de votre site.

Pouvoir le faire en .htaccess aurait été l’idéal car même sans être root sur la machine, vous auriez pu patcher le problème sur votre hébergement mutualisé, mais… La directive « LocationMatch » ne fonctionne pas en .htaccess… :-(

Etape 2 :

Créez un fichier .htpasswd :
htpasswd -c /var/www/htdocs/.htpasswd backoffice
chown root.root /var/www/htdocs/.htpasswd
chmod 644 /var/www/htdocs/.htpasswd


Le programme vous demande un mot de passe, mettez en un décent. (au moins 8 caractères dont deux spéciaux) et idem, remplacez par le bon chemin pour le site, le chown et le chmod mettent des droits raisonnables sur ce fichier htpasswd.

Etape 3 :

Redémarrez Apache : /etc/init.d/apache2 restart
(un reload suffit peut être d’ailleurs, je ne sais plus)

Vérification :

Retournez à votre Admin, vous devriez avoir une fenêtre qui vous demande un login & un pass, utilisez le login backoffice et le mot de passe que vous avez tapé. Ne pas faire « retenir mon mot de passe » dans votre browser.

PS : N’oubliez pas que dans la conf d’apache (généralement /etc/apache2/apache2.conf) il doit y avoir ça :
<Files ~ « ^\.ht »>
Order allow,deny
Deny from all
</Files>

Pour empêcher qu’on puisse télécharger vos fichiers .htaccess et .htpasswd (ceci dit ca y est par défaut normalement)

Ajout par Gabriel de Fragento.org

En attendant un correctif officiel, Fragento vous propose des patchs maison :

1) Correctif pour le Downloader

Dans le fichier : downloader\Maged\Model\Session.php
A la ligne n° 58

Remplacez le code :

if (!empty($_GET['return'])) {
$this->set(‘return_url’, $_GET['return']);
}

Par :

if (!empty($_GET['return'])) {
$this->set(‘return_url’, htmlentities($_GET['return']));
}

2) Correctif pour la page de login

A défaut de modifier le noyau – ce qui empêcherait toute mise à jour, modifiez le template de l’administration.

Dans le fichier : app\design\adminhtml\default\default\template\login.phtml
Ligne : 54

Remplacez le code :

value= »<?php echo $username ?> »

par :

value= »<?php echo htmlentities($username) ?> »

3) Correctif pour la page de renvoi du mot de passe

A défaut de modifier le noyau – ce qui empêcherait toute mise à jour, modifiez le template de l’administration.

Dans le fichier : app\design\adminhtml\default\default\template\forgotpassword.phtml
Ligne : 57

Remplacez le code :

value= »<?php echo $email?> »

par :

value= »<?php echo htmlentities($email) ?> »

Remarques :

  • Vous êtes fortement invités à diffuser le lien du sujet sur Fragento afin d’éviter des déconvenues aux utilisateurs de Magento ayant un site en production
  • Si vous copiez/collez les bouts de codes, assurez-vous que les guillemets sont conservés
  • D’une manière générale n’accédez jamais ni au Downloader ni à l’Administration via un lien fourni par une personne tierce, mais toujours par un accès direct, pour éviter tout risque de phising
  • Ces correctifs n’affectent pas les fonctionnalités de Magento
  • Tout avis d’un autre développeur sur ces correctifs « rapides & maison » est bienvenue ! Je n’ai pas la prétention que ces correctifs soient les seuls possibles, et je ne garantis pas leur efficacité pleine et totale (même si après test toute injection de code est demeurée vaine)

écrit par Philippe Humeau \\ tags:

fév 24

Aïe, comme une prémonition, le post du 23/02 sur la sécurité se trouve malheureusement très adapté à la situation :
3 failles de sécurité de type XSS, cross site scripting, viennent d’être révélées sur Security Focus ce jour à propos de Magento v1.2.0.

Numéro CVE :
CVE-2009-0541
Numéro Bugtraq : 33872

En effet, trois failles de sécurité de type XSS (voir post du 23/02/2009 sur la sécurité) sont présentes dans Magento 1.2.0 et probablement dans les précédentes versions également. La primauté de cette découverte revient à Loukas Kalenderidis de Sens Of Security. Du coup, je me dis que ca vaudrait le coup de passer un test un peu en profondeur à la chasse d’autres XSS, sait on jamais. De toute façon, le « Web 2.0″ c’est une mine en terme de sécurité, si ca vous intéresse, ici, un article que j’ai publié il y a quelques années dans Hackin9 à ce sujet (il n’y a pas tout, notamment l’anti DNS pinning n’y est pas de mémoire, mais ce sont de bonnes bases).

Pas de panique, la très grande majorité de Magento repose sur Zend qui est un Framework solide donc on ne devrait pas en avoir des tonnes d’autres mais il va falloir être vigilant. De plus Varien a été prévenu par l’auteur de ces 3 failles le 21/01/2009. Yoav (Directeur Technique de Varien) a probablement lancé la chasse dans le reste du code mais Gabriel de Fragento nous indique que sur une 1.2.1.1 il a repéré le même XSS comme fonctionnel (voir commentaire). Le problème ne serait donc pas résolu malgré le fait que Sens Of Security a joué dans les normes visiblement, l’éditeur à été prévenu un mois avant la publication, ce qui semble un délai raisonnable.

Voila ce qui arrive quand on développe en dehors du framework Zend ou que l’on ne contrôle pas assez ses retours d’erreurs… Les risques de ce type, les XSS, principalement sur l’admin du backoffice, sont non négligeables.

Actions à mener rapidement

  1. Upgradez votre Magento ! Dès qu’une version corrigée sera disponible. Pour le moment, la dernière c’est la 1.2.1.1 au moment de la rédaction de ce billet, c’est donc une montée de version mineure si vous êtes déjà en 1.2.x, donc pas ou peu de problème (si vous n’avez pas codé dans le Core). Par contre si vous êtes en pré 1.2, ça risque d’être un peu plus sportif. De toute façon la version actuelle ne semble pas régler tout le problème.
  2. Mettez le bout de conf apache qui est en bas dans le fichier de virtualhost de votre site (ou faite le faire à votre hébergeur). Ça protégera votre backoffice, XSS ou pas.
  3. Sinon, vous pourrez prochainement appliquer le correctif logiciel qui nous sera fournit par Gabriel de Fragento

Les failles en elles mêmes

Vulnérabilité 1, page de login d’administration

Quand vous ratez un login, la valeur que vous allez entrer dans le champ « nom d’utilisateur » va être renvoyé à l’utilisateur sans encodage de la réponse :

  1. Allez sur la page d’administration (http://monmagento/index.php/admin ou quelque chose du genre si il y a un rewriting ou une autre racine du site, bref le /admin quoi)
  2. Entrez dans le champs « nom d’utilisateur » : « ><script>alert(123)</script>
    (attention, le blog est susceptible d’encoder les caractères spéciaux, il faut donc le taper « à la main », le copier/coller ne marchera peut être pas)
  3. Entez n’importe quoi dans le champ « mot de passe »
  4. Cliquez sur « Identifiant » et roohhhhh, une boite javascript qui vous confirme que le code dans le champ a été renvoyé sans encodage et donc exécuté par votre navigateur…

(j’ai également vérifié sur une version 1.0.x et ca marche donc il y a de grande chance que toutes les versions entre 1.0.x et 1.2.0 soient vulnérables)

Vulnérabilité 2, page « J’ai oublié mon mot de passe »

(déjà dans le principe, si tu oublie ton mot de passe admin du nackoffice, on se demande s’il est raisonnable que tu es accès à ce genre de fonction…)

  1. on se rend sur http://monmagento/index.php/admin/index/forgotpassword
  2. Dans la case email on met : « ><script>alert(123)</script>
    (attention, le blog est susceptible d’encoder les caractères spéciaux, il faut donc le taper « à la main », le copier/coller ne marchera peut être pas)
  3. on clique sur « retrieve password » et hop, une boite javascript qui annonce qu’on est vulnérable

Allez, quand on a un filon on le lâche pas,

Vulnérabilité 3, page « Magento Connect Downloader »

Là c’est directement dans l’URL qu’on peut encoder le XSS :
http://monmagento/downloader/?return=%22%3Cscript%3Ealert(123)%3C/script%3E
(attention, le blog est susceptible d’encoder les caractères spéciaux, il faut donc le taper « à la main », le copier/coller ne marchera peut être pas)
et vous connaissez l’histoire de la boite javascript tout ça tout ça…

Bon, allez je vous laisse, j’ai des clients à prévenir qu’il faut upgrader leurs Magento ;)

Conclusion, comme d’habitude : la sécurité à un coût mais elle n’a pas de prix !

Les correctifs ont été déplacés dans un post dédié : ICI

écrit par Philippe Humeau \\ tags: , ,

fév 24

Partout où l’on ne l’attends pas, inclassable, Wikigento frappe de nouveau avec quelque chose qui n’a rien à voir avec les performances de Magento :-)

C’est comme pour la sécurité il y a 2 jours, c’est connexe à Magento même si ce n’est pas directement le sujet. Ceci étant, vos commentaires et vos mails prouvent que c’est aussi ce que vous attendez de ce Blog, alors Mt Garance Mathias nous fait part d’une partie de son expérience et vous offre « la Todo list juridique du Web marchand » d’un point de vue Juridique. Tout comme pour la sécurité, c’est un vaste domaine, très complexe, ceci est donc un résumé rapide, fait pour aider, mais ne constitue en aucun cas un référentiel juridique exhaustif.

Elle n’est pas encore blogeuse mais je lui transmettrai vos commentaires et/ou questions, vous pouvez également la joindre sur l’adresse email ci-dessous.

La « To Do List » du Webmarchand

(par Mt Garance Mathias)

Durant ou après la création de son site Internet, le web marchand doit répondre à un certain nombre d’obligations légales protectrices de son activité et protectrices des consommateurs.

Une fois le site créé, il est nécessaire de notamment :

  • Déposer le nom de domaine sous forme de marque (titre de propriété industrielle qui donne une protection de 10 ans renouvelable), manuscrite ou semi figurative, à savoir accompagnée d’un logo qui figurera sur le site et permet la reconnaissance visuelle de l’entreprise,
  • Si la création du site correspond à une création d’entreprise, il est nécessaire de la faire enregistrer au RCS
  • Faire une déclaration CNIL dans l’éventualité du traitement de données personnelles des clients et indiquer le numéro d’enregistrement attribué sur le site ainsi que l’adresse de contact du service adéquat. (nom, prénom, adresse e-mail, numéro de téléphone, date de naissance…)

Sur le site doivent figurer un certain nombre de mentions légales.

Les Conditions Générales de Vente

Les conditions de vente proprement dites

(conditions relatives au transfert de propriété, à la logistique…)

Les conditions de règlement :

  • Délais de paiement
  • Pénalités de retard
  • Conditions d’escompte/ d’acompte
  • Le délai et les conditions de retour de la marchandise
  • Les modalités de remboursement

Le délai de rétractation  (7 jours – impératif)

Le délai de livraison

Les barèmes de prix, les rabais et ristournes

  • le barème des prix unitaires, Tous les barèmes de prix différenciés doivent être mentionnés
  • les réductions de prix

Les CGV doivent indiquer ce que le fournisseur est prêt à consentir (remises quantitatives, qualitatives, promotionnelles, différées)

Les autres clauses

  • Les commandes
  • La clause attributive de compétence et la loi applicable
  • La force majeure
  • La clause de réserve de propriété
  • Le défaut de conformité de la marchandise

Communication des conditions générales de vente

Conditions de forme et de fond. Généralement, les Conditions Générales de Vente figurent sur des documents :

  • contractuels (bons de commande, contrats …) ;
  • pré contractuels (documents publicitaires …) ;
  • annexes (écriteaux, affiches apposées sur les lieux de vente…).

La Notice légale

Les personnes morales doivent y faire figurer :

  • leur dénomination ou raison sociale et leur siège social
  • leur numéro de téléphone
  • le cas échéant leur numéro d’inscription au RCS ou au répertoire des métiers, leur capital social, l’adresse de leur siège social
  • le nom du directeur ou du codirecteur de la publication et le cas échéant, celui du responsable de la rédaction
  • le nom, la dénomination ou la raison sociale et l’adresse et le numéro de téléphone de l’hébergeur ou de l’éditeur d’un blog

Les personnes physiques quant à elle, doivent faire figurer :

  • leur nom
  • prénoms
  • domicile et numéro de téléphone
  • le cas échéant leur numéro d’inscription au RCS ou au répertoire des métiers
  • le nom, la dénomination ou la raison sociale et l’adresse et le numéro du téléphone de l’hébergeur ou de l’éditeur d’un blog.

Procédure de validation de conclusion du contrat

  • récapitulatif de la commande avant toute validation,
  • envoi d’un accusé réception ( par voie électronique) indiquant à l’acheteur que sa commande a bien été prise en compte et validée,
  • conservation par le vendeur d’une trace écrite de la commande

Toutefois, il existe des régimes spécifiques concernant des contrats de services électroniques (Loi Châtel 2008)

Les publicités par mail

  • Les messages publicitaires doivent être clairement identifiés comme étant des publicités.
  • La personne morale ou physique ayant émis le message doit être clairement identifiable.
  • La prospection directe, sans accord préalable du destinataire est INTERDITE.

« La prospection commerciale est possible si le destinataire de l’email y a préalablement consenti. Il s’agit du régime de l’opt-in. »

Posté par Philippe pour le compte de Mt Garance Mathias, avocate à la cour.

écrit par Philippe Humeau \\ tags: ,

fév 24

Il est intéressant de structurer les posts de ce Blog.

Bien que tout débutant dans ce domaine, je découvre les attentes de ceux qui lisent ces lignes que j’écris pour partager un peu de savoir et quelques expériences. Mais si vous lisez ces lignes, c’est pour obtenir du vrai, du lourd, du Magento qui décolle, alors trêve de rêverie et allons vers du concret :

Au menu du Wiki :
Après l’article sur le dimensionnement des serveurs de bases de données, bientôt celui sur le dimensionnement des serveurs Web frontaux ! Comment évaluer les besoins, quels sont les points de repère, que mettre en face ?

Au menu du Blog :
Il va falloir poster les optimisations, les réglages et tout ce que vous attendez de blog. Gilles a ouvert le feu avec son article sur APC, hier j’ai posté un petit coup de sécurité pour vous faire patienter, mais la suite arrive !

Au fil de l’eau, et à la vitesse ou je pourrais le faire, on va voir les 5 étages de la fusée « performance » :

  1. Le code, le template
  2. L’environnement réseau : Bande passante, Peering, DNS…
  3. Le Reverse Proxy / Load Balancer (Squid, Memcached et autres menus plaisirs de la vie)
  4. Les serveurs Web Frontaux (APC Code cache, cache Zend/Magento en Tmpfs, réglages Apache, mod_fastcgi, …)
  5. Les serveurs de Bases de donnée (réglages et architecture de Mysql)

(Comme Loïs Mac Master Bujold, j’écrirais peut être tout cela dans le désordre)

Lire la suite »

écrit par Philippe Humeau \\ tags:

fév 23

C’est vrai, on ne se refait pas, alors les déformations professionnelles reprennent le dessus…

La confiance est le liquide amniotique de l’économie. Que ce soit dans le monde bancaire ou pour le E-commerce, cela reste vrai. La sécurité d’un site est donc un problème central. Le client considérera comme normal, comme le minimum syndical, que votre site soit sécurisé.

Si un jour cette confiance que votre client vous porte est prise en défaut, les conséquences sont dramatiques. Il sera quasiment impossible de remonter la pente si une mésaventure de sécurité arrive, les clients n’oseront plus payer en ligne sur le site concerné. Monster a éprouvé récemment de gros tracas, tout comme Myspace avec le ver « Sam is my hero » ou Facebook avec ses worm XSS. Nos tests d’intrusion et nos tests de sécurité externe nous montre tous les jours des failles en pagaille, alors voici un petit mot pour, au moins, éviter le pire et le plus trivial.

Sécurité de Zend et de PHP

Premièrement, Magento repose sur Zend et Zend est solide. PHP est pas mal troué, mais le framework Zend en lui même est plutôt clean. Donc si un buffer overflow (ou un dérivé du genre) existe dans Php, c’est à votre hébergeur de gérer ca coté serveur, avec par exemple GRsec+Pax. La plupart des failles dans PHP ne sont pas révélées par les hackers, tout le monde en garde une dans son coin, mais un bon patch GRsec fera correctement le boulot et évitera le pire.

Zend de son coté est une réelle avancée. Pour une fois, par défaut, un Framework propose une sécurité bien faite des contrôles des entrées utilisateurs. Car la majeure partie des failles provient de ce point. Les XSS (Cross Site Scripting) et une partie des SQL injection, sont possibles uniquement parce que le filtrage a été insuffisant sur un formulaire ou une barre de  recherche par exemple.

Si l’on ne s’éloigne pas trop du sujet Magento, le bilan est bon. Zend le protège, Varien n’a pas fait d’erreur de fond, tout va bien. Le facteur qui va mettre en risque le site c’est donc le développement « maison ». Un formulaire créé et contrôlé sans passer par Zend, c’est potentiellement la porte ouverte à nos amis XSS/SQLinject.

Filtrer les « user input »

Je code donc je porte une responsabilité de sécurité chapitre 1 !
Si vous développez en dehors des fonctions sécurisées de Zend, peu importe la raison, d’une manière générale : « Le moins, le mieux ». Limitez les jeux de caractères utilisés/acceptés au stricte nécessaire. Créez en plusieurs au besoin pour avoir de la granularité.

Si possible limitez à la regular expression suivante : [a-zA-Z0-9]
Sinon, si vous devez élargir un peu la regular expression suivante : [a-zA-Z0-9#[email protected]éèëêùàâôöïî],
on est encore dans l’acceptable,
par contre, à bannir au maximum : [-,',+,",&,$,%,\,<,>,|,\\,\,(,),\0,\n]
(je les ai séparé  par des virgules pour améliorer la lisibilité mais selon l’interpréteur de Regexp vous aurez peut être à enlever ces virgules et ce n’est pas \o mais bien \zéro).

Attention également aux encoding, à forcer sur toutes les pages, pour éviter de se faire envoyer des encodages exotiques qui contourneraient les protections. L’UTF8 est bon choix de part son coté universel et récent.

Owasp fournit une librairie pour aider les développeurs à éviter les XSS

Échappement des chaines

Utilisez Escape/unescape afin de nettoyer les donnés traitées

Pour PHP5, les fonctions htmlentities et htmlspecialchars sont vos amies

Upload de fichiers

Un bon gag bien célèbre que l’on croise souvent aussi : l’upload de fichier. Que du bonheur ! Si l’on ne contrôle pas le type de fichier reçu, on s’expose à de très graves déconvenues… Je vous garantie qu’un C99shell ou une backdoor PHP du genre, c’est la compromission complète du serveur en quelques heures maximum. Alors à réception d’un fichier, vérifier son type, appelez l’antivirus dessus et contrôlez son extension, cela peut éviter bien des malheurs car se faire envoyer une backdoor au lieu d’une photo ou d’un fichier HTML, c’est un classique qui fait toujours aussi mal.

Reverse Proxy & Firewall

Un Reverse proxy peut aussi aider. En dehors de sa « classique » fonction de cache, il peut aussi pour permettre de « nettoyer » les  URLs qui sont appelées et éventuellement, couplé à des flex rules ou un IDS, il peut bannir en temps réel sur votre Firewall les petits rigolos qui veulent forger des URL. (REJECT quand on est gentil, DROP si on l’est un peu moins et TARPIT si on est très fâché)

En général, un service Web doit exposer un port 80 et un 443. Le HTTP et le HTTPS sont publiques puisque tout le monde doit pouvoir s’y connecter, par contre, le service SSH, le FTP ou d’autres n’ont pas à être visibles depuis le monde entier. Il faut donc filtrer ces accès et les protéger. Un Firewall en tête de toute votre infrastrucutre fera bien l’affaire, il est aussi possible de Firewaller par machine puisque Netfilter est intégrer dans presque tous les noyaux Linux.

Protégez, au minimum votre port ssh, c’est un minimum. Si vous ne savez pas faire, juste pour le SSH, mettez dans un script (cat > ./ssh_filter.sh, à la fin CTRL+D puis chmod 755 ./ssh_filter.sh) :

#/bin/bash
/sbin/iptables -I INPUT -s xxx.xxx.xxx.xxx -p tcp –dport 22 -j ACCEPT
/sbin/iptables -I INPUT -p tcp –dport 22 -j DROP

Attention, il ne se lancera pas tout seul avec la machine si elle reboot, allez voir le howto (voir plus bas) si vous voulez des détails.

Remplacer xxx.xxx.xxx.xxx par l’IP depuis laquelle vous administrez le serveur. Oui c’est de la survie ultra minimale, mais un cour de firewalling c’est long à faire. Si vous voulez en savoir plus, j’ai rédigé, (il y a longtemps) un petit howto to simple ici.

Droits des fichiers, droits des démons/services

Un des soucis fréquemment rencontrer, c’est que dans le doute, au moindre message d’erreur, la personne qui installe un site, un blog, un système de E-commerce ou autre Weberies met un bon vieux 777 sur le répertoire et les fichiers. Dans le doute aussi, histoire de pas être embété, mes testeurs ont déjà aussi vu des Apache en root (les workers). Tout cela est mal, très mal même… Donc un bon fichier Web a des droits adaptés : 755 au plus large mais JAMAIS de 777 en production ! N’oubliez pas que tout fichier contenant un mot de passe de connexion à un base de données (config.php par exemple) ne doit pas être lisible de tous (pas 755 donc).

De même les démons, apache en premier lieu (mais aussi potentiellement le serveur FTP et Mysql), doivent être lancé sous un nom d’utilisateur non privilégié, sous débian normalement Apache se lance en www-data comme utilisateur et www-data comme groupe.

Protection Kernel contre les overflows et cage/chroot

Le noyau de votre Linux, par défaut sur la majorité des distributions, est compilé avec le support des modules. Ce n’est pas idéal puisque mettre une backdoor à un noyau modulaire est très simple une fois que l’on est root et c’est assez indétectable. La compilation du noyau en statique est donc préférable et il faut y ajouter le patch GRsec/Pax. Ce patch est certes quelque peu joyeu à paramétrer quand on ne le connait pas, mais il est bourré de qualités ! En premier lieu il rend la pile non exécutable, ce qui complique singulièrement les exploitations par overflows.  Ensuite il améliore beaucoup d’autres points, renforcement des chroots, des logs, cacher les processus noyau, amélioration des pools d’entropie.

Les cages (ou Chroot) sont également un bon moyen de défense contre les overflows, d’autant plus si elles sont couplées à GRsec/PAX pour éviter que l’intru puisse sortir de la cage du démon. Les cages sont des sous répertoires, comprenant tout ce qu’il est nécessaire d’avoir (et rien de plus) pour que le démon/service concerné, puisse s’exécuter. Ainsi, il n’a aucune visibilité sur le reste du système si jamais il se retrouvait compromis par un overflow. Il existe des moyens de contourner ces restrictions mais Pax résout le problème.

Webservices

Je code donc je porte une responsabilité de sécurité chapitre 2 ! Un webservice, par principe, expose une grande partie de son fonctionnement à travers un WSDL (prononcez « wisdel ») qui décrit les types et fonctions associés. Grace à cette mine d’information, par essence publique, il est facile de consulter un webservice que l’on pourrait atteindre et de lui faire donner des informations confidentielles. Afin d’éviter ce type de désagrément, il faut mettre le Webservice à l’abri de requêtes frontales depuis Internet (dans un sous réseau), voir cacher le Wdsl quand cela est possible.

Backoffice, password et bruteforce

Une fois que vous avez pensé à tout, que reste t’il à faire ? Mettre un mot de passe décent sur le backoffice évidemment mais ça, vous l’aviez déjà fait. On évite de se faire bruteforcer au cas ou en mettant un .htaccess, éventuellement qui ne vous embetera pas depuis vos IP à vous, mais vous protégera des petits rigolos qui voudraient bruteforcer votre admin ou encore d’une éventuelle faille sur les URL dans l’admin. Un simple .htaccess contenant :

AuthUserFile /www/wikigento/htpass (bien sur ce n’est pas le bon chemin ;) )
AuthName « Wikigento »
AuthType BasicOrder allow,deny
allow from xxx.xxx.xxx.xxxx
allow from yyy.yyy.yyy.yyy
Require valid-user
Satisfy any

vous permettra de vous connecter depuis les IP xxx.xxx.xxx.xxx ou yyy.yyy.yyy.yyy sans demande de login/pass et depuis n’importe quelle IP en renseignant correctement une demande de login/pass.

Autres principes de sécurité pour vos Webdev

N’oubliez pas, par exemple, que la sécurité de vos applications doit se faire coté serveur et pas coté client. Le client, par principe de sécurité, est à considérer comme compromis. Il est possible assez facilement de jouer avec le Javascript envoyé à un browser avec de addons comme Firebug. Ne faites donc confiance qu’à ce que VOUS maitrisez, le serveur. Gare notamment au modèle de sécurité qui repose sur Javascript ou Ajax, ce sont des technologies « client side » et donc par définition elles ne peuvent en aucun cas garantir une transaction ou l’intégrité d’une procédure.

écrit par Philippe Humeau \\ tags:

fév 20

Bonjour à toutes & à tous,

Voici venu le temps de la collaboration !

Afin de fournir à Wikigento une ligne éditoriale de qualité et des compétences techniques toujours renouvellées, une équipe me rejoint pour poster de manière ponctuelle des articles.

Tout le monde ne pourra pas publier de manière continue, mais voici la liste des contributeurs potentiels. (Quand au Wiki, c’est ouvert, tout le monde peut y participer !)

  • Philippe Humeau (NBS System), je continuerai à publier les performances et l’optimisation de Magento d’un point de vue plus système & réseau
  • Fabrice  « Kalliser », contribuera également sur divers aspects de l’optimisation SR
  • Julien Ducamp apportera des points concernant plus le développement
  • Kenji & Frédéric (Faak) posteront ponctuellement, plus sur la partie SEO
  • Patrice, Frédéric, Benoit (Smile) s’intéressent au groupe « compilation » ou « advanced cache »
  • Gilles (Téléshopping) nous parlera de temps à autres d’APC et des settings Mysql
  • Oliver (AFG), s’intéresse particulièrement aux Templates et à leurs optimisations
  • François Ziserman nous postera peut être un billet de temps à autres sur le E-commerce et le fonctionnel
  • Anthony & Gabriel (Fragento),  passeront peut être nous poster un ou deux billets à l’occasion, ne serait-ce que pour nous informés de l’actualité du site Fragento
  • Une invitée surprise, avocate, nous postera prochainement un billet sur les CGV des E-marchands, la « todoliste » pour se lancer en toute sécurité

Si vous souhaitez rejoindre la liste des auteurs pour nous faire partager une idée, un point de vue ou une astuce, n’hésitez pas à me contacter.

écrit par Philippe Humeau \\ tags: