Discussion :

[kisitomomotene]

Salut à tous

Après certaine reflection et analyse, je trouve que deployer aujourd'hui des application en client/serveur est dangereux en terme sécurité, et doit même être interdit.

Je rappelle d'abord que j'entend par client/serveur, l'architecture ou les postes clients sont en communication directe avec la base de donnée.
Alors ce qui se passe souvent, une bonne partie de la logique metier se trouve sur le poste client. Alors pirater devient très simple. imaginer par exemple que sur un poste client une application java est deployé sous forme d'un fichier archive "monappli.jar". il me suffit d'écrire un programme où "monappli.jar" sera dans le classpath, et j'aurais alors accès à toutes les classes de "monappli.jar" et je pourrais executer certaine methode dont normalement je ne devrais avoir accès. Or très souvent les régles de sécurités sont définies au niveau du code de contrôle de l'acquisition de donnée et rarement au niveau de toute les methodes publics de l'application. Combien de personnes ici ecrivent systématiquement les codes de contrôle de sécurité à l'entrée de toutes leurs methodes public?
Un autre problème, les postes clients sont en contact direct avec la BD, et la BD contient souvent des données sensibles et importante d'une entreprise. S'il y a une faille de sécurité sur la BD, un utilisateur peut l'exploiter, puisqu'il est en connexion directe avec la BD.

Pour ces raisons et bien d'autre, je trouve que si on doit developper une application d'entreprise, on doit impérativement le faire suivant une architecture n-tiers. Si on a déjà une application développée suivant une architecture client/serveur, on doit deployer cette application suivant une architecture 3-tiers en utilisant Citrix/Terminal Server/VNC etc..

[Tofalu]

Bonjour,

Pour se connecter à une base de données, il faut être identifier. Les autorisations sont définies dans la base de données. Et les règles d'intégrité permettent de garder la cohérence des données.

S'il y a une faille de sécurité sur la BD

Quelque soit l'architecture. Tu peux même être en architecure 2021ème tiers, si la base n'est pas sécurisée, elle est vulnérable.

monappli.jar" sera dans le classpath, et j'aurais alors accès à toutes les classes de "monappli.jar"

Je ne connais pas java. Mais j'ose espérer qu'il est possible de définir où et par qui peuvent être instanciée les classes. De même que toutes les méthodes ne sont pas publiques.

[kisitomomotene]

Bonjour,

Pour se connecter à une base de données, il faut être identifier. Les autorisations sont définies dans la base de données. Et les règles d'intégrité permettent de garder la cohérence des données.

Oui mais je crois (mais je ne suis pas sûr) que les règles de sécurité dans une Bd sont "statique", on ne peut pas définir une règle d'accès au resource dynamiquement en fonction du contexte d' execution de l'application.
D'autre part très souvent le code qui accède à une BD en arrière plan le fait avec un identifiant propre qui à souvent le maximum de privilège. En effet les programmeurs suppose que l'utilisateur passera tjrs par les formulaires de l'application pour accèder à la BD et met le code de contrôle au niveau de ces formulaires en amont du code d'accès aux données.

Quelque soit l'architecture. Tu peux même être en architecure 2021ème tiers, si la base n'est pas sécurisée, elle est vulnérable.

On parle bien sur de dimunier le risque d'attaque. Lorsque tous les utilisateurs ont directement accès à la BD à partir de leur poste de travail, le risque est 2021 x nbr_utilisateurs x niveau_de _la_faille plus élévé que s'il y avait 2021 couche devant la BD.

[anas.eh]

Salut tout le monde,

Je suis désolé parce que je ne vois pas où est le problème, je vois qu'une vulnérabilité n'existe que parce que l'application développée possède une certaine faille et non pas c'est parce que l'architecture client/serveur toute entière est vulnérable (c'est ce que notre ami voulait dire ?).

