Introduction Jeedom 4.2 : la sécurité

Cet article sert à préparer l’arrivée de Jeedom 4.2, toujours en beta à l’heure où j’écris. Hormis l’énorme changelog que vous pouvez trouver ici (au passage un grand grand merci @Kiboost, sans qui il n’y aurait sûrement pas la moitié des changements que vous voyez !!!), il y a une modification de taille : la sécurité.

Pour ceux qui suivent l’actualité informatique, vous n’êtes pas sans savoir que le nombre d’attaques grandit de jour en jour. A tel point que la sécurité est devenue un des enjeux majeurs de la plupart des acteurs informatiques.

Jeedom ne pouvait pas ne rien faire, la 4.2 annonce donc des changements majeurs là-dessus qui peuvent avoir un impact sur le fonctionnement de celui-ci.

Clef API

Une des premières modifications est au niveau de l’API et des clefs API surtout. Avant avec la clef du core vous pouviez appeler des fonctions API d’un plugin, ce n’est désormais plus possible. Il faut maintenant obligatoirement utiliser la clef API du plugin. De plus, il faut préciser dans l’url le plugin en question. Exemple avant vous faisiez type=virtual dans le plugin virtuel pour appeler son API avec la clef du core ou du plugin. Maintenant il faudra faire plugin=virtual&type=event avec absolument la clef API du plugin virtuel.

Autre modification qui aura un impact minime mais que je préfère indiquer : la taille des nouvelles clef API passe de 32 caractères à 64 caractères.

Pourquoi ?

Cette modification est là pour que les services tierces n’ait jamais la clef du core de Jeedom, qui donne accès à des fonctions critiques de celui-ci. Le services tierces ayant la clef API uniquement du plugin ne peut pas faire d’action critique et ne pourra au pire que corrompre le plugin en question.

Et si je veux pas ?

Là-dessus aucun recours possible, il faudra absolument mettre à jour toutes vos urls d’appels API. Vous pouvez évidemment toujours décider de ne pas mettre à jour mais vous allez perdre l’accès à de nouveaux plugins et surtout vous n’aurez pas de correction en cas de bug ou autre. La sécurité c’est trop important !

Accès aux fichiers

Sûrement la modification qui vous posera le plus de soucis mais elle était nécessaire. Avant au niveau du serveur web, on interdisait l’accès à certains types de fichiers (basé sur l’extension). Maintenant on autorise l’accès à certains types de fichiers (et donc on interdit l’accès à tous les autres). De plus l’accès à certains types de fichiers dépend maintenant du répertoire dans lequel il se trouve. Exemple avant il était par exemple possible d’avoir accès en direct à une image dans le répertoire css, ce n’est plus possible maintenant.

Je me doute que tout le monde ne comprend pas forcément les conséquences de cette modification,. Nous ne pouvons malheureusement pas vous faire une liste des conséquences car cela dépend grandement des plugins. On a vu dans certains cas des plugins utilisant des widgets bien spécifiques perdre certaines images. Normalement ce genre de cas a bien sûr été corrigé en amont soit par nous (en étant plus tolérant sur les types de fichiers autorisés) soit par les développeurs des plugins.

Pourquoi ?

Cela permet de limiter la surface d’attaque possible et donc les failles de sécurité exploitables par un attaquant mal intentionné. On est parfaitement conscient de l’impact que cela aura sur votre Jeedom (même si on a tout fait pour le minimiser au maximum) mais on reste convaincu qu’il vaut mieux des petits désagréments liés à cette modification plutôt que quelqu’un qui ait accès à vos caméras par exemple…

Et si je veux pas ?

Il y aura une parade possible, volontairement complexe, si vous créez un fichier .htaccess_custom à la racine de Jeedom puis mettez le core à jour, cela supprimera le fichier .htaccess de base et utilisera votre custom. Attention en faisant cela vous pouvez ouvrir votre Jeedom à de potentiels attaquants, vous pouvez aussi en cas d’erreur complètement planter votre Jeedom (dans ce cas le support Jeedom pourra refuser votre demande d’aide).

Apache security

Autre sécurité sur Apache, un peu plus complexe, c’est les droits le javascript/html. C’est quelque chose d’assez récent sur les navigateurs, cela permet de dire ce qui est autorisé ou non en javascript/html. Dans les exemples simple, il n’est plus possible de lancer une vidéo en autoplay si celle-ci ne vient pas de Jeedom, il n’est plus possible d’intégrer des x-frame par exemple. Ca ne devrait pas impacter la plupart d’entre vous

Pourquoi ?

Pour les x-frame (page html intégré dans Jeedom) c’est pour vous protéger si le site tierce que vous intégrez est corrompu. En effet, si celui-ci est sous la merci d’une attaque, rien n’empêche l’attaquant de glisser du code javascript dedans qui récupère les mots de passe stockés dans Jeedom par exemple, ou même récupère carrément l’accès à celui-ci.

Et si je veux pas ?

Déjà pour vous rassurer dans un premier temps, cette modification ne s’appliquera que sur les nouvelles installations (attention elle est persistante à une restauration de Jeedom). De plus, il sera possible de l’activer ou non depuis Jeedom en allant dans la configuration de celui-ci, puis onglet OS/DB et ouvrir l’administration Système. Là vous avez dans la liste en bas à gauche deux lignes : « Apache non sécurisé » pour désactiver cette nouvelle sécurité (non recommandé bien sûr) et une une ligne « Apache sécurisé » pour l’activer. Attention après chaque modification il faut absolument redémarrer Jeedom.

Conclusion

Voilà pour le volet sécurité de la 4.2 et surtout pour que vous anticipiez votre mise à jour. On s’excuse d’avance auprès de tous ceux qui vont être gêné par ces modifications. Nous avons essayé pour la plupart des cas de prévoir une solution de contournement (même si on vous encourage à ne surtout pas utiliser !).

Vous aimerez aussi...