Communauté Magento francophone

Bon j’en ai un peu marre du sujet « sécurité Magento » pour le moment. On en a beaucoup parlé, on a apporté des idées et des solutions mais j’aimerai repartir sur autre chose. C’est vrai quoi, j’ai fait 10 ans de test d’intrusion, pour me changer les idées, je pars sur du web commerce, un petit retour au système & réseau, bref on s’aère le neurone et là, hop, XSS, CSRF etc…

Donc, aujourd’hui : les inclusions de contenus tiers !

Un petit schéma pour aider à comprendre (quoique… J’ai jamais été très fort en dessin. J’ai été en classe de dessin parce que la plus belle nana du collège faisait dessin, pas réellement pour mon talent en fait). Bref, je m’égare, donc ci-dessous, un site standard, au milieu. Au dessus un bandeau de pub qui vient d’une régie publicitaire, à droite un flux RSS et en bas, c’est de l’invisible, ce sont des inclusions dans le code source des pages.

Des inclusions, pour faire quoi ?

Eh bien rendre le site plus dynamique, ajouter un widget ou un flux rss, récupérer du contenu éditorial écrit par d’autre, collecter des statistiques, avoir un menu déroulant tout beau, que sais-je encore. Les inclusions de contenus tiers, c’est tout ce qui ne vient pas de votre serveur local, tout ce qui est appelé par des GET depuis d’autres serveurs. des moteurs de recherche de prix en Iframe, un bout de javascript qui fait une merveille ou une autre, un logo qui témoigne  de votre allégence éternelle à la horde, bref les exemple ne manquent pas.

Les plus classiques :

1. Les bons vieux tags de statistiques et de télémétrie : Google analytics, Xiti etc…
2. Le RSS qui provient d’un fournisseur de produits ou de nouvelles
3. Les bouts de codes javascript copier/coller qui font un rollover jolie sur le menu ou des Jqueries toutes précodées
4. Des CSS ou skins contenants des images venant d’ailleurs
5. Les bandeaux publicitaires
6. Les exports des données/commandes/info vers un tiers

En quoi cela peut-il ralentir mon site ?

Eh bien tout dépend du moment où ca se charge et de ce qui bloque ou ralentit.

Imaginons qu’un développeur ait mis dans les includes chargés en en-tête de page, le tag analytics. Imaginons ensuite que Google ne réponde plus (c’est rare) ou qu’il soit interdit d’y aller depuis le poste qui charge la page (je l’ai déjà vu, le proxy bloquait les IP google). Le résultat c’est que le code se chargeant au tout début de la page, la page ne charge plus. Elle va attendre le timeout par défaut (30 secondes) puis va finir par charger le reste…

En fin de page, c’est parfois moins génant, l’internaute a sa page, fait sa vie, le browser reste en cour de connexion mais au moins tout ce qui est déjà chargé est potentiellement fonctionnel.

Si on prend le cas d’un menu JS copié/collé, l’auteur peut avoir envie de savoir qui l’utilise et de se renvoyer un petit « ping ». A chaque fois que son menu est chargé par exemple, il fait un GET d’une page sur son site. Si son site est coupé, le menu ne charge pas, vous dépendez d’un tiers.

Votre centrale de publicité ou le fournisseur de votre skin peut aussi se mettre à ramer. En plus de votre chargement, vous ajouter sa latence de traitement à celle de votre page.

Ajax résoud partiellement le problème en effectuant ses requêtes en background, dans la machine virtuelle javascript du navigateur. Si un thread est planté, c’est moins grave, ent tout cas non bloquant visuellement.

Enfin, il ne faut pas oublier qu’appeler un contenu tiers, c’est ajouter la latence de la connexion entre votre client et vous à celle qui sépare votre client de toutes les sources tiers qui sont inclues. Par exemple, si ntre client [C] se connecte au serveur [S] qui sert une page où se trouve : un bout de javascript [J] qui fait un appel à l’extérieur, une régie pub [P] et un flux rss [R], ca nous donne :

[C] –> [S]        (latence entre le client et le serveur)
[S] –>[C]         (réponse du serveur au client, eh oui, le paquet TCP il repart pas avec ses petits pieds)
[C] —> [J]      (latence du client à la source de Javascript)
[J] –> [C]       (les petits pieds tout ca tout ca)
[C] —–> [P]  (latence du client à la régie pub)
[P] –> [C]       (les petits pieds…)
[C] -> [R]         (latence du client à la source RSS)
[R] –> [C]       (…)

