Comment déboguer une application Web PHP en toute sécurité sans dévoiler de secrets aux concurrents?

Récemment, j'ai fait un programme. J'ai oublié de supprimer 2 lignes de codes. Cette erreur m'a coûté 800 $ par jour chaque jour.

Je programmais avec PHP. Si un visiteur utilise un proxy, il redirige ailleurs. L'utilisation du débogueur était impossible car certains codes contiennent ioncube. Parce que le programme redirige simplement ailleurs, peu importe quoi, il est difficile de voir quelle partie du code est exécutée.

J'ai donc mis un tas d'informations de débogage partout. Je pensais que je les supprimerais de toute façon.

Le moyen le plus naturel de déboguer est bien sûr de mettre des informations de débogage dans un fichier. Le problème est que j'utilise souvent un proxy. Donc, après avoir changé de programme, je dois souvent télécharger le fichier texte avec filezilla. Souvent, le fichier texte ne montre pas ce que je pense qu'il devrait montrer. Enfin, j'ai décidé d'afficher simplement les erreurs sur le Web.

J'ai envisagé d'avoir un mode de débogage. Cependant, j'ai peur d'oublier de supprimer les informations de débogage.

J'ai envisagé d'avoir le mode de débogage si l'utilisateur le faisait? Debuggingmode = 1 par exemple. Cependant, j'étais paranoïaque que mon concurrent puisse deviner le mot-clé secret.

J'ai supprimé la plupart des informations de débogage. J'oublie d'en supprimer un et celui-ci n'apparaît que si les utilisateurs utilisent un proxy du bon pays. Il s'avère que je n'ai pas de mandataire du bon pays et je ne m'en suis pas rendu compte. Après que le programme fonctionne pendant 24 heures, je l'ai téléchargé sur mon domaine principal.

Mon concurrent, en utilisant un proxy, voir le code de débogage. Il copie l'idée et c'est comme ça que j'ai perdu 800 $ par jour.

Rétrospectivement, j'ai vraiment du mal à voir où je me suis trompé. J'ai été super prudent. Pourtant, c'est arrivé.

Comment déboguer une application Web PHP en toute sécurité sans dévoiler de secrets aux concurrents?

J'ai vraiment du mal à voir où je me suis trompé

L'erreur majeure a été de réinventer la roue. Au lieu d'utiliser des mécanismes par défaut pour la journalisation, vous avez inventé le vôtre , qui affiche les informations dans la page. Un cadre de journalisation préfère stocker les journaux dans des fichiers journaux, vous permettant de consulter ces journaux ultérieurement par SSHing sur le serveur.

Quant aux bogues, produire du code sans bogue implique l'utilisation de techniques spécifiques telles que la preuve formelle . Compte tenu de leur coût élevé, ces techniques conviennent aux applications vitales telles que les applications qui contrôlent le trafic aérien ou les navettes spatiales, mais sont une surpuissance pour presque toutes les applications commerciales.

