|
Prochaine révision
|
Révision précédente
|
langages:php:erreurs [08/12/2014 16:28]
127.0.0.1 modification externe |
langages:php:erreurs [08/05/2015 17:50] (Version actuelle)
julp |
| |
| Il est vrai qu'il est tentant de stocker ses données après leur avoir appliquées htmlentities ou htmlspecialchars de sorte de ne pas avoir à se soucier des failles XSS par la suite. En réalité, cette démarche pourrait, d'une part, être fausse dès que vous réaffichez d'autres données qui ne sont pas d'abord passées par votre base de données ; ce qui serait exceptionnel et risquerait de vous faire prendre de mauvaises habitudes (= failles). D'autre part, se pose la question de la dénaturation des données. Que ferez-vous si vous devez effectuer des recherches dans votre base de données ou encore générer, à partir de celle-ci, des formats non HTML (PDF, Excel, XML, graphique/png, etc) ? Un html_entity_decode à chaque fois ? De même, si vous exploitez cette base à partir d'autres clients (Java, C#, etc), cela vous oblige à rester cohérent donc à trouver et appliquer un équivalent de htmlentities/htmlspecialchars à chacune de leur insertion/modification et html_entity_decode à chaque lecture ? Que de travail inutile ! | Il est vrai qu'il est tentant de stocker ses données après leur avoir appliquées htmlentities ou htmlspecialchars de sorte de ne pas avoir à se soucier des failles XSS par la suite. En réalité, cette démarche pourrait, d'une part, être fausse dès que vous réaffichez d'autres données qui ne sont pas d'abord passées par votre base de données ; ce qui serait exceptionnel et risquerait de vous faire prendre de mauvaises habitudes (= failles). D'autre part, se pose la question de la dénaturation des données. Que ferez-vous si vous devez effectuer des recherches dans votre base de données ou encore générer, à partir de celle-ci, des formats non HTML (PDF, Excel, XML, graphique/png, etc) ? Un html_entity_decode à chaque fois ? De même, si vous exploitez cette base à partir d'autres clients (Java, C#, etc), cela vous oblige à rester cohérent donc à trouver et appliquer un équivalent de htmlentities/htmlspecialchars à chacune de leur insertion/modification et html_entity_decode à chaque lecture ? Que de travail inutile ! |
| | |
| | Notez également que é par rapport à é consomme inutilement 8 fois plus de points de code (types (VAR)CHAR) et 8 à 4 fois plus d'octets suivant le jeu de caractères (types *TEXT) pour son stockage. |
| |
| En tant que bon français, une petite illustration du travail supplémentaire et totalement inutile alors demandé par cette htmlentitiesation en prenant simplement un caractère comme œ et une collation MySQL utf8_unicode_ci où œ = oe (plus insensibilité à la casse). | En tant que bon français, une petite illustration du travail supplémentaire et totalement inutile alors demandé par cette htmlentitiesation en prenant simplement un caractère comme œ et une collation MySQL utf8_unicode_ci où œ = oe (plus insensibilité à la casse). |
| ===== Les noms des fonctions/méthodes sont sensibles à la casse ===== | ===== Les noms des fonctions/méthodes sont sensibles à la casse ===== |
| |
| Encore une fois, c'est totalement faux ! Un petit récapitulatif s'impose, PHP et casse : ce qui y est sensible ou non : | Déplacé sur [[http://www.julp.fr/blog/posts/3-mythe-php-1-c-est-mysql_query-et-non-mysql_query]] |
| | |
| ^ Élément du langage ^ Sensible ou insensible à la casse ^ Note ^ | |
| | Nom d'une constante | sensible (par défaut) | voir ci-dessous | | |
| | Nom d'une classe chargée | insensible | voir ci-dessous | | |
| | Nom d'une fonction/méthode | insensible | - | | |
| | Nom d'une variable (propriétés de classe et d'instance comprises) | sensible | $x et $X désignent deux variables différentes | | |
| | |
| Je reviens sur : | |
| * les constantes : par défaut, le nom de leur déclaration doit être repris. Il est cependant possible, en positionnant le troisième paramètre à valeur vraie de define, de forcer PHP à rendre le nom de la constante insensible à la casse. Les constantes déclarées par const implique nécessairement une sensibilité à la casse (FOO et foo désignent deux constantes différentes). | |
| * les noms de classe : par chargée, j'entends une classe connue de PHP. Si, en revanche, la classe désignée n'existe pas encore et qu'un autoload intervient, ce dernier, lui, peut être affecté par la casse. On pensera notamment au fait que les systèmes de fichiers Windows sont insensibles à la casse quand, sur Unixoïde, c'est le contraire. Par conséquent, que la classe s'appelle "Foo" ou "foo" au niveau de PHP, ça désigne la même classe. Mais, au niveau de l'autoload, quand vous cherchez à inclure un script, le nom (foo.php contre Foo.php), suivant le système, ne donnera pas nécessairement le même résultat : l'un des deux pourra échouer si le nom de la classe ne correspond pas exactement au nom du fichier qui en contient le code. | |
| |
| ===== Il FAUT un try/catch ===== | ===== Il FAUT un try/catch ===== |
| ===== Pour faire expirer mes sessions, je joue sur la durée de vie du cookie PHPSESSID (session.cookie_lifetime) ===== | ===== Pour faire expirer mes sessions, je joue sur la durée de vie du cookie PHPSESSID (session.cookie_lifetime) ===== |
| |
| A moins de savoir ce que l'on fait, c'est à éviter pour deux raisons : | Déplacé sur [[http://www.julp.fr/blog/posts/8-mythe-php-2-pour-faire-expirer-mes-sessions-je-joue-sur-la-duree-de-vie-du-cookie-phpsessid-session-cookie_lifetime]] |
| * premièrement, ce n'est pas parce que vous faites expirer le cookie de session (nommé PHPSESSID par défaut) que la session côté serveur n'existe plus. Au contraire, les fichiers de session (gestionnaire par défaut) vont persister côté serveur. Tout ce que vous allez obtenir c'est une multiplication inutile des fichiers temporaires de session et, du fait qu'ils sont toujours présents côté serveur, ça n'empêcherait pas quelqu'un d'exploiter la session que vous croyez avoir terminée. Ce qui compte avant tout, c'est de configurer le garbage collector pour qu'il soit efficace (il faut trouver le juste équilibre par rapport à son trafic : il ne doit pas être invoqué trop souvent - cela va consommer des ressources machines inutilement - ni pas assez - accumulation des fichiers des sessions expirées et pourrait faciliter le travail d'un attaquant, ça en fait plus de sessions à voler). | |
| * deuxièmement, ce que la plupart des gens ne savent pas, c'est que PHP ne reconduit pas la date d'expiration du cookie d'une requête à l'autre. C'est à dire que si vous mettez session.cookie_lifetime à 15 minutes, que quelqu'un visite votre site à 13h32, qu'il revienne ou non avant 13h47, il perdra sa session (et les données qui vont avec) à 13h47 quoi qu'il arrive. Cela en fait donc un comportement admissible dans de très rares cas, il serait plus dommageable qu'autre chose. | |
| |
| ====== Apache ====== | ====== Apache ====== |
| ===== LIKE est insensible à la casse ===== | ===== LIKE est insensible à la casse ===== |
| |
| J'ignore d'où les gens peuvent tirer une telle affirmation car la documentation de MySQL ne l'a jamais mentionné. Pour cause, chez MySQL, ce qui détermine la sensibilité ou l'insensibilité à la casse c'est ni plus moins que l'interclassement courant et, ce, quel que soit l'opérateur (simple égalité - ''='' - comme LIKE). De la même façon que les jeux de caractères, vous avez toute une chaîne d'héritage pour déterminer la collation courante : | Déplacé sur [[http://www.julp.fr/blog/posts/4-sql-gestion-de-la-casse]] |
| * vous pouvez en expliciter une ponctuellement à tout niveau de la requête via le mot-clé COLLATE | |
| * s'il s'agit d'une colonne, c'est celle que vous lui avez accolée à la création de votre table | |
| * sinon, pour des données liées à aucune colonne, vous héritez de l'interclassement défini par la variable nommée collation_connection | |
| | |
| Pour preuve : | |
| <code sql>mysql> set collation_connection = utf8_bin; | |
| Query OK, 0 rows affected (0.02 sec) | |
| | |
| mysql> select 'foo' LIKE 'F%'; | |
| +-----------------+ | |
| | 'foo' LIKE 'F%' | | |
| +-----------------+ | |
| | 0 | | |
| +-----------------+ | |
| 1 row in set (0.00 sec) | |
| | |
| mysql> set collation_connection = utf8_general_ci; | |
| Query OK, 0 rows affected (0.00 sec) | |
| | |
| mysql> select 'foo' LIKE 'F%'; | |
| +-----------------+ | |
| | 'foo' LIKE 'F%' | | |
| +-----------------+ | |
| | 1 | | |
| +-----------------+ | |
| 1 row in set (0.00 sec)</code> | |
| (ça fonctionnera de la même manière avec tout opérateur) | |
| |
