Écrire un article sur la sécurité

[Sephi-Chan]

a noter perso, c'est surtout l'aspect golive et post golive qui m'intéresse (donc modération etc...) parce que pour le reste j'ai ce qu'il faut... ici ^^ mais évidemment ça a sa place dans ton blog.

et si jamais tu peux faire des trucs vraiment sérieux sur la sécurité ça m'intéresse aussi, puisque les vilains coquins de jeuweb me font pas un truc bien blindés malgré mes appels répétés :p

Le problème Ter Rowan, c'est que pour un article sur la sécurité, il y a plein de choses à dire mais l'amplitude du niveau requis est conséquente !

• La sécurité du serveur en lui-même : tenir son système à jour, avoir des mots de passes forts et utiliser de l'authentification forte. Ok. Quelles distributions ?
  
• La sécurité du serveur Web : mettre les fichiers sensibles hors du document_root, restreindre l'accès à certains répertoire, etc. Ok, mais il faut couvrir au moins Apache et Nginx.
  
• La sécurité de la base de données : ne pas utiliser le compte root, ne pas laisser le mot de passe par défaut de root, etc. Ok, à faire au moins pour MySQL, PostgreSQL.
  
• La sécurité de l'application l'application Web : contrôle l'accès à certaines pages selon des permissions, éviter les failles CSRF, XSS, les injections SQL, etc. Ok, mais avec quels langages ? Quels frameworks ? Et comment fournir quelque chose adaptable pour tout le monde pour les gens qui font tout en vieux PHP from scratch ?
  
• La sécurité du code métier : empêcher que le mec s'attaque lui-même ou un type qui n'est pas à portée, empêcher que le mec gagne des sous en mettant un prix négatif, etc. Ok, mais ça dépend des besoins de chacun.
  

Enfin voilà, c'est un sujet extrêmement large et ça décourage les auteurs potentiels : il faut essayer de leur donner plus de pistes qui les aideront à commencer. C'est déjà très dur d'écrire un article, si en plus il faut couvrir un truc immense et/ou mal défini, c'est mission impossible et personne ne s'y aventurera.

[Ter Rowan]

Le problème Ter Rowan, c'est que pour un article sur la sécurité, il y a plein de choses à dire mais l'amplitude du niveau requis est conséquente !

• La sécurité du serveur en lui-même : tenir son système à jour, avoir des mots de passes forts et utiliser de l'authentification forte. Ok. Quelles distributions ?
  
• La sécurité du serveur Web : mettre les fichiers sensibles hors du document_root, restreindre l'accès à certains répertoire, etc. Ok, mais il faut couvrir au moins Apache et Nginx.
  
• La sécurité de la base de données : ne pas utiliser le compte root, ne pas laisser le mot de passe par défaut de root, etc. Ok, à faire au moins pour MySQL, PostgreSQL.
  
• La sécurité de l'application l'application Web : contrôle l'accès à certaines pages selon des permissions, éviter les failles CSRF, XSS, les injections SQL, etc. Ok, mais avec quels langages ? Quels frameworks ? Et comment fournir quelque chose adaptable pour tout le monde pour les gens qui font tout en vieux PHP from scratch ?
  
• La sécurité du code métier : empêcher que le mec s'attaque lui-même ou un type qui n'est pas à portée, empêcher que le mec gagne des sous en mettant un prix négatif, etc. Ok, mais ça dépend des besoins de chacun.
  

Enfin voilà, c'est un sujet extrêmement large et ça décourage les auteurs potentiels : il faut essayer de leur donner plus de pistes qui les aideront à commencer. C'est déjà très dur d'écrire un article, si en plus il faut couvrir un truc immense et/ou mal défini, c'est mission impossible et personne ne s'y aventurera.

à mais je dis pas le contraire, c'est au moins aussi large que mon incompétence sur le sujet d'où mes attentes ^^

[Sephi-Chan]

Bah voilà ! Plus qu'à déterminer les priorités et dire ce qui t'intéresse le plus parmi tout ça.

[Ter Rowan]

tiens, ben commençons par un truc qui doit pas être compliqué pour apporter une pierre à l'édifice

la gestion des répertoires. On a plusieurs fois parler du sujet - toujours pas très clair pour moi - de restreindre l'accès aux répertoires.