En plus, si on veut parler en terme de base de données, soit une base de données BD et un client X qui veut accéder à BD, les droits d'accès pourront l'empêcher de faire quoi que se soit, c'est-à-dire ce client X peut voir (select) | éditer (update,set,delete) seulement une seule (ou un nombre n de) table(s) de BD, une vue d'un ensemble de tables de BD, toutes les tables ou bien absolument rien de rien.

Là on a supposé que ce client a déjà accédé au poste où il y a cette BD, il peut être refusé même au début, le serveur peut nottament refusé les données du client donc il ne peut même pas espérer demander accès au SGBD.

A mon avis, tout dépend de la sécurité qu'on a mis en place durant le développement de notre application.

Quelque soit l'architecture. Tu peux même être en architecure 2021ème tiers, si la base n'est pas sécurisée, elle est vulnérable.

Parmis mes 2021 tiers si tu rattes un tier non sécurisé tu es mort.

Je suis d'accord seulement sur le point que l'architécture C/S est beaucoup plus exposée aux vulnérabilités parce que quoi qu'on fasse on laissera surement une faille derrière nous et si cette faille est découverte par un pirate on est mort.

Bonne journée,

[souviron34]

Salut à tous

Après certaine reflection et analyse, je trouve que deployer aujourd'hui des application en client/serveur est dangereux en terme sécurité, et doit même être interdit.

Je rappelle d'abord que j'entend par client/serveur, l'architecture ou les postes clients sont en communication directe avec la base de donnée.

Là tu me laisses... pantois...

C'est un biais de programmation et de conception de gens ne comprenant pas bien la notion de client-serveur qui peut amener à une telle architecture...

Le principe de client-serveur, comme son nom l'indique, indique qu'un client soumet une requête à un serveur.

Cela n'a rien à voir avec une base de données, bien que cela puisse être appliqué à cela.

Dans le style d'applications dont tu parles, les clients sur les postes clients parlent (devraient parler) à un serveur qui LUI interface la BD.

Alors ce qui se passe souvent, une bonne partie de la logique metier se trouve sur le poste client. Alors pirater devient très simple. imaginer par exemple que sur un poste client une application java est deployé sous forme d'un fichier archive "monappli.jar". il me suffit d'écrire un programme où "monappli.jar" sera dans le classpath, et j'aurais alors accès à toutes les classes de "monappli.jar" et je pourrais executer certaine methode dont normalement je ne devrais avoir accès. Or très souvent les régles de sécurités sont définies au niveau du code de contrôle de l'acquisition de donnée et rarement au niveau de toute les methodes publics de l'application. Combien de personnes ici ecrivent systématiquement les codes de contrôle de sécurité à l'entrée de toutes leurs methodes public?

Cela encore n'a rien à voir, mais a à voir avec langage compilé ou dynamique...

Un programme compilé installé sur un poste client ne pourra être utilisé que pour ce pour quoi il a été conçu. Un programme utilisant un langage semi-compilé, compilé au vol, ou encore pire en script, est effectivement susceptible d'être modifié par à peu près n'importe qui.. Faire un patch dans un binaire est autrement plus délicat...

Un autre problème, les postes clients sont en contact direct avec la BD, et la BD contient souvent des données sensibles et importante d'une entreprise. S'il y a une faille de sécurité sur la BD, un utilisateur peut l'exploiter, puisqu'il est en connexion directe avec la BD.

Voir point 1...

Pour ces raisons et bien d'autre, je trouve que si on doit developper une application d'entreprise, on doit impérativement le faire suivant une architecture n-tiers. Si on a déjà une application développée suivant une architecture client/serveur, on doit deployer cette application suivant une architecture 3-tiers en utilisant Citrix/Terminal Server/VNC etc..

Et quelle est la différence à ton avis ?

une n-tiers est basée sur la notion de client-serveur....

[kisitomomotene]

Là tu me laisses... pantois...

