+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Cookie & securité (/showthread.php?tid=4613)
RE: Cookie & securité - Allwise - 06-03-2010
D'accord avec toi sur toute la ligne, je parlais bien entendu de fichiers de config .php.
RE: Cookie & securité - Anthor - 07-03-2010
Ils prennent la méthode standard mais tu verras que beaucoup ont une méthode pour sortir les fichiers du documentroot, cf dotclear par exemple.
De plus il ne sont en général pas développés avec les pieds et ont suffisamment de suivi pour penser à appliquer les bonnes protections.
Je ne dis pas que c'est plus puissant qu'un .htaccess (Qui soit dit en passant ne change rien avec httpd.conf ^^), je dis que c'est plus optimisé parce que tu n'as pas a y penser et que fichiers d'applications et fichiers public ne sont pas mélangés.
Après chacun est libre de vouloir passer du temps à mettre des protections inutiles alors que les serveurs sont configurés pour, mais ce n'est pas du développement, c'est encore réinventer la route. ^^
RE: Cookie & securité - Argorate - 07-03-2010
En conclusion, si le fichier de config.php est dans le répertoire du du site (sasn htacces ou autre) c'est plutot mauvais mais du moment qu'on le sort du public tout va bien?
j'essai de reformuler pour voir si je comprend, m'en veuillez pas
RE: Cookie & securité - Sephi-Chan - 07-03-2010
- Si un fichier est dans public/, on peut y accéder en tapant son URL ;
- Si un fichier est plus haut dans l'arborescence (my_app/), on ne peut pas y accéder ;
Dans le cas d'un fichier PHP, ça importe peu puisqu'il est exécuté et n'affichera rien (du moins, pour un fichier de config), mais c'est une mauvaise pratique.
Une telle architecture est plus sûre, propre et cohérente :
my_app
|-- config
| |-- config.php
| `-- databases.yml
|-- public
| |-- images
| |-- index.html
| |-- javascripts
| `-- stylesheets
`-- lambda_file.php
Sephi-Chan
RE: Cookie & securité - Argorate - 07-03-2010
on est bien d'accord, je vais donc "tenter" de demander par mail une explication plus aprofondie
RE: Cookie & securité - Aleskweb - 07-03-2010
Woooplaa désolé si je me suis mal exprimé. Ce que je voulais dire c'est que les cookie on ne peut pas utiliser sa comme variable a proprement dite : J'ai un amis qui avait lancé un site ( un jeu en php) ou il mettait dans un cookie l'id de l'user et quand on allait sur le jeu, sa nous connectait automatiquement avec cet id, donc on modifiait le cookie et on changait l'id en le remplacent par celui que l'on voulait. Je rapellais seulement l'erreur de prendre un cookie sans precaution. Aussi je dis qu'il est préférable d'utiliser les superglobales car j'ai toujours su detourner l'utilisation des cookie grace a ces dernières. Donc personnellement je ne vois pas trop l'utilisé des cookies.
Bien sur pour les systèmes d'auto connection, les cookies sont indispensables par exemple (mais faut quand meme pas oublier de sécuriser), mais sinon moi je les détournes autant que possible. Les gets sont bien sur modifiables mais il suffit de ne pas les utiliser n'importe quand (Par exemple je ne les utilises que pour les déplacements, ici il y a une verification de points de mouvement donc pas de tricherie) Sinon un max de Session moi je trouve sa l'idéal.
Pour ce qui est du sdz lisez le système de news, la faille est énorme et le premier gars qui s'y connais un peu en php peut faire une injection sql et peut aller jusqu'a vider les tables etc.... Beaucoups de "novices" font un petit copier collé du code, mettez l'url du get sur google (.php?idnews= si je me souviens bien) et vous verez le nombre qui ont laissé leur site en libre service ^^
En gros tout sa pour dire que les cookies je pense qu'il vaut mieu un maximum les eviter et quelque soit le systèmes (mis a part les Session) il faut bien penser a la sécurité
Ps: Si je me trompe n'hésitez pas a me corriger, l'erreur est humaine. Mais moi j'ai tendance a trop les accumuler >< Et encore désolé si j'ai mis des gens sur la mauvaise route!
RE: Cookie & securité - My Hotel - 08-03-2010
Hum, les sessions c'est bien, mais faut pas en abuser non plus. Certaines données doivent être rechargées à chaque chargement de page.
Sinon, pour tous ces problèmes de sécurités, l'idéal, c'est d'utiliser un framework. L'architecture décrite par Sephi est en place, la sécurité est gérée automatiquement... Bref, on peut se concentrer sur l'essentiel, le jeu lui-même. (je dis ça parce que je me suis mis à Symfony il y a peu, et je suis épaté par la puissance de ce framework!
).Bye