15/03/2008: Pourquoi il faut désactiver display_errors dans le php.ini sur les serveurs de prod
Si vous allez sur le site de en ce moment il y a des chances que vous voyez ceci:
J'en profite pour rappeler qu'il est impératif de mettre la directive [display\_errors][dis] à "off" et mettre en place un fichier de log via [error\_log][err] à la place.
[dis]: http://fr.php.net/manual/en/ref.errorfunc.php#ini.display-errors
[err]: http://fr.php.net/manual/en/ref.errorfunc.php#ini.error-log
09/02/2008: Sécurité PHP5 et MySQL
Il y a quelques temps déjà [Damien Seguy][dams] m'a demandé si je voulais bien faire une revue de son livre "[Sécurité PHP5 et MySQL][livre]", j'ai accepté avec grand plaisir et peu de temps après il m'a envoyé un exemplaire (la partie *disclaimer* comme disent nos amis anglo-saxons).
Le livre passe en revue de nombreuses considérations à prendre en compte lors du développement d'applications web. Bien sur des composantes tiennent du bon sens et sont applicables ailleurs que le web.
Le sommaire (repris du site [Eyrolles][ey]):
# Risques liés aux applications web
* Introduction à la sécurité des applications web
* Vulnérabilités des pages web
* Formulaires et téléchargement ; valider les données
* Cookies et sessions
# Mesures de sécurité pour PHP
* Installation et configuration de PHP
* Intégrité des scripts PHP
* Risques liés aux bases de données
* Vulnérabilités des base de données
* Mesures de sécurité pour MySQL
# Mesures de sécurité pour les technologies connexes
* Mesures de sécurité côté serveur
* Techniques de sécurisation des applications web
* Mener un audit de sécurité
Le plan est clair est progressif, les aspects simples précédents les attaques plus tordues. Les auteurs rappellent à tout moment qu'il s'agit de faire un compromis entre les différents éléments d'un système dont la sécurité fait partie.
Si vous débutez ou n'avez jamais pris l'aspect sécurité de façon sérieuse je vous recommande vivement d'acheter cet ouvrage. Vous y apprendrez toutes les bases nécessaires.
Pour ceux déjà familier avec la sécurité il servira de référence. Vous pourrez aussi le laisser négligemment traîner sur votre bureau pour le porter à l'attention de vos collègues. Et enfin il vous donnera bons arguments lors des discussions avec vos responsables.
[dams]: http://www.nexen.net
[livre]: http://www.eyrolles.com/Informatique/Livre/9782212121148/livre-securite-php-5-et-mysql.php
[ey]: http://www.eyrolles.com 31/12/2007: Sécurité et applications "closed source"
Lu sur la page d'un framework MVC
"Closed source applications are generally more secure, by limiting access to the original source we reduce the ability to have [it] exploited."
J'ai de sérieux doutes quand au bien-fondé d'une telle remarque. La citation suivante illustre bien le contre-argument
>As a cryptography and computer security expert, I have never understood
>the current fuss about the open source software movement. In the
>cryptography world, we consider open source necessary for good
>security; we have for decades. Public security is always more secure
>than proprietary security. It's true for cryptographic algorithms,
>security protocols, and security source code. For us, open source isn't
>just a business model; it's smart engineering practice.
Bruce Schneier in Crypto-Gram Newsletter,
L'idée est que la sécurité est bien meilleure lorsque de nombreuses personnes peuvent analyser les mécanismes utilisés or, dans le cas de code propriétaire, le nombre de paires d'yeux conduisant une analyse est bien moins important. La conclusion logique est que la sécurité est moindre.
Cela n'a rien de bien nouveau en soi mais je suis surpris que l'on puisse encore lire de tels arguments.
Je me suis aperçu plus tard le site n'a pas vu de mise à jour depuis un an et demi et donne tous les signes d'une mort clinique. L'argument de la meilleure sécurité ne leur a pas réussi apparemment.
23/11/2007: WAMP2
A l'occasion du forum Romain Bourdon à annoncé la sortie de WAMP2 qui permet notamment d'installer des versions différentes de PHP et MySQL, tous les détails sont sur
12/10/2007: Pyrus: l'installateur de PEAR réinventé
[Joshua Eichorn][josh] à récemment [posté][post] une liste des nouveautés attendues dans la nouvelle version de l'installateur de PEAR. Afin d'éviter la confusion possible à l'heure actuelle l'installateur va changer de nom et s'appeler [Pyrus][py] tandis que le "repository" de paquetages se nommera PEAR2.
Voici la liste des points abordés par Joshua lors de sa "PEAR2 Unconference" en marge de la ZendCon.
1. Aucune installation n'est nécessaire. Pyrus vient sous la forme .phar qui peut être lancé directement sous PHP.
2. La plupart des paquetages peuvent être utilisés sans installation et plus tard mis à jour via Pyrus.
3. Pyrus est fait pour le scénario développement/déploiement. Une commande "deploy" permettra de gérer le déploiement sur un serveur de production
4. Le code de Pyrus est plus petit et utilise beaucoup moins de mémoire.
5. Les formats supportés par défaut sont .tar, .tgz, .tbz, .zip, and .phar
6. La version minimum requise est PHP 5.3+ qui permet d'utiliser les fonctionnalités avançées telles que les itérateur SPL, XMLReader/XMLWriter, l'extension ZIP, l'extension phar (si activée), les exceptions
7. Le support des applications (en plus des paquetages) via les rôles www and cfg (fichiers de configuration)
8. Pyrus peut installer la quasi-totalité des paquetages utilisant le format 2.0 de package.xml sans avoir besoin de modifier le code. Vous pouvez également utiliser Pyrus pour gérer vos paquetages PEAR.
[josh]: http://blog.joshuaeichorn.com
[post]: http://blog.joshuaeichorn.com/archives/2007/10/10/pear2-unconference/
[py]: http://fr.wikipedia.org/wiki/Pyrus
« Page précédente
(Page 2 de 11 sur 51 billets au total)
Page suivante »