J'ai pos=E9 il y a quelques mois une question sur la s=E9curisation des=20
cha=EEnes de connexion, la r=E9ponse passait par iis, il s'av=E8re que mo=
n=20
h=E9bergeur n'assure pas le support iis en mutualis=E9.
Les r=E9ponses des confr=E8res m'=E9berluent. Si quelqu'un veut bien dire=
=20
quelque chose sur la s=E9curisation des cha=EEnes de connexion, la questi=
on=20
se trouve dans le newsgroup microsoft.public.fr.dotnet.csharp, o=F9 elle =
est plus =E0 sa place, je viens aussi en toucher deux mots ici car j'ai=20
l'impression qu'il y a plus de monde.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jérémy Jeanson
Bonjour Gloops,
La sécurité de la ConnectionString dans un fichier de config ne sert en fait que contre les personne aillant un accès administrateur à ton IIS. donc cela ne concerne que toi et ton hébergeur.
Voila pourquoi il y a très peu de monde qui en parle. Si tu souhaite cependant l'appliquer, sache qu'il faut impérativement avoir une clé dans ton fichier de configuration.
Pour la documentation, ça se trouve par ici : http://msdn.microsoft.com/en-us/library/ms178372.aspx
--- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour Gloops,
La sécurité de la ConnectionString dans un fichier de config ne sert
en fait que contre les personne aillant un accès administrateur à ton
IIS. donc cela ne concerne que toi et ton hébergeur.
Voila pourquoi il y a très peu de monde qui en parle. Si tu souhaite
cependant l'appliquer, sache qu'il faut impérativement avoir une clé
dans ton fichier de configuration.
Pour la documentation, ça se trouve par ici :
http://msdn.microsoft.com/en-us/library/ms178372.aspx
La sécurité de la ConnectionString dans un fichier de config ne sert en fait que contre les personne aillant un accès administrateur à ton IIS. donc cela ne concerne que toi et ton hébergeur.
Voila pourquoi il y a très peu de monde qui en parle. Si tu souhaite cependant l'appliquer, sache qu'il faut impérativement avoir une clé dans ton fichier de configuration.
Pour la documentation, ça se trouve par ici : http://msdn.microsoft.com/en-us/library/ms178372.aspx
--- Jérémy JEANSON MCP http://www.jjeanson.fr
Gloops
Bonjour,
Ah bon ? J'avais pourtant bien lu quelque part l'histoire de hackers ayant réuss i à lire ce qui les intéressait dans le web.config, d'où l'intérê t que ça ne donne rien de trop clair ? Tu semblerais ranger ça comme "légende urbaine" ?
Je n'ai pas vérifié à l'instant mais ce que je vois dans la doc me rappelle effectivement ce que j'ai essayé de mettre en uvre.
Donc selon toi un mot de passe en clair dans le web.config ne poserait pas de problème de sécurité ? _____________________________________________ Jérémy Jeanson a écrit, le 10/02/2010 14:20 :
Bonjour Gloops,
La sécurité de la ConnectionString dans un fichier de config ne ser t en fait que contre les personne aillant un accès administrateur à t on IIS. donc cela ne concerne que toi et ton hébergeur.
Voila pourquoi il y a très peu de monde qui en parle. Si tu souhaite cependant l'appliquer, sache qu'il faut impérativement avoir une clé dans ton fichier de configuration.
Pour la documentation, ça se trouve par ici : http://msdn.microsoft.com/en-us/library/ms178372.aspx
--- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour,
Ah bon ?
J'avais pourtant bien lu quelque part l'histoire de hackers ayant réuss i
à lire ce qui les intéressait dans le web.config, d'où l'intérê t que ça
ne donne rien de trop clair ?
Tu semblerais ranger ça comme "légende urbaine" ?
Je n'ai pas vérifié à l'instant mais ce que je vois dans la doc me
rappelle effectivement ce que j'ai essayé de mettre en uvre.
Donc selon toi un mot de passe en clair dans le web.config ne poserait
pas de problème de sécurité ?
_____________________________________________
Jérémy Jeanson a écrit, le 10/02/2010 14:20 :
Bonjour Gloops,
La sécurité de la ConnectionString dans un fichier de config ne ser t
en fait que contre les personne aillant un accès administrateur à t on
IIS. donc cela ne concerne que toi et ton hébergeur.
Voila pourquoi il y a très peu de monde qui en parle. Si tu souhaite
cependant l'appliquer, sache qu'il faut impérativement avoir une clé
dans ton fichier de configuration.
Pour la documentation, ça se trouve par ici :
http://msdn.microsoft.com/en-us/library/ms178372.aspx
Ah bon ? J'avais pourtant bien lu quelque part l'histoire de hackers ayant réuss i à lire ce qui les intéressait dans le web.config, d'où l'intérê t que ça ne donne rien de trop clair ? Tu semblerais ranger ça comme "légende urbaine" ?
Je n'ai pas vérifié à l'instant mais ce que je vois dans la doc me rappelle effectivement ce que j'ai essayé de mettre en uvre.
Donc selon toi un mot de passe en clair dans le web.config ne poserait pas de problème de sécurité ? _____________________________________________ Jérémy Jeanson a écrit, le 10/02/2010 14:20 :
Bonjour Gloops,
La sécurité de la ConnectionString dans un fichier de config ne ser t en fait que contre les personne aillant un accès administrateur à t on IIS. donc cela ne concerne que toi et ton hébergeur.
Voila pourquoi il y a très peu de monde qui en parle. Si tu souhaite cependant l'appliquer, sache qu'il faut impérativement avoir une clé dans ton fichier de configuration.
Pour la documentation, ça se trouve par ici : http://msdn.microsoft.com/en-us/library/ms178372.aspx
--- Jérémy JEANSON MCP http://www.jjeanson.fr
Jérémy Jeanson
L'accès au web.config via un navigateur? En théorie impossible.
Après rien n'empêche d'avoir une très, très mauvaise configuration de son IIS. Mais je ne sais pas jusqu'à quelle point celà peut aller
--- Jérémy JEANSON MCP http://www.jjeanson.fr
L'accès au web.config via un navigateur? En théorie impossible.
Après rien n'empêche d'avoir une très, très mauvaise configuration de
son IIS. Mais je ne sais pas jusqu'à quelle point celà peut aller
L'accès au web.config via un navigateur? En théorie impossible.
Après rien n'empêche d'avoir une très, très mauvaise configurat ion de son IIS. Mais je ne sais pas jusqu'à quelle point celà peut aller
Vu comme ça c'est certes plus facile. Je dois bien avouer que tu es le premier que je vois dire ça de façon aussi catégorique.
Jérémy Jeanson
Bonjour Gloops,
Ce n'est pas que je sois si catégorique que cela, mais .net est fait pour tourner sur un IIS, et je ne vois pas comment, même le pire des administrateur pourrait rendre accessible le web.config.
Il va bien entendu de soit que si un FTP est ouvert sur IIS et qu'il est public... enfin bon! je pense que tu as compris. Après tout ce n'est que mon point de vue.
Personnellement je travail avec des administrateurs compétents qui ne toucheraient pas à la sécurité sans en connaitre les conséquences.. ..
Tiens c'es une idée ça, je vais leur poser la question... histoire de savoir si il y en a un plus tordu que les autres chez nous... lol (la guerre Développeurs versus Administrateurs continue) --- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour Gloops,
Ce n'est pas que je sois si catégorique que cela, mais .net est fait
pour tourner sur un IIS, et je ne vois pas comment, même le pire des
administrateur pourrait rendre accessible le web.config.
Il va bien entendu de soit que si un FTP est ouvert sur IIS et qu'il
est public... enfin bon! je pense que tu as compris. Après tout ce
n'est que mon point de vue.
Personnellement je travail avec des administrateurs compétents qui ne
toucheraient pas à la sécurité sans en connaitre les conséquences.. ..
Tiens c'es une idée ça, je vais leur poser la question... histoire de
savoir si il y en a un plus tordu que les autres chez nous... lol (la
guerre Développeurs versus Administrateurs continue)
---
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Ce n'est pas que je sois si catégorique que cela, mais .net est fait pour tourner sur un IIS, et je ne vois pas comment, même le pire des administrateur pourrait rendre accessible le web.config.
Il va bien entendu de soit que si un FTP est ouvert sur IIS et qu'il est public... enfin bon! je pense que tu as compris. Après tout ce n'est que mon point de vue.
Personnellement je travail avec des administrateurs compétents qui ne toucheraient pas à la sécurité sans en connaitre les conséquences.. ..
Tiens c'es une idée ça, je vais leur poser la question... histoire de savoir si il y en a un plus tordu que les autres chez nous... lol (la guerre Développeurs versus Administrateurs continue) --- Jérémy JEANSON MCP http://www.jjeanson.fr
Gloops
Jérémy Jeanson a écrit, le 11/02/2010 10:18 :
Tiens c'es une idée ça, je vais leur poser la question... histoire de savoir si il y en a un plus tordu que les autres chez nous... lol (la guerre Développeurs versus Administrateurs continue)
Je soupçonne que ce qui est craint dans l'histoire n'est pas qu'on ait délibérément mis en accès public le répertoire racine où se t rouve la config, mais peut-être plutôt qu'un petit malin ait réussi à dé tourner des outils qui ne lui étaient pas destinés, donc a priori de façon quand même un tantinet plus détournée que ce que tu évoques, parce que l'erreur est humaine, mais à ce point-là c'est vrai que ça paraît rait gros.
Alors après, quant à faire confiance aux outils mis à disposition d es développeurs, là j'ai tendance à suivre ce qui est enseigné en formation, parce que pour faire autrement il faut quand même arriver à un niveau de confiance en soi que je n'ai pas atteint.
Jérémy Jeanson a écrit, le 11/02/2010 10:18 :
Tiens c'es une idée ça, je vais leur poser la question... histoire de
savoir si il y en a un plus tordu que les autres chez nous... lol (la
guerre Développeurs versus Administrateurs continue)
Je soupçonne que ce qui est craint dans l'histoire n'est pas qu'on ait
délibérément mis en accès public le répertoire racine où se t rouve la
config, mais peut-être plutôt qu'un petit malin ait réussi à dé tourner
des outils qui ne lui étaient pas destinés, donc a priori de façon quand
même un tantinet plus détournée que ce que tu évoques, parce que
l'erreur est humaine, mais à ce point-là c'est vrai que ça paraît rait gros.
Alors après, quant à faire confiance aux outils mis à disposition d es
développeurs, là j'ai tendance à suivre ce qui est enseigné en
formation, parce que pour faire autrement il faut quand même arriver à
un niveau de confiance en soi que je n'ai pas atteint.
Tiens c'es une idée ça, je vais leur poser la question... histoire de savoir si il y en a un plus tordu que les autres chez nous... lol (la guerre Développeurs versus Administrateurs continue)
Je soupçonne que ce qui est craint dans l'histoire n'est pas qu'on ait délibérément mis en accès public le répertoire racine où se t rouve la config, mais peut-être plutôt qu'un petit malin ait réussi à dé tourner des outils qui ne lui étaient pas destinés, donc a priori de façon quand même un tantinet plus détournée que ce que tu évoques, parce que l'erreur est humaine, mais à ce point-là c'est vrai que ça paraît rait gros.
Alors après, quant à faire confiance aux outils mis à disposition d es développeurs, là j'ai tendance à suivre ce qui est enseigné en formation, parce que pour faire autrement il faut quand même arriver à un niveau de confiance en soi que je n'ai pas atteint.
Patrice
C'est plus effectivement un pb de "lignes de défense".
Je me souviens par exemple d'un temps ou une url malformée permettait éventuellement de récupérer le code source des pages ASP "Classic".
Si IIS avait un plus un droit "Read" sur ces pages cela permettait alors de voir le code source. Sans le droit "Read" (inutile car IIS ne fournissait jamais ce contenu brut), IIS ne fournissait pas le contenu et le code source était toujours protégé. etc...
Donc selon la nature des données présentes dans ta base, crypter le web.config peut-être un obstacle de plus. Egalement la nature et l'emplacement de la base peuvent intervenir : - si c'est de l'Access la chaine de connexion va révéler l'emplacement du fichier peut-être dans App_Data lui aussi bloqué par IIS mais cet emplacement est potentiellement accessible) - si c'est SQL Server on aura le nom du serveur et l'accès sera peut-être un peu plus difficile (en tout cas on ne peut probablement pas récupérer directement le fichier base de données).
Comme toujours c'est un compromis. A toi de voir le nb de lignes de défense en fonction de la sensibilité des données présentes dans cette base...
-- Patrice
C'est plus effectivement un pb de "lignes de défense".
Je me souviens par exemple d'un temps ou une url malformée permettait
éventuellement de récupérer le code source des pages ASP "Classic".
Si IIS avait un plus un droit "Read" sur ces pages cela permettait alors de
voir le code source. Sans le droit "Read" (inutile car IIS ne fournissait
jamais ce contenu brut), IIS ne fournissait pas le contenu et le code source
était toujours protégé. etc...
Donc selon la nature des données présentes dans ta base, crypter le
web.config peut-être un obstacle de plus. Egalement la nature et
l'emplacement de la base peuvent intervenir :
- si c'est de l'Access la chaine de connexion va révéler l'emplacement du
fichier peut-être dans App_Data lui aussi bloqué par IIS mais cet
emplacement est potentiellement accessible)
- si c'est SQL Server on aura le nom du serveur et l'accès sera peut-être un
peu plus difficile (en tout cas on ne peut probablement pas récupérer
directement le fichier base de données).
Comme toujours c'est un compromis. A toi de voir le nb de lignes de défense
en fonction de la sensibilité des données présentes dans cette base...
C'est plus effectivement un pb de "lignes de défense".
Je me souviens par exemple d'un temps ou une url malformée permettait éventuellement de récupérer le code source des pages ASP "Classic".
Si IIS avait un plus un droit "Read" sur ces pages cela permettait alors de voir le code source. Sans le droit "Read" (inutile car IIS ne fournissait jamais ce contenu brut), IIS ne fournissait pas le contenu et le code source était toujours protégé. etc...
Donc selon la nature des données présentes dans ta base, crypter le web.config peut-être un obstacle de plus. Egalement la nature et l'emplacement de la base peuvent intervenir : - si c'est de l'Access la chaine de connexion va révéler l'emplacement du fichier peut-être dans App_Data lui aussi bloqué par IIS mais cet emplacement est potentiellement accessible) - si c'est SQL Server on aura le nom du serveur et l'accès sera peut-être un peu plus difficile (en tout cas on ne peut probablement pas récupérer directement le fichier base de données).
Comme toujours c'est un compromis. A toi de voir le nb de lignes de défense en fonction de la sensibilité des données présentes dans cette base...
-- Patrice
Gloops
Patrice a écrit, le 12/02/2010 13:23 :
Comme toujours c'est un compromis. A toi de voir le nb de lignes de dé fense en fonction de la sensibilité des données présentes dans cette ba se...
C'est à dire que dans les données à protéger il y a aussi des con nexions mail, et là je suis responsable vis-à-vis du prestataire.
Sinon pour la connexion à la base, c'est vrai que je pourrais toujours tenter le coup, et changer le mot de passe si il s'avère que c'était trop léger. Enfin bon, si on essaie de faire du travail propre, autant ne pas le laisser détruire trop facilement.
Patrice a écrit, le 12/02/2010 13:23 :
Comme toujours c'est un compromis. A toi de voir le nb de lignes de dé fense
en fonction de la sensibilité des données présentes dans cette ba se...
C'est à dire que dans les données à protéger il y a aussi des con nexions
mail, et là je suis responsable vis-à-vis du prestataire.
Sinon pour la connexion à la base, c'est vrai que je pourrais toujours
tenter le coup, et changer le mot de passe si il s'avère que c'était
trop léger. Enfin bon, si on essaie de faire du travail propre, autant
ne pas le laisser détruire trop facilement.
Comme toujours c'est un compromis. A toi de voir le nb de lignes de dé fense en fonction de la sensibilité des données présentes dans cette ba se...
C'est à dire que dans les données à protéger il y a aussi des con nexions mail, et là je suis responsable vis-à-vis du prestataire.
Sinon pour la connexion à la base, c'est vrai que je pourrais toujours tenter le coup, et changer le mot de passe si il s'avère que c'était trop léger. Enfin bon, si on essaie de faire du travail propre, autant ne pas le laisser détruire trop facilement.
