Sécurité des bases de données

Question

Bonjour,



Je construit un site internet compos&#233; de deux parties :

- une partie frontale qui affiche les offres de produits aux clients

- une partie "office" qui permet au propri&#233;taire de modifier ses offres.



Les deux parties sont totalement distinctes, mais fonctionnent autour de la m&#234;me base.

En parcourant l'interface myphpadmin, j'ai trouv&#233; la possibilit&#233;
d'associer plusieurs utilisateurs &#224; la base, mais avec des droits
d'acc&#232;s diff&#233;rents. Lors de la conception, j'ai ins&#233;r&#233; deux
utilisateurs :

- anonyme repr&#233;sentant les internautes de la partie frontale avec uniquement le droit select sur les tables

- propri&#233;taire repr&#233;sentant les internautes utilisant la partie
"office" avec des droits en insert, select, update, delete sur les
tables



L'id&#233;e &#233;tait de disposer d'un  m&#233;canisme de protection
suppl&#233;mentaire de la base, sachant que les pages de la partie frontale
sont reli&#233;es &#224; un petit script utilisant uniquement la connexion avec
l'utilisateur anonyme, tandis que les pages "office" sont reli&#233;es &#224; un
script utilisant la connexion "privil&#233;gi&#233;e". Cela permettait, &#224; mon
avis, de placer une s&#233;curit&#233; au niveau de la base elle-m&#234;me, en plus
des m&#233;canismes qui peuvent &#234;tre utilis&#233;s au niveau application
(sessions, cryptage...). Les niveaux sont utiles, &#224; mon sens, parce
qu'ils permettent de figer, une fois pour
toutes, le r&#244;le de chaque internaute par rapport &#224; la base de donn&#233;es.
Tout internaute se connecte sous l'identit&#233; "anonyme" sans le savoir.
Le propri&#233;taire se connecte sous sa propre identit&#233;, &#224; travers une
entr&#233;e de session (login, mdp)



Cependant, quand j'ai voulu tester le site chez l'heb&#233;rgeur, je me suis
trouv&#233; face &#224; une interface m'interdisant la cr&#233;ation de deux
utilisateurs diff&#233;rents. En ayant fait &#233;tat &#224; travers le forum de
l'h&#233;bergeur, j'ai eu plusieurs r&#233;ponses de la part de  l'h&#233;bergeur
:

- "Bonjour, je ne comprend pas l'interet d'avoir 2 utilisateurs mysql pour
un seul site ?????? C'est la premiere fois que je vois une gestion
d'utilisateur comme ca. Normalement c'est le programme / site que tu
d&#233;veloppe qui gere les utilisateurs et non la base de donn&#233;e. La BD
sert uniquement &#224; stocker des informations"

- "Nous ne pouvons fournir 2 utilisateurs avec niveaux diff&#233;rents car
les
applications ne se font pas comme &#231;a et l'avantage serait nul"..."Le
fait d'avoir 2 utilisateurs ne prot&#232;ge en rien les donn&#233;es. Il
faudrait que celui avec les droits n'existe pas DU TOUT au niveau du
web pour que la s&#233;curit&#233; soit totale. Ce n'est pas possible puisque le
proprio doit pouvoir passer par le web pour modifier...donc s&#233;curit&#233;
inutile"



Finalement, la solution qu'il m'ont propos&#233; est d'utiliser l'unique
connexion dont dispose chaque compte (c'est &#224; dire, et ils me l'ont
bien confirm&#233; eux m&#234;me, que "Les connections &#224; la base de donn&#233;es se
feront toujours avec l'utilisateur ayant tous les droits sur la base.")
et de construire une table suppl&#233;mentaire dans la base pour stocker
l'unique utilisateur privil&#233;gi&#233;. Donc, en plus du travail suppl pour
s&#233;curiser cette table, j'ai l'impression de perdre un niveau de
s&#233;curit&#233; dans l'application.



Ma question est la suivante :

Est-ce que je me trompe dans la conception de l'application en
utilisant les utilisateurs et leurs droits disponibles directement au
niveau de la base de donn&#233;e, ou est-ce que l'h&#233;bergeur fait des
&#233;conomies sur les comptes de ses h&#233;berg&#233;s au d&#233;triment de leur
s&#233;curit&#233;  (C'est direct, mais &#231;a m'interpelle...)



Merci pour vos r&#233;ponses...

Bonne journ&#233;e..

nhervagault · Answer

Salut,

Oui, tu permets en sécurité, mais la sécurité au niveau de la base peux etre decalé sur l'application.
Car tu user guest, auras sa zone, et ton admin auras un cookie pour se propager de page en page, peux etre une connexion ssl pour l'admin, mais la je ne connais pas la mise a place de se systeme et si c'est possible en hebergement mutualise.
La solution c'est un serveur dedie mais la c'est un autre prix ;-)

bon courage.

Mindiell · Answer

Bonjour,

A mon avis, tu ne te trompes pas. Cependant, l'hebergeur n'a pas completement tort non plus, dans le sens ou la s&#233;curit&#233; est suffisante en passant par le web uniquement.
En serveur d&#233;di&#233;, ca reste une s&#233;curit&#233; de plus qui ne coute pas grand chose et qui sert toujours...

Mindiell Software

cs_AlexN · Answer

Bonjour Mindiell,



Quand je posais la question j'avais une certaine id&#233;e du type de d&#233;gats
que peut subir une base de donn&#233;e ainsi expos&#233;e avec les pleins droits
du propri&#233;taire.

Il existe une forme d'attaque appel&#233;e injection sql qui permettrait de
d&#233;tourner une requ&#234;te de son fonctionnement pr&#233;vu. Ainsi, si j'ai bien
compris, il est possible d'interroger une base, sans m&#234;me parfois
conna&#238;tre sa structure. Il suffit pour cela qu'un champ de la base soit
ouvert &#224; travers un champ de formulaire HTML (un livre d'or, une
fenetre de connexion...). Si la r&#233;ception des informations dans ce
champ n'est pas trait&#233;e, elle laisserait la porte ouverte &#224; ce genre de
dysfonctionnement.



Mon id&#233;e &#233;tait la suivante : si malgr&#233; les protections quis sont
plac&#233;es au niveau applicatif, quelquechose fonctionne mal et qu'un
utilisateur peut agir ainsi, s'il n'est que connecte &#224; la base avec un
droit select, ses actions se limiteront &#224; des lecture d'infos, tandis
que s'il est connect&#233; avec les pleins droits... (update password=""...,
delete *...)



Voila..

Peut &#234;tre que je me trompe...

Mindiell · Answer

Ah, int&#233;ressant comme attaque, mais, comme tu le dis, en v&#233;rifiant un minimum tes champs tu &#233;vites cette attaque.
Comme je l'ai dit, c'est un plus (que je pr&#233;f&#232;re moi aussi)...

Mindiell Software

cs_AlexN · Answer

Merci pour ces pr&#233;cisions.
Bonne fin de journ&#233;e.

NB. le bouton "R&#233;ponse accept&#233;e" ne fonctionne plus chez moi...

nhervagault · Answer

Salut,

Dans tes validations de champ, il suffit d'interdire les mots suivant  "delete",  ";",  "scripts" , "'"quote, ....
il faut limiter  un maximum les espaces (faire des trim sur les chaines)
Un bon moyen de valider les champs c'est d'utiliser une regexp.

En ado ou ado.net, il faut utiliser les parametres nommés des commandes.
Cela permet de ne pas s'inquité des formats (doublage des quotes)
probleme de date ....

Allez bon courage.

Sécurité des bases de données

6 réponses

Votre réponse

Discussions similaires