Frameworks & API, PHP & MySQL

L’organisation sécurisée du code

Le 15 mars 2008 à 12:07 par Séverin

Pour bien débuter un projet web, il faut d’entrée de jeu penser à la sécurité. Une fois que des milliers de lignes de codes auront été écrites et des centaines d’URL diffusées, il sera beaucoup plus compliqué de revoir sa copie.

Donc, voilà quelques astuces pour structurer son projet en prenant la sécurité en compte.

La structure des dossiers

Dans cet exemple, chaque dossier à une place et un rôle précis pour éviter les ennuis :

Structure de répertoires d’un projet PHP

  • php : Ce dossier conteint tout le code PHP qui ne sera pas accessible via une URL. Tout ce qui est framework, classes, librairies, templates, …
  • temp : Ici, on enregistrera tout les fichiers générés par le code PHP. C’est à dire le cache, les sessions, les fichiers de données, … Toujours non accessibles via une URL.
  • uploads : Tout les fichiers envoyés par les utilisateurs et qui ne seront pas accessibles via une URL.
  • www : Tout ce qui est inclut dans ce répertoire sera accessible via une URL.
  • www/admin : le répertoire d’administration (si nécessaire).
  • www/admin/index.php : le point d’entré de l’administration.
  • www/images : Juste les images utilisées sur le site
  • www/uploads : Les fichiers uploadés par les utilisateurs, mais ce coup-ci accessibles via une URL.
  • www/index.php : Le point d’entré du site.

Les attributs

Les attributs permettent de définir les droits d’accès de lecture, d’écriture et d’exécution des fichiers et dossiers. En les paramettrant correctement vous sécuriserez d’autant plus votre application. Les droits que je vous indique sont ceux de l’utilisateur exécutant le PHP.

  • php : (lecture seulement) Pas besoin de modifier ces fichiers donc, autant l’interdire pour éviter qu’une utilisation détournée de votre application ne le fasse.
  • temp : (écriture et lecture) On peut retrouver de tout ici. Mais comme c’est le code PHP qui l’a fait, on peut considérer qu’il s’agit d’un contenu de confiance.
  • uploads : (écriture et lecture) On retrouve également de tout, mais ce coup-ci, on ne maitrise pas le contenu.
  • www : (lecture seule) Personne n’a besoin de changer quoi que ce soit ici.
  • www/admin : (lecture seule) Personne n’a besoin de changer quoi que ce soit ici non plus.
  • www/admin/index.php : (lecture seule) Ce fichier est un point névralgique. Aucune changement ne doit être accepté.
  • www/images : (lecture seule) Un répertoire dont le contenu doit resté maitrisé par l’administrateur.
  • www/uploads : (écriture et lecture) Comme son homonyme à la racine, on ne maitrise pas le contenu de ce répertoire.
  • www/index.php : (lecture seule) Ce fichier est un point névralgique. Aucune changement ne doit être accepté.

Un peu plus loin avec les .htaccess

Maintenant, la majeur partie du code est sécurisée. Mais il reste quelques ombres au tableau, les 2 répertoires d’uploads.

Pas de soucis, il suffit d’ajouter un fichier .htaccess pour gérer plus finement les droits.

Ce qu’il suffit de faire, c’est d’interdire les fichiers de scripts (php, asp, javascript, exécutables, batch, …) ou à l’opposée, de n’autoriser que des fichiers bien spécifiques (jpg, gif, png, txt, …)

Pour interdire certains fichiers :

RewriteCond %{REQUEST_URI} ^.*.php.*$ [NC,OR]
RewriteCond %{REQUEST_URI} ^.*.asp.*$ [NC,OR]
RewriteCond %{REQUEST_URI} ^.*.jsp.*$ [NC,OR]
RewriteCond %{REQUEST_URI} ^.*.js.*$ [NC,OR]
RewriteCond %{REQUEST_URI} ^.*.exe.*$ [NC,OR]
RewriteCond %{REQUEST_URI} ^.*.bat.*$ [NC,OR]
RewriteRule .* /index.php [NC,L]

Pour n’autoriser que certains fichiers :

RewriteCond %{REQUEST_URI} !^.*.jpg.*$ [NC]
RewriteCond %{REQUEST_URI} !^.*.jpeg.*$ [NC]
RewriteCond %{REQUEST_URI} !^.*.gif.*$ [NC]
RewriteCond %{REQUEST_URI} !^.*.png.*$ [NC]
RewriteCond %{REQUEST_URI} !^.*.bmp.*$ [NC]
RewriteCond %{REQUEST_URI} !^.*.txt.*$ [NC]
RewriteRule .* /index.php [NC,L]