C'est un biais de programmation et de conception de gens ne comprenant pas bien la notion de client-serveur qui peut amener à une telle architecture...

Le principe de client-serveur, comme son nom l'indique, indique qu'un client soumet une requête à un serveur.

Cela n'a rien à voir avec une base de données, bien que cela puisse être appliqué à cela.

Dans le style d'applications dont tu parles, les clients sur les postes clients parlent (devraient parler) à un serveur qui LUI interface la BD.

L'expression client serveur est un abus de langage pour designer une architecture 2 tiers

Cela encore n'a rien à voir, mais a à voir avec langage compilé ou dynamique...

Un programme compilé installé sur un poste client ne pourra être utilisé que pour ce pour quoi il a été conçu. Un programme utilisant un langage semi-compilé, compilé au vol, ou encore pire en script, est effectivement susceptible d'être modifié par à peu près n'importe qui.. Faire un patch dans un binaire est autrement plus délicat...

justement non. Si on a developper une appli à base de composant reutilisable ( activeX, corba) ou bien si on a utiliser un langage comme java, les methodes publique seront toutes accessibles à travers des programmes clients des composants.
Alors j'expose par un exemple une faille de sécurité qui peut être liée à l'architecture 2 tiers elle même. Je suppose que dans une appli on veuille empêcher un utilisateur X de suspendre le compte d'un client. Ce qui se passe très souvent, on va empêcher à l'utilisateur X d'accèder au formulaire de suspension de compte, ou bien on va l'empêcher d'avoir accès aux contrôles du formulaire qui permettent de suspendre les clients ( et ces droits d'accès sont définis au moment de la configuration, et ne sont pas codés en dur). je suppose qu'en arrière plan, on ait une classe "MonClient.class" avec la methode public "suspendre()" pour gérer effectivement les suspensions, on peut accèder à cette methode depuis n'importe quel environnement de developpement, et ce qui était impossible à travers l'interface utilisateur de l'appli est possible à travers un programme client de la classe "MonClient.class".
L'architecture n-tiers (notamment j2ee) permet de résoudre ce problème en définissant les règles de sécurités, au niveau des methodes.

Et une façon pour contourner ce problème quand on a une appli 2 tiers, est de deployer cette appli en architecture 3 tiers en utilisant les technologies Citrix/Terminal server/VNC etc.

[nicØB]

Je ne vois vraiment pas où est le problème. Si le logiciel client est modifié pour que son utilisateur puisse accéder à des fonctions "interdites", c'est que tu t'y es mal prit.

Quand on fait du client/serveur, on vérifie toutes les requêtes envoyer par le client au serveur.
Dans ton exemple, il va appeler la méthode suspendre. Et bien c'est à toi de faire les vérifications sur ton serveur pour appliquer ou non les modifications que cela implique.

Et avec un site web tu fais comment ? C'est exactement le même problème non ? Tu ne vas pas faire les vérifications via du javascript.
Tu les fais sur le serveur, le navigateur n'étant qu'une interface.

L'architecture n-tiers (notamment j2ee) permet de résoudre ce problème en définissant les règles de sécurités, au niveau des methodes.

Comme l'a dit souviron34, une architecture n-tiers est basée sur du client/serveur...

[souviron34]

...justement non. Si on a developper une appli à base de composant reutilisable ( activeX, corba) ou bien si on a utilisé un langage comme java, les methodes publique seront toutes accessibles à travers des programmes clients des composants.
...

Je vois que tu n'as pas compris ce que je disais : tu cites Java (au max pré-compilé, sinon au vol), Corba (qui n'est qu'un outil intégré dans un autre)..

