logo Homepage
Pages: [1]
  Imprimer  
Auteur Fil de discussion: [Securite] Faille potentielle connection base de donnée  (Lu 5322 fois)
Pl4y3rOuufff
Profil challenge

Classement : 3874/54440

Néophyte
*
Hors ligne Hors ligne
Messages: 13


Voir le profil
« le: 27 Avril 2011 à 14:17:02 »

Salut,

Je développe une application en C# utilisant un base de donnée MS Access (patapay).  Cette DB est protégée par un mot de passe.
Lorsque mon application se connecte à la DB, elle doit connaitre le mot de passe qui est donc écrit en "clair" dans les sources.

Je me dis qu'il suffit de le dé-compiler pour obtenir ce mot de passe facilement.

Il y a t'il un moyen de palier à ce problème ?

Merci
Journalisée
Ge0

Profil challenge

Classement : 17/54440

Membre Senior
****
Hors ligne Hors ligne
Messages: 377


Voir le profil WWW
« #1 le: 27 Avril 2011 à 15:14:51 »

Salut,

Peut-être pourrais-tu te débrouiller pour faire du .NET remoting ? Tu fais en sorte de posséder une application serveur qui interrogera ta base de données Access et ton application cliente que ton utilisateur possédera. Il n'aura ni accès à l'application serveur, ni à la base de données.

C'est à mon avis ce qu'il faut faire, puisque bien que .NET soit du code managé et facilement réversible, tu as aussi ce problème de mots de passe apparents dans les exécutables natifs (ça peut arriver si tu listes des chaînes terminées par un octet nul, des chaînes unicodes, etc.).

Il y a peut-être d'autres solutions qui m'échappent, bien entendu.
Journalisée
_o_
Relecteur

Profil challenge

Classement : 42/54440

Membre Héroïque
*
Hors ligne Hors ligne
Messages: 1258


Voir le profil
« #2 le: 27 Avril 2011 à 18:00:13 »

Il n'y a pas de solution idéale, que des bonnes pratiques (ce n'est pas propre à Access, bien sûr).

Le mot de passe doit être stocké quelque part, mais il faut mettre les formes pour gagner du temps :
- le stocker chiffré (bien sûr, l'application doit pouvoir le déchiffrer, donc la clef est en dur quelque part, mais ça retarde un peu).
- les droits sur le fichier où il est stocké doivent être positionnés avec le plus grand soin pour que n'importe qui ne puisse pas le lire.
- dans la mesure du possible, la base de données ne devrait pas être accédée depuis n'importe quelle connexion distante (liste blanche des IP acceptées, par exemple, voire pas d'écoute distante ou via une socket locale si le client est hébergé sur la même machine).
- bien structurer la base de données pour que, si le mot de passe est dérobé, il ne soit possible à l'attaquant que de bricoler ou de dérober les données applicatives stockées dans la BDD, et pas les tables système.
- utiliser des protocoles réseaux chiffrés pour éviter l'écoute.
- utiliser des réseaux physiques dédiés pour ces communications.
- etc...

Après, tout est affaire de compromis entre le budget et le niveau de sécurité requis.

Au fait, un mot de passe ne se met pas en dur dans les sources. Le jour où il change, tu es obligé de patcher le code, alors qu'il suffirait de modifier un fichier de conf !
Journalisée

Les épreuves de hack de NC sont trop faciles ? Et pourtant ! Bienvenue dans la vraie vie : http://thedailywtf.com/Articles/So-You-Hacked-Our-Site!.aspx
Pl4y3rOuufff
Profil challenge

Classement : 3874/54440

Néophyte
*
Hors ligne Hors ligne
Messages: 13


Voir le profil
« #3 le: 28 Avril 2011 à 22:52:18 »

Merci pour vos réponses

Comme tu dis _o_, cela dépend fort du niveau de sécurité requis et du budget.
Je retiens principalement l'idée de mettre le mot de passe crypté dans un fichier, et d'une clef en dure dans le code ou bien d'utiliser de simple algorithme.  Le reste est très intéressant mais je ne pense pas que le client veut vraiment mettre du budget la dedans.
Journalisée
Pages: [1]
  Imprimer  
 
Aller à: