Discussion :

[scamphp]

Bonjour a tous.

Pour sécuriser mon site, j'ai créé un dossier racine ou pointe mon site internet (index.php)

et mes script sont un niveau au dessus

- prive -> le_vrai_index.php et dossiers et mes fonctions
- public -> racine / index.php

D'après ce que j'ai compris le fait de mettre ses fichiers et fonctions un niveau au dessus de la racine les rends inexploitables depuis l'extérieur.

Pouvez vous me confirmer que j'ai bien compris et que c'est une bonne pratique.


Une autre questions faut-il éviter de donner des noms génériques a ses fichiers du style : root.php admin.php
S'ils sont a la racine je pense qu'il faut éviter, mais s'ils sont dans un dossier au dessus je me demande si c'est utile ????

Ou en cas de faille -> ../admin.php risque aussi d être exploitable

C'est peut être pas très clair, mais j'espère que vous comprenez ce que je veux dire dans l'esprit.

Pour se prémunir faut savoir comment ça marche... mais comme je n'ai pas le niveau d'exploiter mes failles... je ne sais pas faire la différence être l'utile et le superflus...

Merci pour votre aide... et si vos réponses sont pédagogiques c'est encore mieux.

[Tsilefy]

D'après ce que j'ai compris le fait de mettre ses fichiers et fonctions un niveau au dessus de la racine les rends inexploitables depuis l'extérieur.

Ils ne sont pas directement exploitable et sont invisibles, ce qui est déjà un très bon point. Mais tout dépend de la sécurité de ton index.php dans public. S'il a une vulnérabilité, on peut s'en servir pour accéder à tout le reste.

Pouvez vous me confirmer que j'ai bien compris et que c'est une bonne pratique.

Oui, et c'est une bonne pratique.

Une autre questions faut-il éviter de donner des noms génériques a ses fichiers du style : root.php admin.php

