Cookie & securité

[Anthor]

Je ne pense pas que ce soit plus dangereux de faire ce que tu indiques : un tel fichier PHP est toujours placé en dehors du DocumentRoot (ce répertoire souvent nommé www/, public/ ou public_html/ qu'on trouve à la racine de notre FTP), donc il n'est pas accessible par le Web : même si le serveur Web arrêtait d'interpréter les scripts, sont contenu ne serait pas accessible.


Sephi-Chan

Si on faisait un sondage, je ne suis pas sûr que ca dépasserait les 10% d'utilisation et pourtant 95% des hébergeurs propose cette gestion des dossiers

[Sephi-Chan]

Ben ça leur fera les pieds s'ils se font avoir !


Sephi-Chan

[Aleskweb]

Personnellement je trouve qu'un cookie a le désavantage de pouvoirs etre modifié. Par consequent, enregistrer des variables dedans ne serait pas très astucieux. Je pense que il vaut mieu tout faire avec les Sessions les Post et les Gets sans bien sur ne pas oublier de le sécuriser (Pas comme le système de news du sdz qui comporte une faille enorme dont beaucoup de novices ne s'en rendent pas compte et par conséquent laissent leurs bdd ouverte au premier devellopeur venu !)

[My Hotel]

Alors, tu dis que les cookies peuvent être modifiés, puis tu dis, mieux vaut utiliser GET/POST. Je savais pas que GET/POST étaient moins modifiables par l'user que les COOKIES... C'est même plus simple de changer un paramètre GET qu'un cookie (2s de moins environ ). Pour moi, never trust user input s'applique aussi aux cookie, puisqu'ils proviennent de l'utilisateur. L'erreur des débutants, c'est de croire que les cookies sont sûrs, mais si on y applique les même sécurités que get ou post, pas de souçis.
Sinon, rien compris à ta dernière phrase sur le SdZ

Bye

[Anthor]

Personnellement je trouve qu'un cookie a le désavantage de pouvoirs etre modifié. Par consequent, enregistrer des variables dedans ne serait pas très astucieux. Je pense que il vaut mieu tout faire avec les Sessions les Post et les Gets sans bien sur ne pas oublier de le sécuriser (Pas comme le système de news du sdz qui comporte une faille enorme dont beaucoup de novices ne s'en rendent pas compte et par conséquent laissent leurs bdd ouverte au premier devellopeur venu !)

J'ai tellement rigolé, que j'en ai pleuré, j'ai failli mouillé mon caleçon !

[Sephi-Chan]

Personnellement je trouve qu'un cookie a le désavantage de pouvoirs etre modifié. Par consequent, enregistrer des variables dedans ne serait pas très astucieux. Je pense que il vaut mieu tout faire avec les Sessions les Post et les Gets sans bien sur ne pas oublier de le sécuriser (Pas comme le système de news du sdz qui comporte une faille enorme dont beaucoup de novices ne s'en rendent pas compte et par conséquent laissent leurs bdd ouverte au premier devellopeur venu !)

Ne prends pas mal ce qui suit. La sécurité est un sujet important sur lequel il faut avoir des connaissances suffisamment solide pour ne pas induire en erreur les personnes qui vont te lire.

Certaines informations sans importance peuvent bien être stockées côté client. Ça ne pose pas de problème.

Quant à la sécurité, je ne vois pas ce que viennent faire les POST et les GET là dedans… Comme les cookies, ils sont envoyés par le client, et à ce titre on ne doit pas leur faire confiance. On peut donc amalgamer sans problème toutes les données transmises par les actions HTTP (c'est d'ailleurs ce que font certains frameworks).

Seules les sessions ne peuvent pas être modifiées puisque ce sont des données stockées dans un fichier situé sur le serveur. Elles portent un identifiant qu'on transmet au client (et à lui seul) afin qu'il puisse les redemander à chaque requête HTTP qu'il adresse au serveur.

Le passage de cet identifiant peut se faire de deux manières :

• Grâce à un cookie (généralement nommé sid) ;
  
• Grâce à la query string. PHP accolera à toutes les pages internes au site un paramètre GET qui ressemble généralement à SID=dze3x5lc52ksx ;
  

Un peu de lecture à ce sujet : PHP.net - Passer l'identifiant de session (session ID).

Certains serveurs sont configurés pour refuser de transmettre l'identifiant de session dans l'URL. C'est une bonne chose à faire.

Pour le faire, ça se passe dans le fichier php.ini (si vous utilisez PHP, ça va de soi) en modifiant la directive session.use_only_cookies à 1.


Sephi-Chan