Si vous ne travaillez pas sous apache, les autres serveurs disposent également les outils nécessaires pour réaliser la même choses.

Conclusion

Vous voilà désormais avec une structure de fichiers bien sécurisée. Il ne vous reste plus qu’à faire couler le café et à remplir tout ça de lignes de code.

15 commentaires »

Gravatar

Commentaire de Ahmed

le 15 mars 2008 à 13:06

Merci pour ces astuces, c’est un bon début pour s’intéresser plus à la sécurité d’une application web.

Gravatar

Commentaire de chris

le 15 mars 2008 à 23:06

Bien vu.

Gravatar

Commentaire de Séverin

le 15 mars 2008 à 23:22

Mais avec plein de fautes de frappes. Désolé…

Gravatar

Commentaire de Cyril

le 16 mars 2008 à 9:46

Bonjour,
Tres bonne article, je me suis inscris à la newletters et je ne suis pas du tout deçus du type d’article de ce blog.

Je sais à present comment bien organiser mon projet avec les repertoires et leurs chmod adequats.

tcho

Gravatar

Commentaire de Tmex

le 16 mars 2008 à 12:15

Je rajouterais aussi le principe du “pot de miel” créer un faux dossier admin avec une interface de connexion permettant de capturer les curieux et de les dirigés vers une interface bidon de les logguer et les black lister par leur ip et via un cookie .

Gravatar

Commentaire de Kaimite

le 17 mars 2008 à 11:45

Bonjour,

Merci pour les infos.

Je vais de ce pas mettre en place quelques fichiers .htaccess et modifier quelques authorisations !

@++ Kaimite

Gravatar

Commentaire de Tommy

le 17 mars 2008 à 14:47

Je ne perçois pas bien la nécessite de mettre certains dossier en dehors du dossier web (www)… Un peu plus d’explication sur ta façon de faire aurait été plus agréable je trouve.

Gravatar

Commentaire de Séverin

le 17 mars 2008 à 21:07

Ha oui, c’est vrai que j’ai pas été très clair là dessus.

En fait, le répertoire ‘www’ est le seul dont le contenu soit accessible depuis internet. Tout ce qu’on met ailleurs ne sera donc pas accessible directement mais uniquement via des scripts PHP soit par lecture/écriture soit par un include.

En faisant ainsi, tu maitrise les seuls points d’entrées de l’application et tu évites pas mal de failles possibles par l’appel direct à un fichier PHP qui ne serait pas un point d’entrée.

Gravatar

Commentaire de Kaimite

le 17 mars 2008 à 22:59

Re bonjour et encore merci pour votre tutoriel.

En cherchant un peu de mon coté je vous propose une solution sans ré-écriture d’Url.

Order allow,deny
Deny from all

Avec cette version l’utilisateur est renvoyé vers une erreur 403 (Forbidden).

Gravatar

Commentaire de Kaimite

le 17 mars 2008 à 23:01

Oupss, certaines parties ont sautée…

[FilesMatch “\.(php|asp|jsp|js|exe|bat)$”]
Order allow,deny
Deny from all
[/FilesMatch]

Remplacer [ par le signe inférieur (<) et ] par le signe supérieur (>)

Voilà ;-)

Gravatar

Commentaire de Séverin

le 17 mars 2008 à 23:12

C’est vrai que c’est plus propre comme ça et ça fonctionne même sans le mod_rewrite du coup.

Gravatar

Commentaire de hightux.net

le 21 mars 2008 à 11:59

Il me semble indispensable de parler des chmods dans un tel article, sinon c’est intérressant et primordial pour quiquonque souhaitant publié un application web.

Nico

Gravatar

Commentaire de Tommy

le 31 mars 2008 à 21:55

OK Severin pour les explications sur les dossiers ;)

Perso, j’ai plus tendance à tout mettre dans le dossier www (ou public_html selon le serveur), et à mettre des .htaccess avec la ligne : deny from all dans les dossiers que je ne veux pas qu’on accède directement. Et il n’y a aucun soucis :)

Gravatar

Commentaire de Séverin

le 31 mars 2008 à 22:09

C’est à peu près aussi valable en effet. Mais savoir que les dossiers en dessous de www sont accessibles c’est assez pratique quand tu as pas le droit aux htaccess chez ton hébergeur.

Gravatar

Pingback de L’organisation sécurisée du code « Actus Web

le 5 avril 2008 à 20:04

[…] voilà quelques astuces par Smaching Coding pour structurer son projet en prenant la sécurité en […]

Laisser un commentaire

Votre Nom

Votre E-mail (obligatoire mais ne sera pas publié)

Votre Site ou blog

Votre commentaire

Valid XHTML 1.0 Transitional