Je voudrais enregistrer des erreurs / des messages d'information et d'avertissement de mon application Web à un journal. J'avais initialement pensé à vous connecter à tous sur un fichier texte.
Cependant, mon application Web PHP aura besoin d'un accès en écriture sur les fichiers journaux et du logement du dossier Ce fichier journal peut également avoir besoin d'un accès en écriture si la rotation du fichier journal est souhaitée que mon application Web n'a actuellement pas. L'alternative est pour moi de connecter les messages dans la base de données MySQL car mon application Web utilise déjà la base de données MySQL pour tous ses besoins de stockage de données.
Cependant, cela m'a fait penser que l'option MySQL est bien meilleure que l'option de fichier car j'ai déjà un fichier de configuration avec les informations d'accès à la base de données protégées à l'aide des autorisations du système de fichiers. Si j'irais maintenant avec l'option du fichier journal, j'ai besoin de bricoler les autorisations d'accès au fichier et au dossier, ce qui ne fera que rendre mon application moins sécurisée et défaite l'ensemble de la journalisation.
mise à jour: L'autre avantage que je vois avec l'option DB est le manque de besoin de réouverture de la connexion DB pour chacune de ma page Web en utilisant des connexions de DB persistantes qui n'est pas possible avec la journalisation des fichiers. Dans le cas de la journalisation des fichiers, je devrai ouvrir, écrire dans le fichier journal et fermer le fichier pour chaque page.
est-ce correct? J'utilise XAMPP pour le développement et je suis un débutant à la lampe. S'il vous plaît laissez-moi savoir vos recommandations pour la journalisation. Merci.
5 Réponses :
Et si votre dB n'est pas accessible, où allez-vous vous connecter?
Les fichiers journaux sont généralement écrits dans des fichiers texte. Une bonne raison est que, une fois correctement configuré, cette méthode ne manque presque jamais (bien que vous puissiez toujours manquer d'espace disque ou que des autorisations peuvent changer sur vous ...).
Il existe déjà un certain nombre de bonnes fraches forestières qui fournissent une journalisation facile et puissante. Je ne connais pas ce qui est aussi familier avec ce qui est disponible spécifiquement pour PHP (peut-être que quelqu'un d'autre peut commenter), mais Log4J est très couramment utilisé dans le monde Java.
Je vous entends mais ma seule préoccupation est la question de l'autorisation. Vous suggérez-vous que je donne des autorisations d'écriture dans mon dossier Web dans ce cas? J'aime le log4php avec toutes ses options cependant.
@IAMA: Ne donnez jamais la permission d'écriture à votre dossier Web. Sélectionnez un dossier séparé pour les fichiers journaux ( pas quelque part sous votre racine Web) et donnez des autorisations d'écriture là-bas.
Celui-ci a baissé cette réponse, ce serait bien de laisser une raison. Presque toutes les applications Web sont en train de se connecter aux fichiers texte. La baisse sans laisser d'explication n'est pas très utile pour moi ni pour les autres qui lisent cette question.
En plus d'assurer des autorisations correctes, il est judicieux de stocker vos fichiers journaux exteries de la racine Web - c'est-à-dire si votre racine Web est / comptes / iAma / public_html , stockez les journaux dans < Code> / comptes / iAMA / journaux
Compris et c'est comme ça que je stocke mes paramètres d'accès à dB. Cependant, ce dossier de fichier journal nécessitera toujours un accès complet en écriture au compte de personne Apache, correct? Est-ce ce que vous recommandez?
Le compte d'utilisateur que PHP fonctionne comme nécessitera un accès en écriture. Je ne suis pas sûr que vous devriez avoir PHP fonctionner comme anonyme.
Les fichiers journaux, dans mon expérience, sont toujours mieux stockés dans le format de texte brut. De cette façon, ils sont toujours lisibles dans n'importe quelle situation (c'est-à-dire sur ssh ou sur un terminal local) et sont presque disponibles pour être écrits.
Le deuxième problème est Security - Lisez sur la définition des autorisations de fichier sous un système Linux et donnez au répertoire les autorisations minimales pour PHP pour y écrire et que quiconque a besoin d'accès à la lecture de la lecture. Vous pourriez même avoir un cryptage au niveau des systèmes de fichiers.
Si vous deviez tout vouloir, vous pouvez nettoyer les fichiers journaux quotidiens avec une copie cryptée envoyée à un autre emplacement sur SSL, mais je pense que cela peut être surchargé;)
Si cela ne vous dérange pas que je demande, ce qui rend ces fichiers journaux si critiques en termes de sécurité?
meh .htaccess "nie de tout"
La journalisation dans un fichier peut être un danger de sécurité. Par exemple, prenez en considération un LFI Exploit . Si un attaquant peut influencer vos fichiers journaux et ajouter du code PHP comme Code vulnérable:
Et si vous avez accédé à cette page comme ceci:
En général, je stockerais ces informations d'erreur dans la base de données lorsque cela est possible. Cependant, afin de tirer cette attaque que vous avez besoin (P.S. XAMPP est vraiment mauvais d'une perspective de sécurité, il n'y a pas de mise à jour automatique et les responsables de projet sont très lents à libérer des corrections pour des vulnérabilités très graves.) , puis il pourrait exécuter ce code PHP à l'aide d'une attaque LFI. Voici un exemple:
inclure ("/ var / www / inclus /".$_ obtenir [" fichier ']);
http: //localhost/lfi_vuln.php? fichier = .. / journaux / fichier.log & e = phpinfo ();
<> , quel htmlspecialchars () résoudra. Même vous protégez votre auto contre les attaques LFI, vous devriez avoir une "approche de la défense en profondeur", peut-être que le code que vous n'avez pas écrit est vulnérable, tel qu'une bibliothèque que vous utilisez.
@Le Rook: C'est pourquoi (entre autres raisons) que vous vous connectez à un dossier explicitement configuré pour ne pas autoriser l'exécution PHP.
@Eric J. Vous pouvez inclure un fichier n'importe où et son être toujours exécuté aussi longtemps qu'il peut être lu. Go Head, créez un fichier /tmp/junk.none Ajoutez du code PHP, puis inclure ("/ tmp / junk.none");
@Le Rook: chmod -r mylogfile.txt (ou plus utile, ne donnez pas l'autorisation de lecture au processus exécutant votre PHP).
@ Sciences J. Bien que cela résoudra le problème des fichiers journaux. Il reste toujours le problème des images, des PDF et d'autres contenus téléchargés par l'utilisateur qui doivent être lisibles. Je pense toujours que la base de données est la moindre endroit sujette d'erreur pour résider.
@Le Rook: Si vous pouvez inclure ("/ TMP / Junk.none"), vous avez une configuration PHP insécuritée. Voir php.net/manual/fr/ini.core.php , section Open_Basedir.
@ Sciences J. Je pense toujours que SQL est moins sujet aux erreurs (conditions de race qui ont été soulevées dans le lien que vous avez posté). Oui, il existe de nombreuses façons de défendre à l'encontre des attaques LFI cependant très peu sont au courant de leur existence. Chaque configuration PHP par défaut, y compris PHP.ini recommandée de Zend ne définit pas Open_Basedir. Lors de l'écriture du code d'exploitation, l'attaquant doit supposer que le système est par défaut et comptez des configurations plus sécurisées lorsque cela est possible (tel que MAGIC_QUOOTES_GPC = ON ou OFF).
@ERIC J. Vous avez une bonne solution à ces problèmes. Réglage Open_BaseDir est une bonne approche «de sécurité en profondeur», de sorte que vous exécutez phpsecinfo. Pour résoudre la racine du problème, vous devez utiliser une liste blanche pour que les variables utilisées comprennent () / requis (). Ces deux options sont plus pratiques que de supprimer le bit de lecture, mais cela fera également l'affaire.
On dirait que vous posez quelques questions différentes:
La journalisation à un dB n'est pas plus sécurisée que de vous connecter à un fichier et inversement.
Vous devez exécuter votre serveur PHP / serveur Web à l'aide d'un utilisateur qui n'a pas la permission de faire quoi que ce soit d'exécuter le serveur et d'écrire dans ses fichiers journaux. Ajout de la rédaction de fichiers journaux à votre application ne doit pas compromettre la sécurité de quelque manière que ce soit. . Jetez un coup d'œil à http://www.linux.com/archive/feature/1137444/a > Pour plus d'informations.
Il n'y a pas d'une seule réponse droite, cela dépend de ce que vous voulez faire avec vos journaux.
Que voulez-vous faire avec les fichiers journaux? Voulez-vous les piler dans une autre application? Si oui, les mettre dans une DB pourrait être la voie à suivre. Voulez-vous les archiver? Eh bien, il pourrait être préférable de les jeter dans un fichier.
Si vous utilisez un cadre de journalisation comme log4php, http://logging.apache.org/ log4php / index.html Vous pouvez vous connecter facilement à un fichier dB et à un fichier journal (ce n'est probablement pas quelque chose que vous devriez faire, mais il pourrait y avoir un cas) ou vous pouvez basculer entre les deux systèmes de stockage sans beaucoup tracas.
Edit: Ce sujet peut être un duplicata de Connectez-vous pour fichier via PHP ou Connexion à la base de données MySQL - qui est plus rapide?
Merci d'avoir répondu. Toutefois, à partir d'un point de vue de la performance, vous ne pensez pas que nous allons ouvrir et fermer le fichier pour chaque page, tandis que avec DB qui peut ne pas être le cas surtout si nous utilisons des connexions persistantes ou une mise en commun de la connexion.
@IAMA Je n'ai pas de chiffres, mais je suppose qu'il n'y a peu aucune différence de performance dans la plupart de chaque application Web (pourrait être différente si vous exécutez Facebook) entre la journalisation du fichier et la journalisation de DB. Exécutez une référence rapide (démarrez une minuterie, insérez des messages journaux de 50 000 journaux, une minuterie d'arrêt. Faites cela pour un fichier et un dB.) Et laissez-nous savoir ce que vous trouvez. Jetez un coup d'œil à ce thème très très similaire de dépassement de pile: Stackoverflow.com/Questtions/183783/...