[Argorate]

Je ne pense pas que ce soit plus dangereux de faire ce que tu indiques : un tel fichier PHP est toujours placé en dehors du DocumentRoot (ce répertoire souvent nommé www/, public/ ou public_html/ qu'on trouve à la racine de notre FTP), donc il n'est pas accessible par le Web : même si le serveur Web arrêtait d'interpréter les scripts, sont contenu ne serait pas accessible.


Sephi-Chan

Si on faisait un sondage, je ne suis pas sûr que ca dépasserait les 10% d'utilisation et pourtant 95% des hébergeurs propose cette gestion des dossiers

10% et 95% pour quelle méthode? ^^

Sinon, si je demande ça, c'est parce qu’on m'a sortie, lors de ma soutenance de projet, que c'était une grosse faille de sécurité… Alors j'ai dis exactement pareil que sephi et ils m'ont sorti : "Oui mais on peut par des moyens détourné faire afficher le contenu de la page PHP" ou chez pas quoi, ils n’ont pas étaient clair. Je n’ai pas insisté pour ne pas risquer de faire baisser ma note... (Ces gens sont bête est borné).

Bref, zetes bien sur que c'est une méthode clean?

[Sephi-Chan]

10% et 95% pour quelle méthode? ^^

Sinon, si je demande ça, c'est parce qu’on m'a sortie, lors de ma soutenance de projet, que c'était une grosse faille de sécurité… Alors j'ai dis exactement pareil que sephi et ils m'ont sorti : "Oui mais on peut par des moyens détourné faire afficher le contenu de la page PHP" ou chez pas quoi, ils n’ont pas étaient clair. Je n’ai pas insisté pour ne pas risquer de faire baisser ma note... (Ces gens sont bête est borné).

Bref, zetes bien sur que c'est une méthode clean?

La méthode dont on parle consiste à configurer son serveur de façon à avoir un répertoire public. Pour ça, il faut que l'application soit bâtie selon une architecture de ce genre :

my_app

|-- public

|   |-- images

|   |-- index.html

|   |-- javascripts

|   `-- stylesheets

`-- secret_file.php

C'est le cas de la majorité des hébergements mutualisés (seul le nom du répertoire public diffère, c'est souvent www ou public_html). Si ce n'est pas le cas, il est temps de changer d'hébergement

Derrière tout ça, il y un VirtualHost de ce genre :

<VirtualHost *:80>

  DocumentRoot /www/my_app/public    # Adresse physique du site sur le serveur.

  ServerName   nom-de-domaine.com    # Nom d'hôte du site.

</VirtualHost>

Ainsi, quand on va sur nom-de-domaine.com, on est dans public/ et on ne peut pas remonter dans l'arborescence (pour accéder à secret_file.php). Par contre, on peut accéder à index.html et descendre dans l'arborescence (pour accéder aux dossiers images et compagnie).

Le jury qui t'a noté était sûrement constitué de clowns. Ça fait bien de dire que telle ou telle sécurité ne tient pas : encore faut-il le prouver (ou montrer des ressources qui le prouvent).


Sephi-Chan

[Allwise]

Si on faisait un sondage, je ne suis pas sûr que ca dépasserait les 10% d'utilisation et pourtant 95% des hébergeurs propose cette gestion des dossiers

Toutes les plateformes toutes faites : CMS, forums, blogs, annuaires etc etc... ne sont pas développées comme ça et démocratisent la méthode standard, placer le fichier de conf avec les autres.
En même temps, c'est aussi le gage que ça ne pose aucun problème de sécurité, finalement.

Je serais curieux aussi de connaître leurs moyens détournés... Si une faille quelconque était assez puissante pour en arriver là, je pense que peu importe que le fichier se situe dans le DocumentRoot ou non, ça changerait rien.

[Sephi-Chan]

Toutes les plateformes toutes faites : CMS, forums, blogs, annuaires etc etc... ne sont pas développées comme ça et démocratisent la méthode standard, placer le fichier de conf avec les autres.
En même temps, c'est aussi le gage que ça ne pose aucun problème de sécurité, finalement.

Le truc, c'est que si tes fichiers de configuration ne sont pas des fichiers PHP, ils sont directement accessibles. À moins de les protéger (par .htaccess ?).

Ça me ferait chier que n'importe qui puisse exécuter les scripts que je lance avec des Crons ou accède à mes fichiers de configuration en YAML.

Avec la technique du répertoire public, tu n'es pas embêté, la protection est fiable et systématique. En sécurité, il faut toujours préférer l'approche white list que l'approche black list.


Sephi-Chan