Si tu fais un .exe (sous Windows) ou un binaire (sous par exemple Linux/Unix), (avec C, Pascal, C++, Fortran, ..... n'importe quel langage compilé) et que ce binaire est distribué sur les postes clients, même si il se sert de Corba, absolument RIEN ne sera modifiable par le client qui ne soit pas autorisé...

Donc je reprend mon explication : la notion de client-serveur n'a absolument rien à voir avec ça... La faille de sécurité est au niveau du choix du langage utilisé. Un client-serveur avec binaires installés est 100% fiable (en tous cas par rapport à tes aguments) .

[Jedai]

Je vois que tu n'as pas compris ce que je disais : tu cites Java (au max pré-compilé, sinon au vol), Corba (qui n'est qu'un outil intégré dans un autre)..

Si tu fais un .exe (sous Windows) ou un binaire (sous par exemple Linux/Unix), (avec C, Pascal, C++, Fortran, ..... n'importe quel langage compilé) et que ce binaire est distribué sur les postes clients, même si il se sert de Corba, absolument RIEN ne sera modifiable par le client qui ne soit pas autorisé...

Donc je reprend mon explication : la notion de client-serveur n'a absolument rien à voir avec ça... La faille de sécurité est au niveau du choix du langage utilisé. Un client-serveur avec binaires installés est 100% fiable (en tous cas par rapport à tes aguments) .

Mais bien sûr... Et les crackers modifient quotidiennement les binaires de centaines de programmes. Quand tu sais quoi chercher, il est possible (et pas si dur) de faire des patchs à un binaire. Alors bien sûr c'est plus difficile, et le niveau technique des crackers capable de cela est nettement plus élevé que celui nécessaire pour modifier du code source dans un langage interprété (ou pour les autres suggestions faites dans ce sujet). Mais il n'en reste pas moins que c'est possible, et même que c'est fait fréquemment.

La question n'est pas le langage utilisé, mais simplement la sécurité au niveau du serveur (qui lui n'est pas sur la machine du client et ne peut pas sur une machine non compromise être modifié par lui), c'est lui qui doit contrôler la validité et l'innocuité des requêtes qui lui sont soumises, pas présumer que le client est sûr parce qu'il a été écrit dans un langage compilé. Si cette condition est respectée, l'architecture client/serveur est parfaitement sûre (modulo les failles courantes dans les logiciels écrit dans des langages comme le C où il y a d'innombrables occasions d'en introduire par inadvertance, et bien sûr les failles dans la logique de l'application, quel que soit le langage).
Les architectures N tiers sont peut-être un peu plus sûres, mais il arrive également qu'elles induisent un faux sentiment de sécurité qui amène à relâcher sa vigilance...

--
Jedaï

[souviron34]

je ne peux qu'être d'accord, cependant par rapport au PO et à ses remarques suivantes, il s'agissait d'utilisateurs, pas de crackers..

Et par conséquent je maintiens qu'utiliser un langage compilé pour un utilisateur "normal" réduit à 0% la possibilité.

Maintenant bien évidemment la fin mot de l'histoire réside effectivement dans le serveur final...

Quant aux crackages, t'en connais beaucoup sur des systèmes non-pc ??

Mais bien évidemment rien n'est absolument full proof.

En tous cas, mon point est que l'aspect sécurité n'a rien à voir avec l'architecture client-serveur..

[Janitrix]

En tous cas, mon point est que l'aspect sécurité n'a rien à voir avec l'architecture client-serveur..

Je suis tout à fait d'accord avec toi sur ce point, et je ne pense pas dire de bétise en disant que cette architecture est aujourd'hui majoritaire, et que c'est n'est pas pour rien. Sa simplicité est justement réconfortante. Et en ce qui concerne la sécurité, encore un fois, cela dépend entièrement de l'implémentation qui en est faite : une mauvaise implémentation peut amener des trous de sécurité. Mais cela est vrai pour l'informatique en général, donc il n'y a rien de nouveau.

[welcome_59]

Quant aux crackages, t'en connais beaucoup sur des systèmes non-pc ??

Ce sont les systèmes les moins utilisés. Il me semble donc logique que les crackages soient moins nombreux.

[deltree]

Il me semble qu'il faut être précis sur les architectures utilisées.
Ici on parlait au début de 2-Tiers (donc application cliente et base de données "serveur"), puis de 3-tiers qui est pour moi le vrai client-serveur.

Les problèmes essentiels du 2-Tiers sont:
1. que la sécurité est gérée au niveau BD, donc "en général" avec un seul user technique commun à tous le monde. Mais on peut aussi introduire de la sécurité directement au niveau BD avec un user de connection par personne, et des procédures stockées pour garantir l'intégrité fonctionnelle.
2. que le code source "fonctionnel" est sur le poste client donc décompilable ou sourcable, donc potentiellement modifiable


En 3 tiers ou plus, on reporte la sécurité sur le serveur application en non pas sur le client. Une architecture intranet (serveur d'appli Web) est une sorte de 3-tiers, et on ne place jamais la sécurité directement sur le client (en HTML/Javascript) qui est réputé non-fiable.

Je suis tout à fait d'accord avec toi sur ce point, et je ne pense pas dire de bétise en disant que cette architecture est aujourd'hui majoritaire, et que c'est n'est pas pour rien. Sa simplicité est justement réconfortante. Et en ce qui concerne la sécurité, encore un fois, cela dépend entièrement de l'implémentation qui en est faite : une mauvaise implémentation peut amener des trous de sécurité. Mais cela est vrai pour l'informatique en général, donc il n'y a rien de nouveau.

Justement je n'ai pas compris ce qui à ton avis était majoriataire, j'ai personnellement vu de l'intranet, du 3-tiers Corba/java, et du 2-Tiers avec une gestion de la sécurité directement en BD. (modules équivalent de proc stock)
pour moi le type d'application "intranet" est le plus standard et fiable à mettre en place, mais pas forcément encore très utilisé.

[koala01]

Si tu part sur le fait que le client irait directement "attaquer" un serveur de base de données, il n'y a rien à faire, il faut que ce soit l'utilisateur qui fournissent les identifiants nécessaires à l'accès à la base de données, et qu'il ne soient en aucun cas maintenus "en dur"...

J'aurais même tendance à dire qu'il doivent avoir une période de validité, éventuellement remise à zéro quand une requête est effectivement envoyée, histoire d'assurer que, si par malheur, j'"oublie" de quitter l'application avant de sortir de mon bureau, que mon voisin ne puisse pas se faire passer pour moi (ou du moins de limiter les risques)...

Il est clair que, si tu écris "en dur", que ce soit dans une constante globale, ou dans un fichier d'initiation, les informations de connexion "full rights", tu vas sérieusement compromettre la sécurité de la base de données...

Je suis tout à fait d'accord avec le fait que la sécurisation du client doit être prise en compte et que cela interdit de faire du "grand n'importe quoi"

Mais si tu oblige, d'une manière ou d'une autre, l'utilisateur à s'identifier, je ne vois, a priori, pas pourquoi il faudrait éviter de créer un client, même s'il est en langage (semi) interprété, qui fournirait à la base de données les identifiants... que le client a reçu de la part de l'utilisateur...

Ce sera alors à la base de données de décider, en fonctions des droits déclarés pour les utilisateurs, si elle accepte que l'utilisateur effectue la requête demandée...

[deltree]

Le gros inconvénient de cette méthode est de devoir gérer les utilisateurs dans l'administration de la base de données, on ne peut donc pas gérer son propre système de sécurité, (sauf en le synchronisant avec la gestion de base de données)
Je deviens alors dépendant de mon DBA pour la gestion des utilisateurs: ça se fait là ou je suis, mais il faut en être conscient.

[koala01]

Mais, inversement, tu gagne en souplesse du côté de ton application client...

Si, au lieu d'attaquer le serveur truc, tu veux attaquer le serveur brol, qui peut d'ailleurs être une autre SGDB, tu change l'ip, le port (éventuellement), et le tour est joué ...

Bon, après, il y a certaines incompatibilités SQL entre certains SGDB...

[GrandFather]

Le gros inconvénient de cette méthode est de devoir gérer les utilisateurs dans l'administration de la base de données, on ne peut donc pas gérer son propre système de sécurité, (sauf en le synchronisant avec la gestion de base de données)

Généralement on ne gère pas individuellement les utilisateurs dans le SGBDR, mais uniquement x utilisateurs génériques correspondant chacun à un rôle fonctionnel spécifique, à moins qu'on ne veuille tracer les actions de tous les utilisateurs.

S'il est nécessaire que tous les utilisateurs réels soient référencés au niveau du SGBDR, on peut utiliser la possibilité qu'ont certains SGBDR de partager la même base d'utilisateurs que celle de l'OS qui les héberge (ex: PostgreSQL avec les comptes d'utilisateurs d'Unix).

[Emmanuel Deloget]

Ce sont les systèmes les moins utilisés. Il me semble donc logique que les crackages soient moins nombreux.

Cela dépends fortement du système que tu considère (cf. les consoles de jeux vidéo, qui sont une cible privilégiée malgré leur architecture fermée). Mais on s'éloigne du principe du débat.

Débat que j'ai un peu de mal à suivre d'ailleurs. Si l'idée de base est que une fois les sécurités d'un SGBD ouverte (par n'importe quel moyen) n'importe qui peut faire ce qu'il veut, alors oui, l'utilisation d'un SGBD peut poser des problèmes de sécurité (qu'on soit en mode client serveur ou non d'ailleurs: supposons que SQLite intègre une couche de sécurité. Si mon API/assembly/jar contient tout ce qu'il faut pour passer outre cette couche de sécurité (notamment login, mots de passes) alors elle ne me sert à rien et mas base de donnée est vulnérable).

La notion de sécurité d'une architecture client/serveur tient en une unique phrase: "never trust the client". Si le serveur commence à faire confiance au client alors il est vulnérable. En soit, ça n'a rien à voir avec la façon dont le client est codé - l'idée est d'autoriser uniquement les opérations qui ne mettent pas en danger l'intégrité du serveur. Par conséquent, un accès direct à une base de donnée est à proscrire, et il sera préférable d'implémenter la logique métier au niveau du serveur plutôt qu'au niveau du client.

Mais au final, tout cela n'a de sens que si vous travaillez dans un environnement ou vous avez un vrai besoin de sécurité. Si votre logiciel est installé sur un serveur du CEA sans conection (directe ou indirecte) avec le monde extérieur, si les postes clients ne sont utilisés que par des techniciens confirmés et si une malfonction dans votre programme ne fait pas exploser Iter, "KISS" (principalement parce que, sait-on jamais, il se pourrait que "je" prenne en charge la maintenance de votre système ("je" étant un pronom indéfini représentant un informaticien moyen)).

[davcha]

Donc je reprend mon explication : la notion de client-serveur n'a absolument rien à voir avec ça... La faille de sécurité est au niveau du choix du langage utilisé. Un client-serveur avec binaires installés est 100% fiable (en tous cas par rapport à tes aguments) .

Ca a pas trop à voir avec le langage selon moi, ou le fait qu'il soit ou non compilé.

La seule question à se poser est de savoir si le serveur se demande "est-ce que le client actuel a vraiment le droit de faire ça ?"

[souviron34]

Je répondais à cette partie-là :

...Alors pirater devient très simple. imaginer par exemple que sur un poste client une application java est deployé sous forme d'un fichier archive "monappli.jar". il me suffit d'écrire un programme où "monappli.jar" sera dans le classpath, et j'aurais alors accès à toutes les classes de "monappli.jar" et je pourrais executer certaine methode dont normalement je ne devrais avoir accès.
...

Visiblement ce que le PO avait en tête, c'était les langages non-compilés, avec code source pouvant être édités (même si avec quelques manips)...