■ Voir Ils écrivent les bons articles dans le magazine Fast Company.
_{L'article décrit la méthodologie utilisée à la NASA, ainsi que le coût de production de logiciels de cette façon.}

■ Voir Mécanisation de la preuve (Mackenzie 2004).
_{Le livre résume l'histoire de la preuve de logiciel automatisée, expliquant les avantages et les inconvénients d'une telle preuve, ainsi que les raisons pour lesquelles elle n'est pas couramment utilisée par les entreprises pour écrire des logiciels fiables.}

Cela étant dit, il existe un tas de techniques utilisées pour les applications commerciales pour assurer la qualité des logiciels. Cela comprend, mais sans s'y limiter:

• Revues informelles du code,
• Inspections formelles du code,
• Essai,
• Vérification personnelle du code,
• etc.

■ Voir Code complete (McConnell 2004), Programming Productivity (Jones 1986a), Software Defect-Removal Efficiency (Jones 1996) et What We Learned About Fighting Defects (Shull et al. 2002).

N'oubliez pas non plus l'intégration et la livraison continues. Il aide à faire reculer automatiquement l'application en production vers une version de travail lorsqu'une version révisée semble avoir un problème qui a été manqué lors des révisions de code et des tests unitaires, mais a été détecté une fois l'application déployée.

■ Voir Le secret du déploiement continu sécurisé (vidéo)
_{Il explique quelles techniques ont été mises en place chez Google pour éviter que les bogues introuvables avant le déploiement ne restent trop longtemps en production. Il décrit également pdiffcomment il a été utilisé pour intercepter les bogues, y compris ceux qui n'étaient pas liés à la couche de présentation.}

Vous ne devez jamais déboguer en production.

Vous devez toujours avoir un environnement de test identique à l'environnement de production et y déboguer.

Lorsque vous devez modifier du code dans l'environnement de test (comme pour ajouter des instructions de débogage), vous devez vous assurer qu'elles ne passent pas en production.

Une configuration professionnelle ressemble généralement à ceci:

Production
   ^
Staging
   ^
Development

Les instances "Production", "Staging" et "Development" de votre application doivent être aussi identiques que possible afin qu'un bogue qui se produit dans "Production" puisse être reproduit dans "Staging" et "Development", mais toujours complètement séparé de les uns des autres afin que tout ce qui se passe dans l'une des instances n'affecte pas les autres.

Lorsque vous devez analyser un problème, vous le faites dans "Développement". Jouez avec les instructions de débogage et expérimentez tout ce que vous voulez. Lorsque vous avez trouvé une solution, vous appliquez ce correctif à la base de code inchangée dans «Staging» et vérifiez que le correctif fonctionne. Ensuite, vous faites la promotion du correctif en "Production".

Un bon contrôle de version et un système de gestion de build peuvent vous y aider.

Cela se fait rarement car l'effort n'en vaut pas la peine. Même si vous perdez 800 $ par jour, l'effort de prouver un programme correct devient rapidement plus important que cela, ce qui implique qu'il n'y a pas de justification commerciale pour le faire.

Si être certain est une valeur beaucoup (par exemple pour le logiciel ou le contrôle des missiles navette spatiale), vous effectuez une vérification formelle, d' essais exhaustifs de toutes les entrées possibles, etc. Certes, il est extrêmement difficile , ainsi que lent et coûteux. Mais les projets avec des budgets d'un milliard de dollars ont également tendance à avoir des gens extrêmement brillants. (Ou peut-être qu'ils le faisaient auparavant - les titres actuels semblent contredire cette règle.)

Parfois, vous devez déboguer un système en direct. Oui, vous devriez avoir une copie de développement ou de mise en scène. Mais il y aura toujours des différences. Cela est particulièrement vrai si le code s'épuise à l'état sauvage sur le matériel du client. Ou potentiellement, de nombreuses installations client différentes.

J'ai utilisé la technique & debugging = 1 dans le passé. Je soupçonne que la plupart des développeurs PHP l'ont fait. Cela a inversé un commutateur dans le code qui a permis un débogage plus détaillé dans l'application. Ces informations sont généralement sauvegardées dans un fichier journal - généralement le journal Apache (en utilisant error_log ()). Mais, vous pouvez également le sortir. Notre profileur, par exemple, collecterait des informations, puis afficherait les différents repères en bas de la page. Vous pouvez également générer les informations de débogage sous forme de commentaire HTML ou dans un élément masqué qui n'est visible que si vous affichez la source de la page.

Si votre site a des «utilisateurs», vous pouvez limiter le débogage à un seul utilisateur particulier. De cette façon, si quelqu'un essaie d'activer le débogage, il ne fonctionnera toujours pas sauf s'il est connecté en tant qu'utilisateur.

Maintenant, vous avez mentionné que vous utilisiez FileZilla pour vous connecter au serveur. Un développeur devrait vraiment avoir un accès SSH au serveur. Cela vous facilitera le débogage. Par exemple, si vous deviez sortir vos instructions de débogage dans le journal des erreurs Apache, par exemple, vous pourriez facilement récupérer ce fichier pour votre adresse IP et voir les informations de débogage générées par votre dernière demande de page.

Tout le monde a déjà couvert le cas général:

Validation formelle (/ Code éprouvé): impossible pour les programmes du monde réel, bien qu'il existe un système d'exploitation de 4000 lignes, qui a été officiellement prouvé, il a fallu de nombreux mois à de nombreux étudiants russes CS PhD (veuillez commenter si vous vous souvenez du nom de ce projet)

Test CI << Test automatisé << Test : assurez-vous d'utiliser un outil de couverture pour vérifier que vos cas de test ont une couverture à 100%.

Pour votre cas spécifique de laisser le code de débogage en production, j'ai 2 options, les deux nécessitant que le code source soit recompliqué dans le cadre du déploiement vers un nouvel environnement (Staging / Final Testing).

1. Retirez-le au moment de la compilation. Enveloppez le code de débogage dans des structures comme C # et C #ifdef DEBUGpour vérifier la cible de génération (débogage ou libération) et pour les supprimer automatiquement au moment de la compilation.

2. Marquez-le au moment du déploiement. Mettez un commentaire près du code qui ne doit pas être exécuté dans l'environnement réel. Par exemple //TODO: Remove This Before Deployment, puis lorsqu'il est migré (déployé) vers Staging, avant de compiler le code, exécutez-le via un script simple qui vérifie qu'il ne reste aucun commentaire d'indicateur (par exemple //TODO:) dans le code source.

Je suggère le premier pour s'il est à long terme et que vous le voudrez à nouveau (par exemple, le mode de journalisation détaillé), et le dernier si c'est un hack rapide pendant que vous déboguez (par exemple, divers printfs dispersés dans votre code)

Comme d'autres l'ont dit avant moi, de nombreux tests (unitaires et fonctionnels), si possible automatisés et avec une bonne couverture de code, sont la clé pour avoir un logiciel essentiellement sans bug.

Si je comprends assez bien la description de votre problème, les informations de débogage sont affichées sur la page desservie par votre serveur. Si tel est le cas, vous devriez envisager de mettre ces informations dans les journaux appropriés sur votre serveur. De cette façon, il n'est jamais montré à l'utilisateur final, même si vous déployez une version «verbeuse» en production. C'est quelque chose de bien à faire quel que soit le projet sur lequel vous travaillez, sauf si vous avez de très bonnes raisons de faire autrement.

Ce que les autres disent du débogage en production est juste. Mais je l'ai fait parfois de toute façon. Et je pense qu'il existe des moyens plus sûrs de le faire que le vôtre, bien que rien ne soit infaillible.

Je n'ai pas besoin d'une telle sécurité moi-même, je ne veux simplement pas que les utilisateurs voient un tas de charabia sur leurs écrans.

$debug = true;
$allowed_ips = array('192.168.0.220','173.46.89.255'); // limit to your own ip's. If your competitor knows them, though, he can spoof it! But if your stuff is not top secret, it's ok. 

if(!in_array($_SERVER['REMOTE_ADDR'],$allowed_ips) ) {
  $debug = false;
}

if($debug) {
  echo '<pre>' . print_r($some_variable) . '</pre>';
}

Désormais, les utilisateurs ne verront pas votre débogage à moins qu'ils ne le souhaitent vraiment. Si vos 800 $ / jour dépendent de la confidentialité de ces informations de débogage, n'utilisez pas le code ci-dessus . Mais si les informations ne sont pas si sensibles, ce qui précède sera bien mieux que de dépendre d'une variable GET ou de révéler vos secrets à un pays entier.

Alternativement, vous pouvez créer une debugclasse ou une fonction qui vérifiera si l'impression est autorisée ou non en fonction de vos critères. C'est ce que je fais.

Quelque chose comme ça:

class debug {
  public $on = false;
  public static function print($variable) {
    if($on) {
      echo '<pre>' . print_r($some_variable) . '</pre>';
    }
  }
}

debug::print($some_variable); // class checks if printing is allowed. If not, no printing occurs.

Pour mon programme qui me rapportera 800 $ / jour (en développement), j'utilise apache mod auth pour exiger un mot de passe pour accéder à n'importe quelle partie du site, ainsi que pour restreindre les informations de débogage à certaines adresses IP. Cependant, votre question me fait penser que je devrais envisager une meilleure sécurité.

En fait, j'aurais deux validations supplémentaires ici. L'un est le &debug=1paramètre de la demande. Vous pouvez également utiliser une variable de session spéciale ou une configuration de cookie que vous seul pouvez activer via un appel vers une page "secrète" (de préférence avec authentification).

La deuxième validation serait d'avoir dans le fichier de configuration, un tableau avec une plage d'adresses IP et seuls les appels provenant d'un IP dans ce tableau peuvent déclencher la fonctionnalité de débogage. quelque chose comme

Dans la config:

$debugAllowedIPs = array('127.0.0.1', '192.168.0.1', /* add more IPs here */);

Ayez la méthode suivante quelque part où elle peut être accédée globalement:

function getClientIp() {
    if (!empty($_SERVER['HTTP_CLIENT_IP']))  return $_SERVER['HTTP_CLIENT_IP'];
    if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) return $_SERVER['HTTP_X_FORWARDED_FOR'];
    return $_SERVER['REMOTE_ADDR'];
}

Et dans votre code, appelez quelque chose comme:

if (in_array(getClientIp(), $debugAllowedIPs)) { /* show debug info here */ }

Veuillez garder à l'esprit que le code de la getClientIp()méthode n'est pas sûr car la valeur de $_SERVER['HTTP_X_FORWARDED_FOR']est facilement usurpée, mais elle devrait servir à faire passer le message pour votre question.