Bonjour, Un projet de migration m’amène dans une situation inédite pour moi : Je récupère une application web sur mes serveurs. Le problème : l'application de fonctionne avec PHP 5.2 (je n'ai même pas voulu essayer en 5.3). L'ancien hébergeur (et développeur de l'application - y compris dans le futur), me dit que le pré-requis est en PHP 4.4. Effectivement, après bidouillage sur un serveur de test, l'application tourne effectivement sur PHP4.
Mais voilà, PHP4, le support est arrêté depuis 2008. Et d'après les sites de sécu, c'est 34 failles de sécurité non patchées et qui ne le seront jamais. Autant dire que les hackers vont se faire plaisir ...
A priori, pas de trace de l'obligation écrite de la boite de dev de suivre les versions du langage.
D'où ma question : le client est-il en mesure de forcer (par négo, voir par avocat) à rendre son application compatible PHP5 ? Histoire de savoir qui va devoir payer le dev pour upgrader ce soft.
Est-ce que certains d'entre vous ont déjà eu un cas de figure similaire et comment ça s'est terminé ?
Merci, Julien
P.S. : pour la blague, le prestataire actuel ne semble avoir aucun remord à faire tourner cette appli sur un serveur mutu avec PHP 4.4.8 ...
Le 27 mai 2011 16:25, Julien Escario escario@azylog.net a écrit :
D'où ma question : le client est-il en mesure de forcer (par négo, voir par avocat) à rendre son application compatible PHP5 ? Histoire de savoir qui va devoir payer le dev pour upgrader ce soft.
S'il y a un contrat de maintenance en condition opérationnelle ou tierce maintenance applicative, et que les specs de ce contrat encadrent les obligations de correction de failles connues, alors ça se plaide.
Sinon, une fois le soft livré et sans garantie contractuelle de respect d'une norme en matière de sécurité, alors tu ne peux rien obtenir.
Par contre, le fait que des failles connues existent dans l’interpréteur ne suffit pas, il faut que ces failles soient applicables au fonctionnement de l'application et fassent que l'application ne respecte plus son cahier des charges.
Deux bémols : - Si l'application est recettée conforme, chercher le vice caché n'est pas simple, surtout si la faille existait à l'époque de la recette. - Si la mise en conformité aux spécifications est possible sans modification du code de l'appli (reverse proxy filtrant, configuration spécifique de l'interpréteur, ...) alors le prestataire est libre de la méthode à employer tant qu'il en assume les coûts et que c'est conforme aux spécifications contractuelles
En clair, quel que soit le cas de figure, il va falloir tout auditer, tout démontrer, et ça va couter un paquet de blé (et de temps de dev) car la charge de preuve t'incombe. Bref, autant ne pas perdre de temps, et à moins que l'appli ne soit monstrueusement complexe, profites en pour commencer à en migrer des bouts vers une plateforme (et langage) moins impossible à maintenir que le PHP, ce sera une meilleure utilisation du budget...
Est-ce que certains d'entre vous ont déjà eu un cas de figure similaire et comment ça s'est terminé ?
En tant que client : je me suis toujours fait baiser par le presta sauf une fois ou j'avais rédigé les annexes contractuelles moi même. En tant que presta : j'ai toujours baisé les clients. Sans exception. Mais ils l'ont cherché, à imposer du PHP ou autre plate-forme pourrie...
En aucun cas on a eu à aller en justice, donc je n'ai pas épluché toute la jurisprudence à ce sujet.
P.S. : pour la blague, le prestataire actuel ne semble avoir aucun remord à faire tourner cette appli sur un serveur mutu avec PHP 4.4.8 ...
Ben s'il n'a aucun engagement imposant le contraire, pourquoi changerait il ?
Le Fri, May 27, 2011 at 04:25:16PM +0200, Julien Escario [escario@azylog.net] a écrit: [...]
A priori, pas de trace de l'obligation écrite de la boite de dev de suivre les versions du langage.
D'où ma question : le client est-il en mesure de forcer (par négo, voir par avocat) à rendre son application compatible PHP5 ? Histoire de savoir qui va devoir payer le dev pour upgrader ce soft.
Oh bah c'est ton client qui va payer le dev, d'une façon ou d'une autre. Soit qu'il a encore le presta en question à travailler sur le site, il fait évoluer sa demande sur « compatible PHP 5 actuel ». Soit qu'il prend quelqu'un d'autre pour le faire.
Est-ce que certains d'entre vous ont déjà eu un cas de figure similaire et comment ça s'est terminé ?
[...]
P.S. : pour la blague, le prestataire actuel ne semble avoir aucun remord à faire tourner cette appli sur un serveur mutu avec PHP 4.4.8 ...
Tu émets des réserves sur ce à quoi tu peux t'engager, en tant qu'hébergeur, en terme de sécurité. Tu peux aussi lui vendre (toi ou un presta) du « firewall applicatif » (genre mod_security, ...) à mettre devant, si vraiment il veut/peut pas le faire évoluer, mais quand meme réduire les risques.
Le 27/05/2011 16:51, Dominique Rousseau a écrit :
Oh bah c'est ton client qui va payer le dev, d'une façon ou d'une autre. Soit qu'il a encore le presta en question à travailler sur le site, il fait évoluer sa demande sur « compatible PHP 5 actuel ». Soit qu'il prend quelqu'un d'autre pour le faire.
L'appli est encore maintenue par le développeur 'historique'. Contrat type tierce maintenance applicative. Donc pour toi, ils n'ont aucune obligation à faire tourner ça sur une plateforme respectant l'état de l'art, ne serait-ce qu'en matière de sécurité ? Pour moi, payer une maintenance annuelle, ça implique quand même d'être dans les clous question version de PHP 'moderne' mais je suis un grand rêveur.
Le contrat parle également de l'obligation de la part du prestataire de protéger avec un firewall logiciel. A mon avis, ce n'est pas le cas mais est-ce que c'est prouvable avec du nmap ? Bah, après réflexion, ils trouveront toujours un moyen de trouver une ACL quelconque et de dire que c'est fait.
Tu émets des réserves sur ce à quoi tu peux t'engager, en tant qu'hébergeur, en terme de sécurité.
C'est fait ça, parapluie ouvert ;-)
Tu peux aussi lui vendre (toi ou un presta) du « firewall applicatif » (genre mod_security, ...) à mettre devant, si vraiment il veut/peut pas le faire évoluer, mais quand meme réduire les risques.
Mouais, mais compte tenu du nombre de failles possibles (pour la plupart des DoS), aucune protection ne sera garantie en terme d'efficacité. Et on tombe vraiment dans la rustine là, je n'aime vraiment pas.
Merci, Julien
Le Fri, May 27, 2011 at 05:02:06PM +0200, Julien Escario [escario@azylog.net] a écrit:
Le 27/05/2011 16:51, Dominique Rousseau a écrit :
Oh bah c'est ton client qui va payer le dev, d'une façon ou d'une autre. Soit qu'il a encore le presta en question à travailler sur le site, il fait évoluer sa demande sur « compatible PHP 5 actuel ». Soit qu'il prend quelqu'un d'autre pour le faire.
L'appli est encore maintenue par le développeur 'historique'. Contrat type tierce maintenance applicative. Donc pour toi, ils n'ont aucune obligation à faire tourner ça sur une plateforme respectant l'état de l'art, ne serait-ce qu'en matière de sécurité ? Pour moi, payer une maintenance annuelle, ça implique quand même d'être dans les clous question version de PHP 'moderne' mais je suis un grand rêveur.
La vérité est dans le contrat <point> :-)
[...]
Tu peux aussi lui vendre (toi ou un presta) du « firewall applicatif » (genre mod_security, ...) à mettre devant, si vraiment il veut/peut pas le faire évoluer, mais quand meme réduire les risques.
Mouais, mais compte tenu du nombre de failles possibles (pour la plupart des DoS), aucune protection ne sera garantie en terme d'efficacité.
un bon monit et ça roule, pour les DoS ;-)
Et on tombe vraiment dans la rustine là, je n'aime vraiment pas.
Bah, si t'as ton parapluie. Tu peux aussi te dire que t'en veux pas comme client, et il donnera ses sous ailleurs :-)
Julien Escario escario@azylog.net écrit :
L'appli est encore maintenue par le développeur 'historique'. Contrat type tierce maintenance applicative. Donc pour toi, ils n'ont aucune obligation à faire tourner ça sur une plateforme respectant l'état de l'art, ne serait-ce qu'en matière de sécurité ? Pour moi, payer une maintenance annuelle, ça implique quand même d'être dans les clous question version de PHP 'moderne' mais je suis un grand rêveur.
Tu es un grand réveur. Il ne faut pas se leurrer : la sécurité est un centre de coût, et tout le monde s'en tape. Il faut qu'il y ait une catastrophe pour qu'ils comprennent qu'appliquer les patchs n'est pas du pognon jeté par les fenêtres.
Là où je suis, le client m'interdit même de faire les mises à jour de sécurité parce que l'arrêt de deux heures pour le faire est insupportable pour les utilisateurs. Bon, c'est pas du PHP, et c'est pas à poil sur l'internet, et ça ne craint pas trop, mais quand même...
Malheureusement, la tendance actuelle est d'externaliser non seulement les développements de SI, mais également d'externaliser le SI lui-même en mode SaaS. Ce qui me parait une idée curieuse...
Je rève d'une boite qui déciderait de reprendre la main sur son SI et de tout internaliser, y compris les développements histoire de garder la maîtrise de son coeur de métier, y compris les process métiers. Mon CV est dispo... ;-)
Bonjour,
Je rejoins les réponses précédentes, quasiment impossible à forcer de faire l'upgrade si c'est pas prévu.
Tu peux donc utiliser un web application firewall (modsecurity) pour palier aux problèmes de sécurité de PHP (et certainement de l'application elle-même) Ma recette c'est : en frontal : un apache+mod_security en reverse proxy avec fail2ban pluggé sur les logs de mod_security (ce dernier n'étant pas en mode coupure) en backend : un apache+php4+appli + iptables configuré en local avec policy en DROP pour toutes les chaines (input/output) sauf le strict nécessaire. (si possible un fw entre les deux)
en tout cas, ne pas mettre en direct ton apache+php4+appli. Si jamais une personne malveillante arrive à bypasser le modsecurity (c'est toujours possible... et souvent à cause d'un bug de sécurité de l'application), il sera beaucoup plus embêté en étant dans sur un serveur backend très limité sur le plan des connexions (in/out) (mais bon la sécurité à 100% utopie)
Dernière chose, tu peux aussi rajouter les acl niveau IP si c'est possible pour l'accès depuis Internet, du https voir même une authentification par certificat SSL obligatoire, etc pour limiter les utilisateurs possibles. L'ACL peut être aussi en GeoIP (module apache) pour limiter les ip entrante à un pays (si c'est possible pour les utilisateurs) ceci t'évitera un bon gros paquet de tentative d'attaques.
A+
Le 27/05/2011 15:25, Julien Escario a ecrit :
Bonjour, Un projet de migration m’amène dans une situation inédite pour moi : Je récupère une application web sur mes serveurs. Le problème : l'application de fonctionne avec PHP 5.2 (je n'ai même pas voulu essayer en 5.3). L'ancien hébergeur (et développeur de l'application - y compris dans le futur), me dit que le pré-requis est en PHP 4.4. Effectivement, après bidouillage sur un serveur de test, l'application tourne effectivement sur PHP4.
Mais voilà, PHP4, le support est arrêté depuis 2008. Et d'après les sites de sécu, c'est 34 failles de sécurité non patchées et qui ne le seront jamais. Autant dire que les hackers vont se faire plaisir ...
A priori, pas de trace de l'obligation écrite de la boite de dev de suivre les versions du langage.
D'où ma question : le client est-il en mesure de forcer (par négo, voir par avocat) à rendre son application compatible PHP5 ? Histoire de savoir qui va devoir payer le dev pour upgrader ce soft.
Est-ce que certains d'entre vous ont déjà eu un cas de figure similaire et comment ça s'est terminé ?
Merci, Julien
P.S. : pour la blague, le prestataire actuel ne semble avoir aucun remord à faire tourner cette appli sur un serveur mutu avec PHP 4.4.8 ... _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 27 mai 2011 19:44, Milamber milamberspace@gmail.com a écrit :
utilisateurs possibles. L'ACL peut être aussi en GeoIP (module apache) pour limiter les ip entrante à un pays (si c'est possible pour les utilisateurs) ceci t'évitera un bon gros paquet de tentative d'attaques.
Ou comment rendre ton site totalement inaccessible aux usagers des petits FAI et à ceux qui sont en IPv6. A moins de laisser un trou qui rend la "protection" inutile.
Non, GeoIP ce serait une erreur dans un contexte sécurité. Un peu comme la plupart des RBLs...
On 04/06/11 13:48, Jérôme Nicolle wrote:
Le 27 mai 2011 19:44, Milambermilamberspace@gmail.com a écrit :
utilisateurs possibles. L'ACL peut être aussi en GeoIP (module apache) pour limiter les ip entrante à un pays (si c'est possible pour les utilisateurs) ceci t'évitera un bon gros paquet de tentative d'attaques.
Ou comment rendre ton site totalement inaccessible aux usagers des petits FAI et à ceux qui sont en IPv6. A moins de laisser un trou qui rend la "protection" inutile.
Non, GeoIP ce serait une erreur dans un contexte sécurité. Un peu comme la plupart des RBLs...
Ça dépend du use case. C'est plutôt utile et efficace sur un accès FTP authentifié. Depuis que j'ai mis ça en place il y presque un an sur le mutu, plus aucun problème. Avant cela, on avait au moins une fois par semaine un accès illégitime, les clients se faisant piquer leur mot de passe enregistrés sur leur machine (vers, keylogger ou autre joyeuseté). Il a juste fallut régler qqs faux positifs au début (des ranges d'IP mal localisés).
On ven. 27 mai 2011 19:44:52 CEST, Milamber milamberspace@gmail.com wrote:
Bonjour,
Je rejoins les réponses précédentes, quasiment impossible à forcer de faire l'upgrade si c'est pas prévu.
Tu peux donc utiliser un web application firewall (modsecurity) pour palier aux problèmes de sécurité de PHP (et certainement de l'application elle-même) Ma recette c'est : en frontal : un apache+mod_security en reverse proxy avec fail2ban pluggé sur les logs de mod_security (ce dernier n'étant pas en mode coupure) en backend : un apache+php4+appli + iptables configuré en local avec policy en DROP pour toutes les chaines (input/output) sauf le strict nécessaire. (si possible un fw entre les deux)
en tout cas, ne pas mettre en direct ton apache+php4+appli. Si jamais une personne malveillante arrive à bypasser le modsecurity (c'est toujours possible... et souvent à cause d'un bug de sécurité de l'application), il sera beaucoup plus embêté en étant dans sur un serveur backend très limité sur le plan des connexions (in/out) (mais bon la sécurité à 100% utopie)
Dernière chose, tu peux aussi rajouter les acl niveau IP si c'est possible pour l'accès depuis Internet, du https voir même une authentification par certificat SSL obligatoire, etc pour limiter les utilisateurs possibles. L'ACL peut être aussi en GeoIP (module apache) pour limiter les ip entrante à un pays (si c'est possible pour les utilisateurs) ceci t'évitera un bon gros paquet de tentative d'attaques.
A+
Le 27/05/2011 15:25, Julien Escario a ecrit :
Bonjour, Un projet de migration m’amène dans une situation inédite pour moi : Je récupère une application web sur mes serveurs. Le problème : l'application de fonctionne avec PHP 5.2 (je n'ai même pas voulu essayer en 5.3). L'ancien hébergeur (et développeur de l'application - y compris dans le futur), me dit que le pré-requis est en PHP 4.4. Effectivement, après bidouillage sur un serveur de test, l'application tourne effectivement sur PHP4.
Mais voilà, PHP4, le support est arrêté depuis 2008. Et d'après les sites de sécu, c'est 34 failles de sécurité non patchées et qui ne le seront jamais. Autant dire que les hackers vont se faire plaisir ...
A priori, pas de trace de l'obligation écrite de la boite de dev de suivre les versions du langage.
D'où ma question : le client est-il en mesure de forcer (par négo, voir par avocat) à rendre son application compatible PHP5 ? Histoire de savoir qui va devoir payer le dev pour upgrader ce soft.
Est-ce que certains d'entre vous ont déjà eu un cas de figure similaire et comment ça s'est terminé ?
Merci, Julien
P.S. : pour la blague, le prestataire actuel ne semble avoir aucun remord à faire tourner cette appli sur un serveur mutu avec PHP 4.4.8 ... _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
-
Dominique Rousseau -
Julien Escario -
Jérôme Nicolle -
Michael FROMENT -
Milamber -
Olivier Le Cam -
Stephane Dupille