IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 :

protection contre injection shell


Sujet :

Langage PHP

  1. #1
    Membre du Club
    Femme Profil pro
    Développeur Web
    Inscrit en
    avril 2005
    Messages
    102
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2005
    Messages : 102
    Points : 59
    Points
    59
    Par défaut protection contre injection shell
    Bonjour,

    je travaille actuellement sur un projet (interne) pour lequel certaines fonctions php (type exec, system, etc) sont autorisées dans php.ini car utilisées dans le code, légitimement (essentiellement pour exécuter des scripts perl).
    Dans le même projet, il y a une fonctionnalité permettant à un utilisateur de saisir un script shell dans un textarea ; ce contenu, stocké en bdd, sera ensuite exécuté sur une machine (autre que le serveur web) donc ne peut/doit pas être trop "nettoyé".
    Devant un tel fonctionnement (qui, j'en ai bien conscience, est un trou de sécurité béant ^^), comment éviter au max les soucis de type injection php / shell / autre (quoi ?) ?
    Je n'ai jamais touché à un système aussi délibérément "ouvert" et comme on nous rabâche les oreilles à propos de sécurité au niveau hiérarchique (ce que je trouve pertinent par ailleurs ^^), je voudrais bien faire un truc propre

    l'enregistrement en bdd passe par des requêtes préparées mais ce n'est pas l'injection sql qui m'inquiète le plus dans ce cas précis

    comment m'assurer du bon fonctionnement du formulaire ? que tester / nettoyer / transformer ?
    j'ai essayé de mettre un truc du genre dans le champ et ça ne fait rien mais ça me semble léger comme vérif ^^

    merci d'avance,

    NB : il y a quand même plusieurs niveaux de protection avant d'arriver jusqu'à ce formulaire mais comme le dit notre CSSI "une chaîne a la force de son maillon le plus faible", je ne veux pas être le maillon faible

    EDIT : projet développé sur un framework maison librement inspiré de Zend et Symfony

  2. #2
    Membre émérite

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

    Informations forums :
    Inscription : mai 2008
    Messages : 1 575
    Points : 2 438
    Points
    2 438
    Par défaut
    À partir du moment où tu autorises un utlisateur à saisir un script shell dans un textarea pour l'exécuter plus tard, il n'y a pas grand-chose à faire, à part faire une liste blanche de toutes les commandes autorisées, si c'est possible.

    Autrement, il faut verrouiller l'accès avec une restriction par IP et/ou par 2FA.

  3. #3
    Membre chevronné
    Avatar de cavo789
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2004
    Messages
    1 253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mai 2004
    Messages : 1 253
    Points : 1 965
    Points
    1 965
    Par défaut
    Bonsoir

    Absolument d'accord avec Tsilefy : n'autoriser que certaines valeurs prédéfinies (principe de la liste blanche).

    En aucune manière autoriser que quelqu'un encode quelque chose car je pourrais p.ex. tenter un exec(base64_decode('BLA BLA BLA')) c'est-à-dire tenter de passer outre tes contrôles.

    Je comprends bien que ces formulaires sont strictement accessible à certains utilisateurs, que tu es sur un réseau sécurisé, etc. mais ouvrir la possibilité de taper des lignes de commandes, c'est quand même sacrément risqué.

    Dans l'hypothèse où quelqu'un encode (volontairement ou pas) un code qui va détruire des données, quel serait ta responsabilité ? Si tu réponds : on risque de me tirer l'oreille voire pire; à ta place, je ne coderais pas une telle interface.

    Ne pourrais-tu pas restreindre le risque avec une liste blanche; des scripts que tu ajouterais toi-même, que tu aurais validé, relu, etc. bref sur lequel tu aurais apposé un "OK; pas de souci" ?

    Bonne soirée.
    Christophe (cavo789)
    Mes scripts Open Source : https://github.com/cavo789

  4. #4
    Membre du Club
    Femme Profil pro
    Développeur Web
    Inscrit en
    avril 2005
    Messages
    102
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2005
    Messages : 102
    Points : 59
    Points
    59
    Par défaut
    merci pour vos réponses, je m'en doutais un peu ^^

    on avait plutôt une liste noire : certaines commandes étaient refusées mais le demandeur a dit : "c'est pas assez sécurisé" (sic) (en plus, les regex étaient foireuses et refusaient des chaines de caractères légitimes)
    la liste blanche, d'ici que les utilisateurs nous listent tout ce à quoi ils doivent accéder, on y est encore dans 3 ans...

    et on ne peut pas ne pas faire cette fonctionnalité ^^ l'appli en elle-même est un trou de sécurité de par ce qu'elle est censée faire, on le sait bien
    de même impossible de pré-valider, les scripts sont entrés par des gens dont on (l'équipe de dév de l'IHM) ne connait pas le boulot, ni pourquoi ils le font, ni comment, encore pire que la liste blanche, c'est inenvisageable

    en parallèle, sur l'appli, il y a un chantier de sécurisation des accès, avec clé de cryptage sur un support physique, faut quand même déjà arriver jusque là

    sinon, est-ce qu'il ne serait pas plutôt possible de lancer "nos" scripts perl sans passer par exec, system et tutti quanti et donc de mettre ces fonctions PHP en ignore list dans le php.ini ?

  5. #5
    Membre émérite

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

    Informations forums :
    Inscription : mai 2008
    Messages : 1 575
    Points : 2 438
    Points
    2 438
    Par défaut
    Tu as 2 soucis donc. Le textarea est insurmontable (en tout cas dans PHP). Mieux vaut blinder les permissions d'accès.

    Le lancement de scripts perl, ça dépend. Quelles sont les conditions de déclenchement de ces scripts? Est-ce que c'est automatique ou il faut une action humaine / extérieure au serveur? Est-ce que exec reçoit le nom du script grâce à des inputs utilisateurs?

  6. #6
    Membre éprouvé
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2009
    Messages
    552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mars 2009
    Messages : 552
    Points : 1 060
    Points
    1 060
    Par défaut
    Bonjour,

    Citation Envoyé par Elianora la blanche Voir le message
    Je n'ai jamais touché à un système aussi délibérément "ouvert" et comme on nous rabâche les oreilles à propos de sécurité au niveau hiérarchique (ce que je trouve pertinent par ailleurs ^^), je voudrais bien faire un truc propre
    Il y a pourtant pas mal de système de systèmes qui permettent in-fine d'exécuter des scripts shell utilisateur sans nettoyage :

    - Les systèmes qui te permettent de créer une VM en ligne
    - Les éditeurs de code en ligne permettant l'exécution (ex : https://repl.it/repls/LovableBurlyFlatassembler)
    - Les outils d'intégration continue (jenkins, Travis CI, etc.)
    - Les outils de déploiement (puppet server, chef server, etc.)
    - ...

    Niveau sécurité, je vois globalement deux stratégies sur ces outils :

    - Restriction de l'environnement d'exécution (droit utilisateur restreint, isolation réseau, etc.)
    - Restriction des utilisateurs autorisés à exécuter ces scripts (avec éventuellement des mécanismes de validation)

    La base pour choisir la bonne stratégie, ça va être de commencer par répondre à la question : A quoi servent ces scripts bash?

    Si tes scripts doivent permettre à quelques utilisateurs de supprimer des fichiers, tu ne sécuriseras pas de la même façon que si tes scripts doivent uniquement permettre à de nombreux utilisateurs de faire des analyses sur le contenu de ces fichiers.

    Plus globalement, je t'inviterais bien à parcourir les principes de la méthode EBIOS qui oblige à prendre du recul pour bien "identifier les événements redoutés" afin de définir les bonnes "mesures de sécurité" (en bonus, niveau hiérarchie, un cadre ça rassure)

  7. #7
    Membre du Club
    Femme Profil pro
    Développeur Web
    Inscrit en
    avril 2005
    Messages
    102
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2005
    Messages : 102
    Points : 59
    Points
    59
    Par défaut
    le principe de l'appli est de récupérer des config de machines distantes (et faire qq autres trucs), bcp d'utilisateurs y ont accès et peuvent faire pas mal de choses (c'est pour ça que c'est très "ouvert")

    typiquement, les scripts shell que les utilisateurs vont saisir seront une liste de cat, grep, etc
    et les scripts perl permettent grosso modo de contacter lesdites machines pour lancer ces scripts shell (y aussi de l'envoi de mail et du traitement de données provenant de la base, je sais pas pourquoi c'est fait en perl et pas en php mais je vais pas le changer, pas le temps)
    certains sont lancés sur action utilisateur sans paramètre saisi manuellement, certains avec et certains sont lancés automatiquement (cron)
    bref un joyeux bazar quand même

    y a aussi 2-3 exec qui servent à manipuler des fichiers sur le serveur web lui-même (déplacement dans l'arbo, déplacement de fichiers, archivage) => ça, il est probablement possible de le faire avec des fonctions php et sans exécuter du shell
    mais c'est un gros chantier donc ça prend du temps, donc ça coûte de l'argent, donc on le fera pas (enfin, vous voyez le genre "on veut tout pour rien" ^^)
    le blindage d'accès est déjà en place et on va en ajouter une couche

    cela dit, je pense qu'il y a une vraie réflexion à mener par rapport à ça et pas juste mettre en place une mini protection sur les 2 textareas concernés (même si, bien sûr, c'est ça que les utilisateurs voient et pas tout ce qui est derrière) ^^

    je vais déjà essayer de n'utiliser qu'une seule fonction "système", ça permettra de virer les autres (ça change pas fondamentalement le truc, mais ça forcera les futurs développeurs à se demander pourquoi c'est bloqué)

  8. #8
    Membre éprouvé
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2009
    Messages
    552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mars 2009
    Messages : 552
    Points : 1 060
    Points
    1 060
    Par défaut
    Citation Envoyé par Elianora la blanche Voir le message
    cela dit, je pense qu'il y a une vraie réflexion à mener par rapport à ça et pas juste mettre en place une mini protection sur les 2 textareas concernés (même si, bien sûr, c'est ça que les utilisateurs voient et pas tout ce qui est derrière) ^^
    C'est se poser réellement la question du "autre" à côté des injections sql et php :

    - Accès à des données sensibles
    - Corruption des données de la base
    - Corruption des données du serveur
    - Installation d'une backdoor
    - Envoi d'un email d'insulte aux clients
    - ...

    Après, tout comme tu fais des requêtes préparées pour éviter des injections SQL, tu proposes des mesures en face des risques :

    - S'assurer que l'on a bien une traçabilité sur les scripts
    - Faire valider les scripts par un administrateur
    - Compte spécial pour les accès à la base de données (lecture seule, pas d'accès aux tables sensibles, etc.)
    - Restriction de l'environnement d'exécution des scripts (droits sur les fichiers, chroot)
    - Distinguer deux fonctions dans l'application : ajouter un script en décrivant ses paramètres et exécuter un script avec des paramètres
    - Compiler les bash en PHP pour autoriser seulement une liste de commandes autorisées :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    <command1> <param1> <param2> ...
    <command2> <param1> <param2> ...
    # moins trivial si tu dois gérer des if...
    - ...

    Dès lors, choisir si on met en place telle ou mesure en fonction du coût ou de l'impact (système moins ouvert, utilisateurs qui doivent attendre des validations,...), ça revient à celui qui doit choisir d'assumer ou non le risque...

Discussions similaires

  1. [PHP 5.4] protection contre injection sql et xss
    Par sinifer dans le forum Langage
    Réponses: 8
    Dernier message: 07/05/2013, 19h31
  2. Protection contre les SQL Injections ?
    Par kedare dans le forum JDBC
    Réponses: 9
    Dernier message: 05/05/2010, 11h42
  3. Script de protection contre l'injection SQL
    Par mabrouk1987 dans le forum Général JavaScript
    Réponses: 5
    Dernier message: 10/12/2009, 09h52
  4. [MySQL] Protection contre les injections
    Par hafcher dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 19/06/2008, 21h35
  5. Formulaire et protection contre injection
    Par Overstone dans le forum Langage
    Réponses: 11
    Dernier message: 09/08/2007, 18h46

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