C'est de la sécurité par l'obscurité, ça n'a pas vraiment d'intérêt (ça donne une certaine défense en profondeur, mais bon le gain n'est pas important) car l'attaquant testera de toutes façons toutes les attaques possibles sur tous les fichiers qu'il peut atteindre, quel que soit le nom du fichier.

C'est surtout recommandé lorsqu'on utilise des CMS comme Wordpress, Drupal ou Joomla et qu'on est dans un hébergement mutualisé où tous les fichiers sont dans un répertoire public donc directement accessibles, et qui dont les noms des fichiers sont toujours les mêmes. Lorsque des fichiers de ces CMS ont des vulnérabilités, il existe des robots qui scannent automatiquement tous les sites à la recherche du fichier vulnérable afin de les exploiter. Dans ce cas, renommer le fichier, modifier l'URL de l'admin etc... peuvent avoir un intérêt.

Dans tous les cas, l'idéal c'est de ne pas avoir de vulnérabilités en maîtrisant les différentes failles possibles et comment les éviter; et comme on ne parvient pas toujours à écrire un code sans défaut, il faut utiliser un bon parefeu bien configuré, ou un dispositif comme modSecurity.

[scamphp]

Clair, net précis j'adore.... merci

Je suppose que c'est la même chose pour le nom des variables ?

C'est de la sécurité par l'obscurité, ça n'a pas vraiment d'intérêt (ça donne une certaine défense en profondeur, mais bon le gain n'est pas important) car l'attaquant testera de toutes façons toutes les attaques possibles sur tous les variables qu'il peut atteindre, quel que soit le nom de la variable.

[grunk]

Pour les variables c'est encore moins utile et c'est même pas recommandé puisque ça va te rendre le développement compliqué.
Il existe des obfuscateurs qui font ce genre de chose pour toi mais en PHP l'intérêt est limité à certains cas très particulier. On les utilise plus en javascript où le code source est directement disponible à tout le monde.

Concernant les nom de fichier , un serveur web bien configuré , qui empèche de lister le contenu du dossier est bien plus efficace par exemple.

Les points que tu abordes doivent en effet être pris en compte , mais il sont plutôt la deuxième barrière quand l'attaquant à déjà pénétré le système.
Concentre toi plutôt sur :
- Les injections SQL
- La validation des données saisie
- Les failles courantes type XSS et CSRF

[Celira]

Concentre toi plutôt sur :
- Les injections SQL
- La validation des données saisie
- Les failles courantes type XSS et CSRF

Je confirme : un attaquant ne va pas s'embêter à aller éplucher le code source, si mettre admin et ' OR 1='1 dans le formulaire de login lui permet d'accéder à toute l'application.

[scamphp]

J'ai pour habitude aussi de faire dans l'index

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
if ( ! defined( 'URL' ) ) {
 
	define( 'URL', dirname( __DIR__ ) );

Puis dans chaque fichier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if ( !defined( 'URL' ) ) exit ();

Pour vérifier que le fichier est bien appelé par l'index

Vous allez me dire que c'est inutile aussi ???


On me dit souvent que j’enfile 3 slips et que cela ne sert a rien

[cavo789]

Bonjour

Vous allez me dire que c'est inutile aussi ???

Un très grand nombre de programmes font cela et je trouve ça particulièrement sain et propre. Le CMS Joomla avec son JExec p.ex.; lire https://docs.joomla.org/JEXEC/fr, je pense aussi à LimeSurvey (outil d'enquêtes en ligne), ...

Si tu as des fichiers .php qui n'ont, strictement, aucune raison d'être appelé en URL; faire ce que tu fais ajoute une jolie couche de protection d'une part et clarifie la logique qui est la tienne et, toutes personnes qui lire ton code, saura immédiatement qu'il s'agit d'un script non exécutable en accès direct.

Conserve donc cette façon de faire; c'est une très bonne chose; même en dehors du plan strict de la sécurité.

Concernant le fait de mettre tes fichiers en dehors d'un dossier accessible par URL; là aussi, c'est une bonne chose et ici encore d'autres systèmes font ainsi. Par exemple, le framework Laravel où, en principe, seul le dossier nommé public est supposé accessible. Les autres dossiers contiennent les classes, les helpers, les accès DB, qui doivent rester en dehors du champs d'actions des URLs.

Remarque : veille bien que le dossier où tu places ton code "non accessible" soit bien accessible par code. Je pense à la clause open_basedir de PHP qui permet de définir quels sont les dossiers qui peuvent être accédé; p.ex. avec des require_once(). Si ton dossier au-dessus de ton dossier principal est non accessible dû à une sécurisation open_basedir; tu auras une erreur fatale.

Bonne soirée

[scamphp]

Si

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ( !defined( 'URL' ) ) exit ();

est utile c'est contradictoire avec le fait de dire que les fichiers au dessus de la racine sont protégés...

OU

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ( !defined( 'URL' ) ) exit ();

n'est utile que pour les fichiers dans public

et inutile dans les fichiers au dessus de la racine

[cavo789]

Selon ton hébergeur, tu pourrais ne pas avoir le droit de placer des fichiers au-dessus de la racine de ton site web aussi, dans ce cas-là, l'instruction est utile.

Ensuite, cela reste une excellente pratique à conserver. Peut-être qu'un jour tu vas réutiliser ton code ou le mettre à disposition d'autrui et là, tu ne pourras pas savoir ce qu'il en est fait.

Cela ne coûte vraiment rien de prévoir cette ligne et, comme je l'ai mentionné, cela permet à quiconque qui lire ton code de savoir que tel fichier n'est pas exécutable en direct. Sans se prendre la tête et de lire son contenu.

Donc, oui, je te conseille personnellement de conserver cette protection-là qui, soyons pragmatique, ne coûte que quelques secondes d'implémentation ;-)

Bonne soirée

[Tsilefy]

Il existe une bien meilleure méthode que de devoir ajouter if(defined) à chaque page, au risque de l'oublier et de risquer la catastrophe: il faut éviter de mettre du code exécutable directement dans les fichiers php. Les fichiers *.php ne doivent contenir que des fonctions ou des classes et seuls quelques fichiers (index.php) sont directement exécutables.

[scamphp]

Dans la série des protections serait-il intéressant que le serveur pointe (exécute) un fichier machin.php plutôt que index.php (comme cela tu peux toujours chercher mon index... il n'existe pas)

OU cela ne sert a rien ???

[cavo789]

Il existe une bien meilleure méthode que de devoir ajouter if(defined) à chaque page, au risque de l'oublier et de risquer la catastrophe: il faut éviter de mettre du code exécutable directement dans les fichiers php. Les fichiers *.php ne doivent contenir que des fonctions ou des classes et seuls quelques fichiers (index.php) sont directement exécutables.

Absolument d'accord mais ce n'est pas toujours le cas : si tu regardes un CMS, tu as p.ex. la définition des vues (views) qui sont des fichiers .php à part entière n'ayant qu'une portion de code; l'écriture d'une portion de la page web p.ex. Dans ce type de fichiers, point de classes mais immédiatement du code exécutable.

Joomla en est un exemple.

Bonne soirée.

[Tsilefy]

Absolument d'accord mais ce n'est pas toujours le cas : si tu regardes un CMS, tu as p.ex. la définition des vues (views) qui sont des fichiers .php à part entière n'ayant qu'une portion de code; l'écriture d'une portion de la page web p.ex. Dans ce type de fichiers, point de classes mais immédiatement du code exécutable.

Joomla en est un exemple.

Bonne soirée.

D'accord. Quand on utilise un CMS, on doit s'adapter au fonctionnement du CMS.

[Tsilefy]

Dans la série des protections serait-il intéressant que le serveur pointe (exécute) un fichier machin.php plutôt que index.php (comme cela tu peux toujours chercher mon index... il n'existe pas)

OU cela ne sert a rien ???

Pff, franchement ça ne sert à rien. S'il s'agit de tentatives d'intrusions, les seuls à te protéger efficacement sont un firewall et/ou modsecurity (ou similaires) et/ou un site sécurisé (ne jamais faire confiance à tout ce qui est envoyé de l'extérieur (GET, POST), ne pas faire confiance aux javascript hébergés ailleurs, utiliser des requêtes préparées pour la base de données, utiliser des méthodes de chiffrements efficaces....). Si l'intrus est déjà dans ton serveur, c'est déjà game over, il n'y a rien à faire sauf tout détruire et reconstruire à partir d'une sauvegarde saine.