Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage PHP Discussion :

Sécurité coté programmation


Sujet :

Langage PHP

  1. #1
    Membre régulier
    Homme Profil pro
    Urbaniste
    Inscrit en
    mai 2018
    Messages
    184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Urbaniste

    Informations forums :
    Inscription : mai 2018
    Messages : 184
    Points : 81
    Points
    81
    Par défaut Sécurité coté programmation
    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.

  2. #2
    Membre émérite

    Profil pro
    Inscrit en
    mai 2008
    Messages
    1 574
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 1 574
    Points : 2 440
    Points
    2 440
    Par défaut
    Citation Envoyé par scamphp Voir le message

    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.
    Citation Envoyé par scamphp Voir le message
    Pouvez vous me confirmer que j'ai bien compris et que c'est une bonne pratique.
    Oui, et c'est une bonne pratique.

    Citation Envoyé par scamphp Voir le message
    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.

  3. #3
    Membre régulier
    Homme Profil pro
    Urbaniste
    Inscrit en
    mai 2018
    Messages
    184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Urbaniste

    Informations forums :
    Inscription : mai 2018
    Messages : 184
    Points : 81
    Points
    81
    Par défaut
    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.

  4. #4
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    5 508
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 5 508
    Points : 14 807
    Points
    14 807
    Par défaut
    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
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Modératrice
    Avatar de Celira
    Femme Profil pro
    Développeuse PHP/Java
    Inscrit en
    avril 2007
    Messages
    8 407
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Développeuse PHP/Java
    Secteur : Industrie

    Informations forums :
    Inscription : avril 2007
    Messages : 8 407
    Points : 15 959
    Points
    15 959
    Par défaut
    Citation Envoyé par grunk Voir le message
    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.
    Modératrice PHP
    Aucun navigateur ne propose d'extension boule-de-cristal : postez votre code et vos messages d'erreurs. (Rappel : "ça ne marche pas" n'est pas un message d'erreur)
    Cherchez un peu avant poser votre question : Cours et Tutoriels PHP - FAQ PHP - PDO une soupe et au lit !.

    Affichez votre code en couleurs : [CODE=php][/CODE] (bouton # de l'éditeur) et [C=php][/C]

  6. #6
    Membre régulier
    Homme Profil pro
    Urbaniste
    Inscrit en
    mai 2018
    Messages
    184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Urbaniste

    Informations forums :
    Inscription : mai 2018
    Messages : 184
    Points : 81
    Points
    81
    Par défaut
    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

  7. #7
    Membre éprouvé
    Avatar de cavo789
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2004
    Messages
    830
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mai 2004
    Messages : 830
    Points : 1 035
    Points
    1 035
    Par défaut
    Bonjour

    Citation Envoyé par scamphp Voir le message
    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
    Christophe (cavo789)
    Logiciel gratuit de scan antivirus : https://github.com/cavo789/aesecure_quickscan
    Mes logiciels OpenSource : https://www.avonture.be

  8. #8
    Membre régulier
    Homme Profil pro
    Urbaniste
    Inscrit en
    mai 2018
    Messages
    184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Urbaniste

    Informations forums :
    Inscription : mai 2018
    Messages : 184
    Points : 81
    Points
    81
    Par défaut
    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

  9. #9
    Membre éprouvé
    Avatar de cavo789
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2004
    Messages
    830
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mai 2004
    Messages : 830
    Points : 1 035
    Points
    1 035
    Par défaut
    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
    Christophe (cavo789)
    Logiciel gratuit de scan antivirus : https://github.com/cavo789/aesecure_quickscan
    Mes logiciels OpenSource : https://www.avonture.be

  10. #10
    Membre émérite

    Profil pro
    Inscrit en
    mai 2008
    Messages
    1 574
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 1 574
    Points : 2 440
    Points
    2 440
    Par défaut
    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.

  11. #11
    Membre régulier
    Homme Profil pro
    Urbaniste
    Inscrit en
    mai 2018
    Messages
    184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Urbaniste

    Informations forums :
    Inscription : mai 2018
    Messages : 184
    Points : 81
    Points
    81
    Par défaut
    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 ???

  12. #12
    Membre éprouvé
    Avatar de cavo789
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2004
    Messages
    830
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mai 2004
    Messages : 830
    Points : 1 035
    Points
    1 035
    Par défaut
    Citation Envoyé par Tsilefy Voir le message
    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.
    Christophe (cavo789)
    Logiciel gratuit de scan antivirus : https://github.com/cavo789/aesecure_quickscan
    Mes logiciels OpenSource : https://www.avonture.be

  13. #13
    Membre émérite

    Profil pro
    Inscrit en
    mai 2008
    Messages
    1 574
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 1 574
    Points : 2 440
    Points
    2 440
    Par défaut
    Citation Envoyé par cavo789 Voir le message
    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.

  14. #14
    Membre émérite

    Profil pro
    Inscrit en
    mai 2008
    Messages
    1 574
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 1 574
    Points : 2 440
    Points
    2 440
    Par défaut
    Citation Envoyé par scamphp Voir le message
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Android] Besoin d' aide - Sécurité en programmation android
    Par Ado_88 dans le forum Mon application mobile
    Réponses: 0
    Dernier message: 16/09/2014, 10h27
  2. Sécurité coté client - WCF
    Par FrancisT dans le forum Windows Communication Foundation
    Réponses: 6
    Dernier message: 24/02/2012, 17h27
  3. Sécurité sur programme Shell
    Par coincoin22 dans le forum Linux
    Réponses: 9
    Dernier message: 30/08/2007, 19h07
  4. [Cgi] Sécurité du Programme c
    Par ankou82 dans le forum C
    Réponses: 19
    Dernier message: 14/06/2006, 10h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo