J’ai travaillé sur la sécurité logique basée sur les informations de l’utilisateur actuel, par exemple : « si topic.creator.username est égal à User.current().username », j’autorise l’utilisateur à modifier ou supprimer le sujet.
Le problème est que je dois garantir certaines actions en fonction de la session de l’utilisateur ! Mais j’ai effectué plusieurs tests, et c’est pour cela que je vous pose la question aujourd’hui.
Via JavaScript dans le navigateur (même en mode production), je peux exécuter Discourse.User.current().set(‘username’, ‘sometestename’). De cette façon, certaines actions de mon système seraient activées simplement grâce à cette modification. Je sais que ce n’est pas l’objectif pour 99 % des utilisateurs, mais dans ce cas précis, savez-vous comment empêcher les utilisateurs de manipuler les informations de leur compte ?
Si vous modifiez des informations dans votre navigateur local, cela ne change rien au niveau du backend.
L’utilisateur est connecté via un jeton d’authentification, je suppose, donc vous ne pouvez pas vous faire passer pour quelqu’un d’autre auprès du backend :
Puisqu’il est impossible de tromper le serveur, vous ne pourrez effectuer aucune modification en tant qu’un autre utilisateur.
Dès que vous actualiserez le navigateur, vos modifications locales seront probablement effacées. Dans le pire des cas, vous risquez de perturber l’état de l’application JavaScript et devrez supprimer votre cache.
Comme tu l’as dit, la meilleure solution serait de toujours récupérer la session de l’utilisateur actuel depuis le serveur backend.
De cette façon, les modifications du cache dans le navigateur ne pourraient pas avoir d’impact ! Sais-tu où je pourrais vérifier que la sécurité logique est basée sur la session utilisateur du serveur backend, et non sur le PreloadStore ?
N’hésite pas à me corriger si je suis sur la mauvaise voie ! Merci Robert pour ton aide !
Je ne suis pas expert en sécurité, juste un développeur d’applications, mais toutes les modifications persistantes ne peuvent être effectuées que sur le serveur. Ce qui se passe dans le navigateur avec EmberJS vise la commodité de l’utilisateur et une expérience d’utilisation supérieure, par exemple la mise en cache pour la vitesse ou un comportement d’interface automatique semblable à une application. Cela ne change pas le fait qu’en définitive, l’application doit négocier toutes les modifications persistantes avec le serveur Rails, et ce faisant, n’aura la permission de le faire que pour l’utilisateur connecté.
Il en va de même pour toutes les récupérations de données : le serveur Rails n’enverra que les données auxquelles l’utilisateur connecté a accès.
Je ne pense pas que vous ayez besoin de vous inquiéter de cela, car si quelqu’un tentait de contourner ce mécanisme, il échouerait dès le premier obstacle : il est impossible de tromper l’API.
Je suis préoccupé car je travaille sur certaines approches où une telle action sera disponible ou non selon votre utilisateur, si vous êtes le créateur du sujet, si vous êtes le créateur du message. Ainsi, je dois valider cela en fonction de la session utilisateur côté serveur.
Par exemple, sur un message, l’utilisateur peut le modifier s’il en est le créateur.
MODIFICATION : Comme pour les permissions des messages sur Discourse, je vais vérifier cela.
Vous devez d’abord mettre en œuvre toutes les mesures de sécurité côté back-end.
Les sérialiseurs Rails déterminent quelles données sont envoyées.
Le Guardian protège les actions autorisées.
Tout cela est géré par les contrôleurs Rails.
Peu importe les données erronées envoyées par le front-end ou les requêtes qu’il émet pour récupérer des informations, car ces éléments protègent le serveur.
Vous pouvez reproduire ce comportement côté front-end, mais le front-end n’est pas le gardien d’accès.
Consultez plusieurs des plus grands plugins pour voir des exemples de sérialiseurs et d’utilisation du Guardian.
J’ai analysé le code du plugin et la base de code concernant les contrôles des publications (actions), afin de déterminer où je pourrais le plus intervenir pour renforcer la sécurité.
Comme analysé ! Du côté du front-end, plusieurs étapes vérifient si l’utilisateur peut modifier ou non la publication, telles que :
1ère étape : SiteSetting.post_menu_hidden_items
2e étape : attrs.canEdit
3e étape : editPost() - !post.can_edit - controllers/topic
Cependant, même si le front-end est manipulé, une fois que la requête est envoyée au serveur back-end dans posts_controller.rb, dans la méthode :
def update
Le serveur re-requête la publication via Rails, comme ultime vérification :
