2009-08-31 5 views
0

Je développe une application PHP que je prévois de vendre et de distribuer. Je veux contrôler qui a accès aux fonctions principales et à l'installation des applications via une sorte d'appel à mon serveur, qui vérifie si l'emplacement d'installation du script (example.com) se trouve dans une base de données, voire vérifie une clé de licence de quelque sorte.Comment sécuriser un produit PHP en utilisant btcompiler et les clés de licence?

  1. Quelqu'un at-il des directives générales pour sécuriser un programme PHP distribué? Je ne m'attends pas à une sécurité totale, mais je voudrais lancer le script avec un essai, et je voudrais décourager la personne moyenne de modifier le code pour essayer de contourner l'achat du script. J'avais deux idées en tête - avoir un script "phone home" avec l'adresse du serveur de script, et vérifier cette adresse par rapport à une base de données (assez simple), ou en plus de générer une sorte de clé de licence et coder en dur cette clé dans le script, soit dans un fichier, soit dans les requêtes d'installation de base de données.

Ma question est, si je vais cette dernière voie (codage en dur), quel est le moyen le plus efficace de coder en dur une clé dans un script lors de l'exécution et le package tout dans un fichier zip unique?

  1. J'utiliserais bcompiler pour tenter d'obfusciter les fonctions d'authentification utilisées ci-dessus. Je sais que vous avez besoin de support pour bcompiler compilé en PHP afin de écrire bytecode, mais y at-il des exigences spéciales à exécuter compilé bytecode? Mon application fonctionnera sur une variété de machines, mais avec la condition commune qu'elles exécuteraient toutes PHP5, donc le code doit être capable de fonctionner sur des environnements d'hébergement restrictifs (où ils ne peuvent pas télécharger des bibliothèques externes tertiaires PHP, par exemple).

Répondre

3

Jeter un oeil à ces questions/réponses pourraient vous aider au moins un peu:

Il ne sera pas pleinement répondre à vos questions, mais pourrait encore se révéler utile :-)


encore, mon idée principale serait que votre problème est plus un problème juridique que toute autre chose: si vos clients veulent vous voler, ils ne sont probablement pas les clients vous devriez essayer de garder ... La chose la plus importante à faire serait probablement d'avoir un contrat solide avec vos clients, qui définissent ce qu'ils peuvent, et ne peuvent pas faire; il y aura toujours des gens qui essaieront d'arroger la «protection» que vous pourrez mettre en place - et ils réussiront très probablement de toute façon ...

Si vous voulez vous lancer dans ce genre d'affaires, vous devrez obtenir un bon CLUF; C'est plus une affaire juridique que technique, et vous aurez certainement besoin de l'aide de quelqu'un dont le travail est sur le plan juridique.
Toujours, en passant par le CLUF à partir des applications/sites Web que vous utilisez peut vous donner quelques indications.


En sidenote: l'idée « de la maison d'appel »: assurez-vous que, si votre « maison » site/application est en baisse (cela arrivera, un jour ou d'une autre), il ne met pas sur tous les sites Web sur lesquels votre application a été déployée - Je suis sûr que vos clients ne l'aimeraient pas ^^

Aussi: assurez-vous que le fait que votre logiciel «appelle à la maison» de temps en temps est clairement indiqué quelque part dans la documentation/CLUF: si vos clients découvrent par eux-mêmes que votre application répond à des demandes de réseau pour lesquelles ils n'ont pas adhéré, cela sera mauvais pour vos relations publiques.

Et: Je l'ai vu (plusieurs fois) applications déployées sur des serveurs configurés de sorte qu'ils ne pouvaient pas faire la demande à l'extérieur du réseau d'une entreprise (ils disent « raisons de sécurité » ou des trucs comme ça) - - il n'y a pas grand-chose à faire dans ce genre de situation, je suppose ...
Une autre approche serait de ne pas distribuer une application, mais de fournir un service: ne vendez pas l'application elle-même, mais l'hébergez et vendez services - c'est ce que font de nombreuses entreprises (par exemple: google, avec gmail ou google docs, bur il y a tellement d'autres exemples), et si le service est génial, il peut très bien fonctionner.

Je dois ajouter que cela vous donne une plus grande capacité pour les mises à jour pour corriger les problèmes plus rapidement, pour insatnce, ou tout simplement ajouter de nouvelles fonctionnalités ... Et vous avez le contrôle sur qui peut utiliser l'application ;-)

Thie Le plus gros problème avec cette idée est que votre application ne doit connaître (presque) aucun temps d'arrêt: vous devez trouver un excellent service d'hébergement, créer des sauvegardes, être réactif, capable de résoudre rapidement des problèmes, ... Pas facile non plus!

+0

Merci pour vos commentaires - ma relation avec les gens qui achèteraient mon script n'est pas comme un type de fournisseur-client, où je peux demander un contrat, je viens projeter de vendre le script à n'importe quel nombre de personnes, comme n'importe quel autre article. Je ne suis pas trop préoccupé par les problèmes juridiques concernant mon code - si quelqu'un veut pirater mon code, je ne peux pas les arrêter. Je veux juste décourager le client moyen d'essayer de se mêler du système d'authentification. –

+0

@Andrew: OK; Si vous comprenez que vous ne pouvez pas les empêcher de faire le mal, mais seulement les ralentir/rendre les choses plus difficiles, c'est vraiment une bonne chose. –

0

Pourquoi ne proposez-vous pas une solution hébergée? C'est ce que proposent la plupart des startups, etc. Cela signifie aussi que vous pouvez soulager la douleur des mises à jour, etc.