Sécurisation des chaînes de connexion

Le
Gloops
Bonjour tout le monde,

J'ai posé il y a quelques mois une question sur la sécurisation des
chaînes de connexion, la réponse passait par iis, il s'avère que mo=
n
hébergeur n'assure pas le support iis en mutualisé.

Les réponses des confrères m'éberluent. Si quelqu'un veut bien dire=

quelque chose sur la sécurisation des chaînes de connexion, la questi=
on
se trouve dans le newsgroup microsoft.public.fr.dotnet.csharp, où elle =

est plus à sa place, je viens aussi en toucher deux mots ici car j'ai
l'impression qu'il y a plus de monde.

Merci de votre attention.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jérémy Jeanson
Le #21167541
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
Gloops
Le #21167821
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


Jérémy Jeanson
Le #21167831
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
Gloops
Le #21173071
Jérémy Jeanson a écrit, le 10/02/2010 15:04 :
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
Le #21173051
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
Gloops
Le #21173601
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.
Patrice
Le #21182521
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
Le #21192501
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.
Publicité
Poster une réponse
Anonyme