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