Authentification Sécurité avec GWT : Sécuriser les servlets

C'est simple, je reprend le code du projet Contact disponible sur l'aide de GWT (Building Large Application)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public ContactsServiceImpl() { getThreadLocalRequest().getSession().getAttribute("toto"); initContacts(); } private void initContacts() { // TODO: Create a real UID for each contact // for (int i = 0; i < contactsFirstNameData.length && i < contactsLastNameData.length && i < contactsEmailData.length; ++i) { Contact contact = new Contact(String.valueOf(i), contactsFirstNameData[i], contactsLastNameData[i], contactsEmailData[i]); contacts.put(contact.getId(), contact); } }

---

Cela va planter si c'est le premier appel à une RemoteServiceServlet.

Quand je regarde ce code, je comprend le null pointer exception.

Résumons le pourquoi :

• Google nous impose d'hériter d'une servlet technique pour implémenter un service RPC. On utilise donc les signatures de méthodes de notre service et non les classiques doGet/doPost.
• On perd donc l'accès à HttpServletRequest et HttpServletResponse or ceci est embétant car on peut en avoir besoin pour faire plein de chose, accéder à la session en autre (même si c'est à éviter pour du stateless), ...
• Il fallait qu'ils trouvent un moyen pour nous filer une référence dessus. Ils ont éviter d'utiliser la première idée qui vient au débutant : les variables d'instances car si la servlet est utilisée par plusieurs threads simultanément, ça ne vas pas le faire. Ils stockent donc ces objets dans un espace mémoire du thread courant pour qu'on puisse y accéder par la suite.
• Il est fort possible que le constructeur soit appelé la 1° fois avant que la 1° requête n'ait été mise dans cet espace mémoire d'où le null pointer.

Intriqué par la source de ton exemple (la ligne en rouge ne sert à rien), j'ai télécharger le code source à
http://code.google.com/webtoolkit/do.../Contacts2.zip
et cette ligne n'y est pas !

L'essentiel de cette histoire, c'est de retenir :
On ne gère pas le cycle de vie des servlets, c'est le conteneur qui s'en occupe. Est-ce que le conteneur crée la servlet au démarrage ou à la première requête ? et que se passe t'il s'il la partage entre plusieurs thread ?

Dans les servlets, mon conseil : ne pas toucher au constructeurs, ni utiliser de variable d'instance sauf si on sait ce qu'on fait.

C'est normal que tu ne la trouve pas, c'est moi qui l'ai ajoutée pour te montrer le cas.
J'ai pris comme exemple leur code car je me suis basé dessus pour l'architecture du projet (MVP, rpc etc..). Ils traitent du code dans le constructeur, je me suis donc basé su ce qu'ils font sauf que j'avais besoin d'une info en plus.

Pour ce qui est du stateless. Tellement pratique, perso, je n'ai mis que le login. :D

Ce qui est étonnant, c'est que quand on appelle une servlet classique en premier. la deuxième partage le même id de session donc instinctivement je me suis dit qu'ils partageaient le même thread. Et bien ça plante quand même.

A+

En tout cas sinon, comment gères tu l'affichage en fonction de l'utilisateur connecté?

Par exemple le projet exemple de Google "Contact" propose un service avec une liste de Contact mais comment faire si cette liste est personnalisé en fonction de l'utilisateur connecté?

En effet, le service créé une hashmap de tout les utilisateurs du coup comment faire pour la limiter? revenir vers la BDD à chaque fois et recharger la liste?
Parceque la variable est d'instance :/

Code:

---

private final HashMap<String, Contact> contacts = new HashMap<String, Contact>();

---

Une application se résume en gros à faire transiter des flux de données entre le repository choisi (base de données, fichiers, ... sur le serveur) et l'interface graphique (ihm cliente).

Si pour des raisons de performance, on souhaite les mettre en "cache", on peut intervenir à différents niveaux avec des avantages/inconvénients.
côté client : cookies, cache du navigateur, modèle objet javascript
côté serveur : modèle objet java, session, fichiers/bdd

Sans entrer dans le détail de chacune de ces solutions, disons que :
soit on utilise une session (côté serveur ou côté client) : état à gérer avec le problème de l'expiration, actualisation des données
soit on échange les données à chaque fois (pas de session) : pas d'état à gérer mais trafic supplémentaire.
Il n'y a pas de secret : ce qu'on gagne en temps (avec des caches), on le perd en espace et vice versa ... Il faut trouver le bon compromis pour une situation donnée.

Pour des données communes à plusieurs utilisateurs, tu peux les stocker dans le modèle objet de ton application.
Si c'est des données propres à chaque utilisateur, soit tu vas les rechercher en bdd à chaque fois, soit tu essayes d'en stocker côté client (dans le modèle objet javascript), soit tu en stockes dans la session http côté serveur.

Et si je préfère une application stateless pour une application à millions d'utilisateurs, pour une application à seulement quelques dizaines d'utilisateur (< 100), je pense que la session http côté serveur répond à ce besoin.

L'intégration d'un conteneur EJB avec une gestion stateful peut aussi permettre de gérer les sessions pour les users. A savoir que le stateful renverra des infos sur la partie cliente en cas d'une demande d'une ressource ou alors enregistrera une session lors de la première connections.

Le souci est comme tu le définis de savoir ce que l'on veut faire. De la performance pure ou alors une gestions précise de la gestion des sessions (Stateful).

Qu'en pensez vous ?

Bonjour,

Je développe actuellement une application GWT (client GWT + RPC et servlet TOMCAT)

Je souhaite avoir une architecture stateless, c'est à dire :
1) l'utilisateur se connecte à l'application => je vérifie son pasword dans la servlet
2) ensuite je stocke des informations contextuelles dans un objet javascript (mais je n'utilise pas de numéro de session) que je passe à chaque appel de mes servlet en utilisant le mécanisme RPC. Je ne fais donc ensuite aucun contrôle de connection dans mes servlet.

Je voudrais savoir si il existe une faille de sécurité dans ce type d'architecture ?

Merci

Les deux limites que j'imagine :

1) Si un "pirate" arrive à deviner ou à capturer le code qui transite à chaque fois pourrait se faire passer pour ton utilisateur.
Cela est très proche du vol d'identifiant de session bien que peut être moins devinable, moins formalisé. Et s'il ne faut pas compter sur l'obfuscation comme élément de sécurité, le vol d'identifiant de session n'est pas le plus répandu et utilise pas mal l'ignorance des utilisateurs.

2) L'autre risque (mais c'est également un avantage suivant le point de vue) c'est que tant qu'il n'y a pas de mécanisme d'expiration de session et tant que le navigateur est ouvert, on peut exécuter des actions personnelles. Ceci n'est pas bien gênant tant que l'utilisateur ne surfe pas dans un cybercafé en laissant le navigateur ouvert.

Whaou !

ça c de la réactivité !

Merci pour ces explications très claire !

Bonjour,

Pour moi c'est un risque de sécurité. La Servlet doit impérativement vérifier l'utilisateur à chaque appel.

Mes applications sont en state-less, j'utilise le websso pour l'authentification. L'id que le sso envoie à ma servlet me permet de vérifier l'authentification avec l'utilisateur qui se trouve dans ma base de donnée. pour améliorer les performance j'utilise la session uniquement pour éviter de faire une requete en BDD à chaque appel rpc en y stockant les info de l'utilisateur.

J'ai donc une session utilisé uniquement pour des raisons de perf. Mais tous le fonctionnel de l'appli reste en state-less.

pvoncken, tu vérifies avec ta session.
Pour retrouver ta session, un identifiant de session est échangé entre client et serveur .

Si son objet qu'il transmet joue le même rôle (avec plus d'information cependant), s'il n'est pas devinable/modifiable bien entendu, je ne vois pas en quoi ça serait plus risqué ?

Cela dépend plus de ce que représente son objet javascript et si les données qu'il véhicule sont compréhensible.


Pour en revenir à ton histoire de session, as tu des mesures de différences de performance (par curiosité) car tu perds un avantage du staleless selon moi. L'intérêt du stateless, c'est de pouvoir être load balancé sur n'importe quel serveur mais si ta session ne s'y trouve pas, cela va lui redemander de s'authentifier, n'est ce pas.
Je peux comprendre l'utilisation de session (toutes les appli n'ont pas une charge énorme), je peux imaginer que la différence de performances soit significative. En revanche, je ne comprends pas bien l'intérêt d'un "tout stateless" sauf pour l'authentification. Quelque chose à du m'échapper ... Peux tu m'éclairer ?

Avec la couche websso, je ne pense pas que cela revienne au meme avec un objet géré à la main. Le WebSSO garantie l'authentification avec des mécanismes de sécurisation du token de session.

Au niveau du tout stateless sauf l'authent, c'est par rapport à mon contexte. Je reste au maximum stateless pour pouvoir me soumettre facilement à du load balancing. Il n'y a que l'authent avec lequel j'utilise la session car on a une api déjà toute faite qui récupère les infos du websso et qui les stocks en session.

Par contre le jour où j'ai besoin de faire du load-balancing, je n'aurais que la couche d'authent à modifier.

Pour le load-balancing on peut également choisir la stratégie du sticky qui permet de balancer les requetes sur un serveur en fonction du token de session. Cette stratégie me permettrait de ne même pas modifier mon authent. Stratégie que tu ne pourra pas mettre en place si tu utilise autre chose que le token standard de session.

De plus, Le state-less permet également de sécuriser la persistance en évitant de perdre des infos qui serait en session.

Merci pour tes précisions. Ton point de vue se défend.

Pour ma part, si ton approche est plus "standard", "éprouvé", ... je pense néanmoins que l'échange d'un objet identifiant l'utilisateur (pour peu qu'il soit bien fait) n'est pas un risque énorme et apporte l'avantage qui est une application full stateless qui n'expire pas tant que le navigateur n'est pas fermé.

Je concède néanmoins que cela peut être un inconvénient pour d'autres points de vues.