Question:
Dois-je m'inquiéter si mon site Web génère des informations sur la pile?
Kevin
2015-03-24 12:35:04 UTC
view on stackexchange narkive permalink

J'ai un formulaire de connexion simple sur ma page Web et l'URL ressemble à ceci:

  example.com/signup/signup.php?q=1  

Si j'essaye quelque chose comme ceci:

  example.com/signup/signup.php?q=1& ()  

Je suis redirigé vers un vidage de pile qui ressemble à quelque chose comme ceci:

  exception 'DOMException' avec le message 'Erreur de caractère non valide' dans /<mydirectory>/a_xml.class.php:74Stack trace: # 0 / <mydirectoy> / a_xml.class.php (74): DOMDocument->createElement ('()') ... # 6 {main}  

Est-ce un gros problème en termes de sécurité? Y a-t-il des attaques qu'un utilisateur malveillant peut effectuer qui lui permettront de dégrader ou de voler ma base de données? Ou est-ce relativement bénin et je peux l'ignorer?

Si vous ajoutez un simple & () à l'arrière d'une requête, affichez cet échange de pile. Supprimez l'application de la production, renvoyez le type qui a écrit ceci et continuez à partir de là. Je parie que si vous changez le q = en quelque chose de drôle, vous obtiendrez de bons suppléments.
Bien que la sécurité par l'obscurité soit une mauvaise chose, personne ne dit qu'il est intelligent de dire à tout le monde comment votre système fonctionne. L'obscurité * ajoutée * à d'autres mesures de sécurité peut aider un peu, ou ralentir les attaquants et vous permettre de découvrir la menace avant.
Je m'interroge à ce sujet aussi, et les réponses jusqu'à présent ne semblent pas vraiment répondre à la question. De toute évidence, toute erreur qui provoque l'affichage d'une trace de pile est un bogue qui doit être corrigé. Ce cas particulier PEUT indiquer un problème potentiel d'injection SQL, et si c'est le cas, c'est une énorme faille de sécurité et devrait être corrigé. Mais la question était: crée-t-il une faille de sécurité pour que l'utilisateur puisse voir une trace de pile? J'entends souvent les gens dire que de tels messages montrent à un pirate potentiel des informations sur des composants internes qui pourraient être exploités. Mais, comme quoi? Alors un hacker apprend que j'ai un ...
Le principe de base est «moins il y a d'informations révélées, mieux c'est». Certaines personnes n'affichent même pas la version du serveur.
... fonction nommée "foobar". Comment cela l'aide-t-il? Peut-être peut-il voir que j'utilise la bibliothèque mysqli. Je suppose que vous pourriez dire que s'il découvre que j'utilise une version particulière d'un paquet qui a une faille de sécurité connue, il pourrait l'exploiter. Mais il pourrait de toute façon essayer un éventail d'exploits de sécurité connus, donc cacher la version particulière que j'ai semble une défense faible.
En plus de ne pas le montrer à l'utilisateur, n'oubliez pas d'essayer / attraper tout ce qui est sensible pour vous assurer qu'une trace de pile ne peut pas s'échapper vers le système de journalisation.
Permettez-moi de vous poser la question suivante: pourquoi avez-vous ressenti le besoin de nettoyer «» lors de la publication de la question? À moins que ce ne soit purement pour faciliter la lisibilité, il était inutile de le supprimer. :-)
Les répertoires, les noms de fichiers source, les noms de fonctions, etc. ne sont pas si importants dans cet exemple, autant que de découvrir que la chaîne après le `&` est potentiellement transmise à un appel `createElement` en l'état. Ce sont des informations précieuses pour un attaquant potentiel, bien plus que n'importe quel nom de fichier ou numéro de ligne ou autre. Fondamentalement, puisque vous ne pouvez pas facilement prédire ce que tous les messages d'erreur possibles * eux-mêmes * diront à l'avance, vous ne voulez pas les afficher et courir le risque d'exposer de manière inattendue les détails d'une faille avant de le découvrir vous-même.
@Jay Je me souviens qu'il y a quelques mois à l'école, notre professeur nous a enseigné la sécurité et nous faisions du «piratage» dans un environnement d'apprentissage et nous pouvions faire beaucoup en connaissant simplement la structure du répertoire. Je ne me souviens plus comment s'appelle la méthode ni comment la faire.
@chloe et al: Ok, je comprends l'argument: pourquoi prendre le risque de dire quelque chose à un hacker? Même si je ne vois pas de moyen de l'exploiter, peut-être que le pirate sait quelque chose que je ne connais pas. Mais quelque chose de plus spécifique?
@Jay, Le stacktrace contient des valeurs d'argument ... Et si dans votre pile vous avez une méthode prenant votre chaîne de connexion SQL comme argument? Les informations sur la pile d'appels et les fichiers peuvent aider le pirate informatique à exploiter une faille ailleurs, il travaille plus rapidement et sera plus difficile à détecter et à arrêter à temps.
@Chloe: Bruce Schneier a une histoire, il a configuré son serveur (je pense que mail) pour mentir sur son numéro de version. Il a été obligé de le changer pour ne pas signaler du tout un numéro de version, par le volume de courrier triomphant de personnes qui avaient repéré que Schneier exécutait une version connue pour être exploitée ;-)
@SteveJessop: Pourquoi n'est-il pas simplement passé à une version qui n'a pas été exploitée o.O
@LightnessRacesinOrbit: Je suppose parce qu'il ne voulait pas continuer à le changer. De plus, je m'attends à ce qu'il y ait un risque réel que la seule version inexploitée soit la dernière, et le but n'était pas de dire la vérité.
@Steve: Il doit garder tous les services à jour. :( Quelle terrible façon de "sécuriser" son système. Je pensais qu'il était censé être un expert?
@LightnessRacesinOrbit: bien sûr, il a gardé le service à jour, il est autant sur le tapis de course que n'importe qui d'autre. Je parle du numéro de version qu'il rapporte, pas de la version dont il s'agit réellement. Bien sûr, un attaquant dédié sondera le service de toute façon pour déterminer de quelle version il s'agit, indépendamment de ce qu'il rapporte. Je ne pense pas qu'il s'agissait d'une mesure de sécurité sérieuse, juste de l'hygiène.
Six réponses:
#1
+67
Alasjo
2015-03-24 12:55:36 UTC
view on stackexchange narkive permalink

Dans les environnements de production (contrairement aux environnements de développement), les traces de pile et les messages d'erreur doivent être consignés dans un fichier au lieu d'être vidés à l'écran. En effet, un attaquant peut apprendre des choses sur votre système qui pourraient contribuer à compromettre votre système.

Des informations telles que le système d'exploitation, la version du serveur Web, la version PHP et plus encore. Certaines traces de pile peuvent contenir des variables système / d'environnement qui ne devraient pas être rendues publiques!

L'utilisateur / visiteur devrait obtenir une belle page d'erreur HTTP au lieu d'un message qui n'est d'aucune utilité pour le visiteur.

[CWE-209: Exposition d'informations via un message d'erreur] (http://cwe.mitre.org/data/definitions/209.html) et [CWE-756: Page d'erreur personnalisée manquante] (http: //cwe.mitre .org / data / définitions / 756.html).
Et les traces de pile dans la production sont si 90s
En ajoutant à la liste du deuxième paragraphe (bien que cela soit implicite dans le premier paragraphe), un attaquant peut apprendre quels sont vos bogues et les exploiter avant que vous n'ayez une chance de les remarquer. Dans le cas de l'OP, nous pouvons voir qu'il est possible que la chaîne après le `&` soit passée directement à un appel `createElement`. Un attaquant peut immédiatement commencer à expérimenter. D'un autre côté, s'il est enregistré uniquement, alors qu'il s'agit toujours d'une faiblesse, il n'est au moins pas annoncé, et en supposant que vous faites attention à vos journaux d'erreurs (ce que vous devriez), vous avez la possibilité de le corriger avant que quiconque ne le remarque.
Des informations telles que le système d'exploitation, la version du serveur Web, la version PHP et plus sont souvent incluses directement dans les en-têtes HTTP, pas besoin de trace de pile.
Je suis d'accord avec cette réponse, mais il me semble que la principale raison pour laquelle ils ne sont pas affichés sur les sites de production est qu'ils ne constituent pas un écran d'erreur utile.
Donc, la sécurité par l'obscurité est utile après tout, qui savait.
#2
+26
kasperd
2015-03-24 16:24:04 UTC
view on stackexchange narkive permalink

Il y a deux aspects différents à cela:

  • Le bogue à l'origine de la trace de pile est-il une faille de sécurité?
  • Le framework est-il configuré pour afficher les traces de pile aux étrangers.

Le message d'erreur Erreur de caractère non valide ressemble beaucoup à un échappement oublié, qui peut très souvent être exploité d'une manière ou d'une autre. Vous devriez donc vous inquiéter de la trace de pile car elle est le symptôme d'une éventuelle faille de sécurité.

L'autre question est de savoir si vous devriez être préoccupé par les traces de pile affichées à des tiers. D'une part, cacher des informations sur les éléments internes d'un système peut être considéré comme une sécurité par l'obscurité. Dans la plupart des cas, je serais d'accord avec cela, mais pas en cas de traces de pile.

Les traces de pile n'apparaissent que lorsqu'il y a un problème, donc s'il y a jamais une trace de pile, il y a un risque important que il y a un bogue, et s'il y a un bogue, il y a un risque important qu'il soit exploité. Il est donc judicieux de garder les traces de pile loin des étrangers. De plus, si la trace de pile contient non seulement les noms des fonctions appelées mais également des valeurs de paramètres, elle peut facilement fuir des clés, des mots de passe, des cookies ou d'autres types d'informations d'identification.

Pour les deux raisons ci-dessus, c'est il est important de faire attention à l'endroit où vos traces de pile apparaissent.

Il est cependant important que les traces de pile soient disponibles pour ceux qui ont besoin de résoudre le problème. La journalisation des traces de pile est donc importante. Si les cas où les traces de pile sont des indications de failles de sécurité réelles, vous souhaitez les corriger dès que possible. Même si un message d'erreur non descriptif ne donnera pas beaucoup de travail à un attaquant, simplement en réalisant quels personnages fonctionnent et lesquels ne fonctionnent pas, ils peuvent éventuellement trouver comment l'exploiter de toute façon.

+1 pour être la seule réponse à ce jour pour remarquer que, outre le vidage de la pile, cela ressemble certainement à une vulnérabilité d'injection.
#3
+15
dotancohen
2015-03-26 16:54:28 UTC
view on stackexchange narkive permalink

Il y a deux problèmes ici, et le PO pose des questions sur le problème le moins important.

Affichage de la trace

C'est le problème que l'OP demande à propos de. Il y a des débats sur le niveau d'un problème d'affichage d'une trace en général , et cet exemple particulier montre bien que l'affichage d'une trace peut être un problème de sécurité . La raison en est que cela nous permet (vous, moi et le hacker) d'être au courant de l'existence du deuxième problème.

Ne pas filtrer les entrées de l'utilisateur

C'est un réel problème . Non seulement je sais (grâce à la trace) que votre application transmet des entrées utilisateur non filtrées et non validées aux fonctions PHP natives, je sais même que DOMDocument->createElement () est la fonction en question. Maintenant, je vais commencer à attaquer ce site et tous les sites que je peux identifier avec cette société pour d'autres problèmes de filtration, tels que l'injection SQL, XSS, CSRF, ad nauseum.

Merci. Il s'agit de la réponse la plus correcte et attire l'attention sur le fait que les décharges de pile peuvent aller de totalement inoffensives à indicatives de problèmes majeurs. Trop souvent, en matière de sécurité, nous obtenons des réponses binaires et traitons tous les problèmes de sécurité de la même manière. Nous avons toujours des ressources limitées dans ce que nous pouvons faire, le triage est donc extrêmement important.
#4
+7
Rob
2015-03-24 20:12:28 UTC
view on stackexchange narkive permalink

Notez que les traces de pile incluent des paramètres. S'il y a des appels de fonction qui passent des mots de passe comme arguments, ceux-ci finiront dans des traces de pile.

C'est évidemment un désastre si un utilisateur peut lui faire afficher le mot de passe d'un autre. Moins évidemment, les mots de passe des utilisateurs se trouvent désormais dans des fichiers journaux; ce qui rendra vos utilisateurs très fous. À tout le moins, vous devez vous assurer que la journalisation des mots de passe n'a pas lieu.

#5
+4
Loko
2015-03-24 16:22:30 UTC
view on stackexchange narkive permalink

Dans votre exemple, les utilisateurs peuvent voir la structure de vos répertoires qu'ils pourraient utiliser pour des attaques potentielles. Vous seriez surpris de tout ce qu'un «hacker» peut faire avec très peu d'informations. Donc, Oui en général, c'est un gros problème en termes de sécurité. Comme le dit Alasjo, ce n'est pas non plus convivial et une page d'erreur est une bonne alternative.

Par exemple, dans certains cas, l'affichage d'erreurs aux utilisateurs peut conduire à: Cheminement du chemin

La traversée de chemin est également connue sous le nom d'attaque ../ (barre oblique par point), escalade de répertoire et retour en arrière.

#6
  0
gentwo
2015-03-27 11:09:21 UTC
view on stackexchange narkive permalink

Bien que cela ait été évoqué dans les commentaires ci-dessus, il peut être utile de noter que l'une des raisons

"Des informations telles que le système d'exploitation, la version du serveur Web, la version PHP et plus encore. Certaines traces de pile peuvent contenir variables système / d'environnement qui ne devraient pas être rendues publiques! " (Voir le commentaire ci-dessus de @Alasjo et @Danny Beckett)

est mauvais, car connaître la pile logicielle utilisée pour construire votre application permet aux attaquants d'exploiter les failles de sécurité de ces composants (les problèmes de sécurité dans les logiciels courants sont informations largement diffusées (voir https://cve.mitre.org/)) en plus de toutes les failles / défauts de votre application mis en évidence dans les traces de la pile.

Par exemple, puisque je sais que votre site utilise maintenant PHP, je pourrais essayer toutes les failles de sécurité liées à PHP (dans le cas où vous n'avez pas corrigé votre installation PHP pour corriger cette faille ... vous gardez votre logiciel niveaux de patch de pile à jour, n'est-ce pas? :-)) même si votre application n'a exposé aucune de ses propres failles dans la trace de la pile.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...