Sécurité Java EE - clients d'application

Question

Je suis en train d'écrire sur un projet Java EE qui aura tout de 3 à 6 clients différents. Le projet est open source, et je me demande quels mécanismes de sécurité on pourrait/devrait utiliser. Le problème est: Parce qu'il est open source, je crois qu'il est possible pour n'importe qui avec un utilisateur d'écrire son propre client (peut-être pas réaliste, mais vraiment possible) et de prendre contact avec le serveur/base de données. J'ai essayé de passer par tous les scénarios de lecture/écriture des données différentes à la base de données des rôles différents, et je conclus là-dessus que je dois avoir un mécanisme de sécurité à un niveau supérieur à celui (il est pas assez pour vérifier si ce type de compte est autorisé à persister cette entité avec cet ID et ainsi de suite ...). D'une certaine manière, je dois savoir que le client qui prend contact est le bon client I a écrit. Est-ce que la signature des fichiers Jar pourrait résoudre tout ce problème, ou y a-t-il d'autres façons de le faire?

-Yngve

Answer 1

Eh bien la source peut être disponible pour tout le monde, mais la configuration du déploiement et de la base de données est certainement pas. Lorsque vous déployez l'application, vous pouvez ajouter des utilisateurs avec des rôles. La chose la plus simple à faire est de les conserver dans une base de données. Bien sûr, le contenu de la table ne sera accessible qu'à l'administrateur de la base de données. L'administrateur de la base de données va configurer l'application pour qu'elle puisse accéder aux tables requises. Lorsqu'un utilisateur tente de se connecter, il doit fournir un nom d'utilisateur et un mot de passe. L'application lira la table pour authentifier/autoriser l'utilisateur.

Ce type de sécurité est le plus courant. Pour être vraiment sécurisé, vous devez transmettre les informations d'identification via un chemin sécurisé (HTTPS). Pour plus de sécurité, vous pouvez utiliser l'authentification client HTTPS. Vous le faites en générant une clé publique pour chaque client et en la signant avec la clé privée du serveur. Ensuite, le client doit envoyer cette clé signée à chaque demande.

EDIT: Un utilisateur étant capable d'écrire son/son propre client ne fait pas l'application moins sûr. Il/elle ne sera toujours pas en mesure d'accéder à l'application, s'il est nécessaire de se connecter en premier. Si la connexion réussit, une session (cookie) sera créée et sera transmise à chaque requête. Jetez un oeil à Spring security. Il a une courbe d'apprentissage plutôt abrupte, mais si vous le faites une fois, vous pouvez ajouter de la sécurité dans n'importe quelle application en quelques minutes.

Answer 2

Je pense vraiment que si restreindre les activités disponibles sur le côté serveur (en fonction du rôle) ne suffit pas, que vous avez un problème plus grave. Même si un utilisateur n'écrit pas son propre client, le mécanisme que vous utilisez pour vos appels à distance risque d'être intercepté et manipulé. L'essentiel est que vous devriez limiter les appels possibles qui peuvent être faits contre le serveur, et traiter chaque appel au serveur comme potentiellement malveillant. Pouvez-vous penser à un exemple de scénario dans lequel une action serveur qu'un utilisateur authentifié particulier serait autorisé à prendre serait acceptable s'il utilisait votre client mais était dangereuse s'il n'utilisait pas votre client? Si c'est le cas, je dirais que vous comptez trop sur votre client.

Cependant, plutôt que de critiquer juste que je voudrais essayer d'offrir aussi des réponses réelles à votre question ainsi. Je ne pense pas que la signature de votre fichier jar sera suffisante si vous imaginez un utilisateur malveillant; En général, la cryptographie à clé publique peut ne pas vous aider car l'utilisateur malveillant hypothétique qui recompose votre source aura accès à votre clé publique et ainsi usurper l'authentification que vous avez créée.

En fin de compte, il faut quelqu'un dans le système en qui vous avez confiance, et vous devez donc déterminer qui c'est et baser votre sécurité autour d'eux.Par exemple, imaginons qu'il peut y avoir de nombreux utilisateurs dans une entreprise particulière à laquelle vous ne faites pas confiance, et un administrateur qui les supervise, à qui vous faites confiance. Dans ce scénario, vous pouvez configurer votre client de sorte que l'administrateur doit entrer un code spécial au démarrage, et que ce code soit conservé en mémoire et transmis avec toute demande. De cette façon, même si l'utilisateur reverse votre code, il n'aura pas le code d'admin. Bien sûr, les appels de votre client à votre serveur seront toujours vulnérables à être interceptés et manipulés (sans compter que cette exigence serait une douleur royale dans le cou pour vos utilisateurs).

Ligne de fond: si l'ordinateur de votre utilisateur appelle votre serveur, alors votre utilisateur appelle votre serveur. Ne faites pas confiance à votre utilisateur. Limitez ce qu'ils peuvent faire, peu importe le client qu'ils utilisent.