ce serait bien (enfin pour moi, c'est peut être évident pour les autres d'avoir un article la dessus

j'imagine un plan de ce type :

Organisation des répertoires
Instructions (si serveur apache, si serveur truc...)
Explications


les deux premiers points le comment faire, le troisième pourquoi on le fait.

[atra27]

Ben on ne peut pas vraiment non plus...

Avec apache, ça serait un simple htaccess-> dans ce cas y a deja des cours sur les htaccess

Avec php, from scratch, il faut sécuriser les fichiers du répertoire -> renvoie sur un cours pour faire un espace membre.

Avec php + FW, voir la doc du FW, mais en général les repertoires sont réécrits pour renvoyer vers un controller

Avec asp, java, ruby, whatever, ça sera différent.

Le probléme de la sécu, c'est que c'est pas un tuto sur "comment XXX ?" qu'il faudrait car ces domaines sont déjà couverts par des tutos sur d'autres sujets, mais plutôt "Quelles sont les failles potentielles"

Après si le programmeur n'est pas capable de comprendre le pourquoi et le comment de la faille, verrifier que son systeme est sécurisé, et le cas échéant se coder/trouver un systeme pour combler cette faille, c'est mal barré!

Il existe deja des tutos sur le SDZ contre les failles CSRF, XSS et les injections SQL.
Je les trouves bien foutu car le premier chapitre présente ce que sont ces failles et comment ça marche.
Les autres développent une résolution en php sans FW, mais un codeur un peu débrouillard et pas trop feignant saura adapter s'il a compris le principe dans la première partie!

D'ou le fait qu'il n'y a pas de tto sur la sécurité mais juste des tutos sur les failles, et des tutos sur "comment faire XXX", reste ensuite a réfléchir et joindre les deux

Enfin ce n'est que mon explication personnelle sur certains cas, pas une vérité générale!

[niahoo]

juste un petit détail, je mettrais d'abord le pourquoi, et ensuite le comment. parce que sinon le tuto explique comment suivre bêtement des règles sans savoir pourquoi et ce n'est pas bon.

ensuite ne pas mettre des répertoires contenant des fichiers de config ou autre dans le document root, le pourquoi est simple : on ne veut pas qu'ils soient vus. et le comment : ben tu les mets pas dans le document root !!

mouarf.

Encore un post utile signé niahoo.

[Sephi-Chan]

Entièrement d'accord : il faut expliquer pourquoi avant d'expliquer comment.

Tu parles ici de la protection des répertoires. Pourquoi voudrais-t-on protéger l'accès à un répertoire ?

La raison la plus évidente, c'est bien parce qu'il contient des fichiers importants : identifiants de la base de données, scripts de maintenance, scripts cron, etc.

Heureusement, les serveurs Web ont été conçus dans cette optique et ils permettent de définir un site en associant un nom de domaine à un répertoire sur le système de fichier de la machine. Ce répertoire — appelé DocumentRoot dans Apache et root dans Nginx — représente le dossier dans lequel on se trouve lorsque l'on navigue à la racine du nom de domaine indiqué.

Exemple de configuration avec Nginx :

server {

  listen      80;

  server_name jeuweb.org;

  root        /home/jeuweb/public_html;

  index       index.php;

}

Ainsi, un script situé dans /home/jeuweb n'est pas accessible depuis le Web. Votre serveur Web ne trahira jamais son contenu !

En revanche, votre application (écrite en PHP, par exemple) pourra accéder aux répertoires sous-jacents.

Imaginons un simple script dont le but est de servir une image aléatoire mais sans permettre de naviguer parmi les images disponibles. Voici une architecture correcte :

/home/avatar_displayer

├── avatars

│   ├── 1.png

│   ├── 2.png

│   └── 3.png

└── public

    └── avatar.php

Avec un DocumentRoot pointant sur /home/avatar_displayer/public, l'accès au répertoire /home/avatar_displayer/avatars est impossible depuis un client HTTP.
En revanche, notre script avatar.php peut y accéder. Par exemple :

<?php

$filename = mt_rand(1, 3) . ".png";

$filepath = "../avatars/" . $filename;



header('Content-Type: image/png');

header('Content-Disposition: inline');

header('Content-Transfer-Encoding: binary');

header('Content-Length: ' . filesize($filepath));

readfile($filepath);

?>

[Ter Rowan]

ok pour le pourquoi avant le comment et merci pour ce premier point

quelques critiques (et la je suis béotien, je ne sais pas quoi mettre)

(+) le pourquoi n'est pas suffisant :
je ne sais pas comment moi, simple internaute, je peux accéder aux fichiers de document root (ça doit être ultra basique comme sujet mais voilà 0 idée, bien sûr en cherchant je trouverais, bien sûr en réfléchissant un peu j'ai l'intuition du machin, maisbon c'est mieux en le mettant noir sur blanc

(+) le pourquoi n'est pas suffisant 2 :

En revanche, votre application (écrite en PHP, par exemple) pourra accéder aux répertoires sous-jacents.

Pourquoi ? j'imagine que ce n'est pas l'utilisateur mais le serveur (ou le script, ou le je sais pas quoi un truc du genre) qui a accès au fichier mais juste quelques mots la dessus serait pas mal pour bien comprendre

(+) pour apache, comme pour nginx ce serait bien de dire comment modifier le paramétrage (bon j'ai trouvé dans apache un documentroot dans httpd.conf, ça doit être là mais voilà, tant qu'à faire...)


sinon l'idée de l'exemple (et de l'arborescence et du code pour l'image) me parait bien, faudrait juste penser aussi à l'exemple de ce qu'il faut faire comme paramétrage (mon troisième point)


quand je me lis je me dis que je suis à peu près au niveau du gus qui affiche 100 lignes de code en disant qu'il y a une erreur quelque part (il manque un ";" banane ligne 33, t as qu'à lire le message d'erreur) mais voilà, y a 15 ans je faisais du c++ à l'école, j'ai appris à jouer avec du chmod unix, mais sans savoir pour quelle application.

Depuis je pisse du php plus ou moins propre à la maison, mais toujours en localhost, avec des installations "automatisées" double clic et hop ça marche donc évidemment chuis un peu quiche la dessus, je me suis jamais frotté au web réel ^^ (sauf dans mon boulot, en tant que manager / aboyeur mais là c'est une autre histoire)

[Sephi-Chan]

ok pour le pourquoi avant le comment et merci pour ce premier point

quelques critiques (et la je suis béotien, je ne sais pas quoi mettre)

(+) le pourquoi n'est pas suffisant :
je ne sais pas comment moi, simple internaute, je peux accéder aux fichiers de document root (ça doit être ultra basique comme sujet mais voilà 0 idée, bien sûr en cherchant je trouverais, bien sûr en réfléchissant un peu j'ai l'intuition du machin, maisbon c'est mieux en le mettant noir sur blanc

Considère un VirtualHost (hop, une notion de plus) qui a pour ServerName www.foo.com et pour DocumentRoot /home/foo/public.

Si tu crées un fichier foo.txt dans ce répertoire, tu pourras y accéder grâce à ton navigateur Web à l'adresse http://foo.com/foo.txt.

(+) le pourquoi n'est pas suffisant 2 :

En revanche, votre application (écrite en PHP, par exemple) pourra accéder aux répertoires sous-jacents.

Pourquoi ? j'imagine que ce n'est pas l'utilisateur mais le serveur (ou le script, ou le je sais pas quoi un truc du genre) qui a accès au fichier mais juste quelques mots la dessus serait pas mal pour bien comprendre

Apache exécute tes scripts PHP en tant qu'un utilisateur précis (parfois www-data, mais ça change selon les distributions). Il faut que ce compte dispose des permissions pour lire les fichiers (et écrire dedans, dans le cas d'un dossier d'uploads, par exemple). Là encore, ça demande des notions.

Depuis je pisse du php plus ou moins propre à la maison, mais toujours en localhost, avec des installations "automatisées" double clic et hop ça marche donc évidemment chuis un peu quiche la dessus, je me suis jamais frotté au web réel ^^ (sauf dans mon boulot, en tant que manager / aboyeur mais là c'est une autre histoire)

N'utilise pas ce genre d'installation, qui te masque tous les mécanismes et utilise un OS adapté au langage et aux outils que tu utilises. Installe-toi une machine virtuelle sous Linux (Ubuntu server ou Debian), installe ton propre Apache/Nginx.

Le temps que tu passeras à apprendre n'est jamais perdu, et la quantité d'articles sur le sujet (surtout en anglais) rend ça très accessible.


Les questions que tu poses sont à tiroir : pour expliquer une notion, il faut en introduire 3 nouvelles et ainsi de suite. C'est pire qu'une Hydre.

Le mieux est d'écrire toi-même l'article, en écrivant chaque question que tu te poses au fur et à mesure, et en y apportant une réponse ou ce qui te semble être une réponse. Puis ceux qui savent passent derrière pour corriger/expliquer. Au moins tu es sûr que toutes les questions de débutant seront couvertes.

Bref, tout le monde doit se mettre au boulot pour un article de qualité.

[atra27]

+1, poste donc tout ça sur le wiki de jeuweb.
C'est plus stable qu'un forum (vu que c'est de la doc pérenne), mais on peut toujours combler les manques de ce que tu y aura mis