Pourquoi la consignation correcte des requêtes http complètes serait-elle une mauvaise pratique?
Je regarde actuellement la documentation Secure Coding Practices fournie par Veracode avec sa suite d'outils d'analyse de code.
Dans une section "pratiques de journalisation sécurisées", ils mentionnent que la journalisation des requêtes HTTP complètes en cas d'erreur est une erreur courante, mais ils n'expliquent pas pourquoi.
Je travaille sur un site Web personnel où j'ai 2 fichiers journaux distincts:
errors.log: toute exception inattendue finit par être interceptée et enregistrée dans ce fichier. Là, je journalise simplement le stacktrace (journalisation d'exception de base simple classique)
security.log: toute demande qui n'a pas pu être effectuée via l'interface utilisateur, qui est le signe d'une demande falsifiée (exemple: IDOR tente comme quelqu'un essayant d'accéder aux données d'un autre utilisateur), entraîne la levée d'une exception de sécurité d'exécution personnalisée. Cette exception de sécurité stocke notamment la demande http qui a été effectuée, puis est enregistrée. Fondamentalement, tous mes validateurs principaux (qui effectuent les mêmes vérifications que les validateurs frontaux) lèvent cette exception de sécurité en cas de problème - l'idée est que je (ou une tâche Cronned;)) puisse régulièrement vérifier que security.log est vide .
J'ai décidé de consigner la demande http complète (j'entends par là: pas la demande brute, mais j'extrais tous les en-têtes/cookies et paramètres et les affiche de manière lisible, ainsi que des informations comme l'horodatage, l'origine IP et autres choses) pour les exceptions de sécurité uniquement (pour faciliter l'analyse des attaques potentielles liées à la logique biz).
Ce fichier journal sera ouvert dans un éditeur de texte uniquement (VI très probablement), et ne sera pas automatiquement analysé par les outils ou affiché dans une webapp.
Maintenant, je comprends que la journalisation des requêtes http complètes peut être exploitée dans certaines conditions. Un exemple classique est une webapp d'analyse de journaux sujette aux attaques XSS qui est utilisée par un helpdesk - dans ce cas, un attaquant pourrait forger une requête malveillante pour laisser la charge utile exploser une fois que les gars du helpdesk vérifient le contenu des journaux via la webapp vulnérable.
Je comprends également que la journalisation de trop de choses peut entraîner un déni de service en raison de la saturation des disques, mais c'est déjà le cas avec les traces de pile.
Dans mon cas, quels dangers pourraient découler des demandes de journalisation, dans des cas particuliers? La seule chose (techniquement valide mais irréaliste, étant donné la faible sensibilité du site Web) que je vois serait une charge utile spécialement conçue qui pourrait provoquer une sorte de débordement de tampon lorsqu'elle est analysée par VI (l'attaquant devrait savoir que j'utilise VI + use un 0-jour etc .. Ok possible pour NSA mais irréaliste pour ce petit site qui n'est d'ailleurs pas une cible d'intérêt d'ailleurs pour certains script kiddies).
Je suppose que quelqu'un pourrait faire de la falsification de journaux, mais bonne chance pour découvrir mon affichage de demande unique: P Étant donné que j'extrais des données dans la demande et les affiche à ma manière, il est pratiquement impossible de me tromper via la falsification de journaux.
Dois-je vérifier spécifiquement les caractères de contrôle du VI de fin de fichier (cela existe-t-il même?)?
Quoi d'autre pourrait mal tourner? Est-ce que j'ai râté quelque chose ? Maintenant, je me rends compte que ma question pourrait être paraphrasée: "ce qui peut mal tourner si je laisse les utilisateurs écrire du texte (via le contenu de la demande ..) dans un seul fichier contrôlé sur ma machine qui ne sera ouvert que par un puits à jour éditeur de texte éprouvé "
MISE À JOUR
Mise à jour pour fournir plus d'informations sur les 3 premiers retours (merci pour ce bon retour entre nous!)
- Le formulaire de connexion n'est pas couvert par le mécanisme (mais le formulaire d'inscription l'est!)
- Je ne gère pas de boutique, il n'y a pas d'informations très sensibles. Les informations les plus sensibles seraient le prénom/nom et la date de naissance lors de l'inscription de l'utilisateur. Il y a un jeu avec des points et des classements, donc la sécurité est importante pour éviter la tricherie (donc cette journalisation personnalisée)
- Insistant sur le fait que seules les demandes malveillantes (contournement de la validation frontale) seront enregistrées, dans un monde utopique, le fichier journal sécurisé resterait vide pour toujours
Grâce à vos commentaires, je me rends compte, entre autres:
- La divulgation du contenu de ce fichier pourrait permettre le détournement de session en raison de l'extraction des cookies de session de la demande
- Un bogue dans l'analyseur de requête pourrait empêcher une requête d'être enregistrée
- Un bogue dans mon code pourrait enregistrer une demande d'enregistrement d'utilisateur mal formée qui stockerait des informations sensibles dans le secu-log (le mot de passe étant clairement le plus sensible)
Manipulation :
- En ce qui concerne la divulgation du contenu du fichier, je suppose que si quelqu'un y arrive, je suis déjà en poste :)
- Concernant le bogue de l'analyseur, en effet, mais au moins cela déclencherait une exception qui serait enregistrée dans le logger "normal", c'est acceptable
- Concernant le formulaire d'inscription, je considère que même si un bug aussi rare se produisait, je ne devrais pas avoir accès à un mot de passe en clair, même par accident. Je vais adapter l'analyseur pour ne stocker aucun paramètre de demande qui correspond à un
*password*modèle.
Je suppose que je ne peux raisonnablement pas aller plus loin que cela pour protéger mes utilisateurs (si je veux pouvoir détecter les attaques biz-logic en direct). Je suppose que 99% des sites sur le web ne vont pas jusqu'à la moitié de ces considérations :)). Il me semble clair que la petite surface d'attaque ajoutée est compensée par les avantages de sécurité que cette journalisation personnalisée offre.
J'ajouterai des tests unitaires approfondis supplémentaires à cette partie de la base de code pour finalement réduire les risques de bogue.
Dans un environnement d'entreprise, je devinerais deux fois en ce qui concerne la journalisation des données sensibles - je suppose que je discuterais de la question avec quelqu'un comme un responsable de la conformité des données
Le mot clé est correctement.
Consigner correctement les requêtes HTTP en cas de besoin n'est pas une mauvaise pratique. Je suis un testeur de stylo et j'enregistre toutes les requêtes HTTP que je fais dans le cadre d'un test; cela est attendu. Je travaille également sur un système serveur qui s'intègre à un certain nombre de systèmes hérités complexes. La journalisation des requêtes HTTP complètes en cas d'erreur est une fonctionnalité nécessaire. Il peut afficher des détails tels que le système d'un cluster qui a fait la demande erronée, qui autrement serait perdu.
Veracode est un système d'analyse de code source automatisé. Il peut indiquer si vous transmettez une requête HTTP à une fonction de journal. Mais il ne peut pas vraiment dire si vous vous connectez "correctement". Ils sont donc arrivés à cette conclusion plutôt vague, car c'est le mieux que leur système puisse faire. N'y mettez pas trop de poids. Le problème a-t-il une cote de risque? Je soupçonne que ce serait à faible risque. La plupart des gens sont moins consciencieux que vous et accordent peu d'attention aux problèmes à faible risque.
Les éléments clés pour une journalisation correcte sont:
- Injection/forgeage de grumes
- Déni de service
- Confidentialité des journaux
Vous mentionnez les deux premiers dans votre question. Pour un site Web personnel, le troisième n'est pas un problème - vous êtes le propriétaire, l'administrateur système, tout - et vous seul aurez accès. C'est un problème beaucoup plus important dans un environnement d'entreprise, où vous ne voulez certainement pas que tout le monde dans l'entreprise ait accès aux données confidentielles (comme les mots de passe des utilisateurs) dans les demandes. Certains systèmes masquent délibérément des parties de données dans les journaux - en particulier les numéros de carte de crédit, pour la conformité PCI.
Vous mentionnez que vous extrayez les en-têtes, les cookies et les paramètres et les formatez dans le fichier journal. Je vous recommande de consigner les demandes brutes et d'avoir un post-processeur séparé pour les formater. Il y aura des situations étranges - par exemple paramètre dupliqué dans l'URL et POST body - cela peut provoquer des erreurs. L'extraction et la mise en forme peuvent entraîner la perte de la fonctionnalité de la demande d'origine.
Le problème avec la journalisation de tout n'est pas que vous pourriez l'implémenter incorrectement (par exemple autoriser XSS, l'exécution de code, le débordement de tampon, etc.), car la solution à cela serait simplement de le faire correctement, comme c'est le cas avec tout le code. [Vous fournissez une surface d'attaque supplémentaire, mais si vous décidez que la conservation de journaux supplémentaires est importante, cela peut en valoir la peine]
Le problème est avec ce que vous vous connectez: all the headers / cookies and parameters. Ceux-ci peuvent évidemment contenir des informations sensibles, telles que les identifiants de session, les cookies de connexion, les mots de passe, les informations de carte de crédit, etc., en texte clair.
Maintenant, si vous enregistrez uniquement les demandes que vous savez malveillantes, il peut être correct de les enregistrer. Mais pouvez-vous en être sûr? Peut-être que vous jetez accidentellement une exception de sécurité sur une action valide, ou que vous en jetez une sur un incident de sécurité qui peut être produit par un utilisateur valide - comme une connexion non valide en raison d'une faute de frappe.
Même si vous stockez ces journaux en toute sécurité, vous pouvez avoir des vulnérabilités dans votre code qui permettent à un attaquant de les lire de toute façon (par exemple via LFI). Vous pouvez également avoir des sauvegardes de ces journaux, qui peuvent être compromises. Ou un attaquant peut avoir obtenu un accès limité au serveur et obtenir d'autres informations utiles à partir de ces journaux.