Bonne nouvelles, les requêtes étant séquentielles, votre client encaisse toutes les latences et les additionne !
Votre latence qui était –> + –> (allez / retour client <—-> serveur) devient :
–>x2  +     —>x2   +   —–>x2 + ->x2
(serveur) (javascript)(régie pub)(rss)
Soit en équivalent « petits tirets » : —- devient ———————-
Si le tiret vaut 10 ms, on passe de 40 ms à 220 ms…
Le tout sans compter le chargement des contenus en eux même (le menu, les flux xml du rss, la JPEG de la banière)

Les navigateurs ne sont pas tous idiots et souvent ils demandent tout en même temps et traitent à l’arriver. Mais si c’est un point bloquant qui est en attente (le JS du menu par exemple) ca ne change rien, le client rame. Il faut donc choisir judicieusement les prestataires de ces contenus tiers (rapidité, disponibilité) et vérifier le comportement de son site s’il est isolé de ses « fournisseurs ». Pour cela, sous Linux rien de plus simple :

iptables -I OUTPUT -j DROP
wget http://localhost/

On interdit toute connexion à l’extérieur (iptables -I OUTPUT -j DROP), puis on faire une requête sur la homepage du site. Si ca charge rapidement, on est plutôt bien partit. Si ca bloque, c’est que l’on a une relation de dépendance ! Ca ne teste que la home mais vous pouvez le tester sur une sous page, de même si vous avez un virtualhost vous aurez peut être à remplacer « localhost » par son nom. Le DROP permet d’avoir un comportement comme si l’hote distant était indisponible. Si vous mettez DENY ou REJECT à la place, votre site aura une réponse « non » instantanée et ca ne sera pas réaliste.

Enfin, si votre site doit poster l’information qu’il a collecté, une vente par exemple et l’acheminer à votre système  SAP, à votre système de Stats, à votre système de livraison, si ce fameux système rame, ca va ramer aussi. Bon si c’est la livraison, c’est après le checkout donc le client a tendance à ne pas trop zapper votre site après avoir mis sa CB, mais avant…

Ok, ca peut faire ramer, mais est-ce potentiellement dangereux ?

Oui, bon je vous vois d’ici me dire : « Ah-Ah ! Ca va reparler de sécurité »

Pas du tout, enfin un peu. Mais c’est comme on dit à la blackhat du « Digital Self Defense », rien à voir avec la sécurité
(Ah bah ça ma p’tite dame, la mauvaise foi, c’est un métier !)

Bon, c’est risqué ou pas alors ?
Bien sûr que c’est risqué, vous croyiez que j’avais mis le titre juste pour poser un smiley ?

Si votre fournisseurs de RSS met un bon gros bout de Javascript dans son flux ? Vous l’affichez ? Votre moulinette d’affichage est assez intelligente pour éviter d’afficher du code ? Sûr ? Et si ca se trouve, votre fournisseur de contenu RSS a une faille XSS qui permet à n’importe qui de poster du JS… Si si ca arrive les XSS

Et votre régie publicitaire ? Elle est sérieuse ? Ahhhhh bon. Donc elle lit le code des Flashs postés pour éviter les attaques par anti DNS pinning j’imagine et puis elle ne rame jamais. C’est comme Gmail, ca plante jamais ça monsieur !

Et le bout de Javascript copié/collé pour faire un beau menu qui déroule, en glissant sur un rollover de folie avec des animations subliminales ? Il a été relu ? Il ne fait aucun get/post nul part ailleurs ?

Comment éviter cela ?

Eh bien en premier lieu vérifier le taux d’autonomie / dépendance de votre site Web avec le test iptables -P OUTPUT DROP.

Si ca passe, vous êtes assez tranquille sur les ralentissements sinon il regarder l’appel qui fait ramer. Mesurer les temps de réponse de chacune de vos inclusions pour savoir si ils sont tous globalement bon. Ca dépend aussi du budget que vous avez mis dans votre développement. A 2 000 € le site, il y aura de la récupération de code, c’est fatal. A 15 000 ou plus, si un code javascript est copié/collé c’est clairement un peu abusé.

Sur la sécurité c’est une autre histoire. Prenez des prestataires connus, de confiances, aux performances régulières et vérifiables. Pour tout ce qui concerne le contenu qui sera directement affiché dans la page sans vérification (RSS par exemple) redoublez de prudence. Votre site affichera ce qu’on lui envoi, votre internaute lira ce que le site lui envoie.

Si le site qui est la source d’information est corompu, votre site est compromis, votre internautes sont compromis. C’est invisible et imparable, avec une iframe « invisible » (d’un pixel) qui contiendra le javascript malieux, l’utilisateur sera à la merci de l’assaillant. N’oubliez pas que Flash & Javascript disposent de fonctionnalités très puissantes permettant le pire comme le meilleur !

écrit par Philippe Humeau \\ tags: analytics, import tiers, rss