Discussion :

[sekaijin]

Bonjour.

Je viens de lire un article qui est l'exemple typique à ne pas suivre.
Cet article propose une méthode pour faire une application sécurisée en JS avec Extjs.

Mais la conception est surtout ce qu'il ne faut pas faire. Donc peu importe la librairie. Le principe mis en oeuvre repose sur AJAX.

Je ne jetterais pas la pierre à son auteur. Vous trouverez l'article ici.

voici le principe de l'application
Au démarrage, le serveur envoi une page HTML qui charge un JS qui affiche un formulaire de login.
Lorsque l'utilisateur le valide, une requête AJAX demande au serveur les informations sur l'utilisateur.
Lorsque la réponse arrive, le JS vérifie que l'utilisateur est autorisé et affiche l'interface de l'application.

C'est ce principe qu'il ne faut JAMAIS suivre.
La raison est très simple: n'importe quel utilisateur un peu bricoleur peut passer outre.
dans l'exemple de l'article il suffit de mettre un point d'arrêt dans le listing 3 ligne 29
Une fois la variable data créée, il suffit de positionner la valeur data.firstName pour être autorisé.

On peut toujours essayer de sécuriser ce code, cela ne changera jamais rien. Il sera toujours possible pour quelqu'un d'intervenir sur le traitement de la réponse et de passer outre.

De plus avant même que l'utilisateur ait tenté de se loger il possède déjà le code de l'application. Il peut donc l'analyser et invoquer des services directement sans être passé part une quelconque authentification.

C'est un principe de base du dev JavaScript: la sécurité est toujours assurée par le serveur.
Moins l'utilisateur a de code et d'info, moins il a de clefs pour hacker l'application.

Si vous envisagez une telle approche pour la sécurité de votre application, je ne peux que vous conseiller de revenir dessus. Pour assurer un max de sécurité, il faut que lorsque l'utilisateur ouvre l'application il n'obtienne que le strict minimum.
Et si l'authentification échoue, il faut qu'il n'ait aucune information supplémentaire.

A+JYT

[thelvin]

Je comprends pas en fait.

Apparemment cette appli contacte bel et bien le serveur pour demander une authentification.
Ensuite, dans la réponse, essentiellement de type "l'authentification a marché, oui / non," ma foi, il est possible de modifier la réponse "non" pour la transformer en "oui" et ainsi avoir tout le JavaScript qui se comporte comme si ça avait réussi... Mais la session sur le serveur n'a quand même pas été ouverte, et à la prochaine requête on se fera jeter et on n'aura pas l'info ni les effets dont on a besoin.
Ça me semble un comportement parfaitement normal et aussi sécurisé que n'importe quel site web.

[danielhagnoul]

Bonsoir

Je n'ai pas lu l'article, mais l'explication de @sekaijin me semble claire.

[...] une requête AJAX demande au serveur les informations sur l'utilisateur. Lorsque la réponse arrive, le JS vérifie que l'utilisateur est autorisé [...]

On ne doit jamais validé, coté JS, une opération sécuritaire.

Ce n'est d'ailleurs pas la première fois que l'on recommande de ne pas traiter des opérations mettant en cause la sécurité d'un site web du côté client. On doit se limiter au recueil et à la transmission (cryptée de préférence) des informations.

[sekaijin]

c'est un énorme trou de sécurité
l'appli demande au serveur si l'utilisateur est accepté ou pas

mais le code de l'appli est déjà disponible sans contrainte de sécurité
ensuite toute la sécurité repose sur un if dans un code JS donc accessible par le client

il n'y a donc absolument aucune sécurité il suffit quelque soit la réponse du serveur de gruger ce code pour avoir accès à toutes les fonctionnalités

en clair on te donne un papier à l'entrée d'un site sécurisé
sur le papier il est écrit
appeler le 01 01 01 01 01 et donner son son nom et son mot de passe
si la réponse de l'opérateur est OK alors ouvrir la porte.
si non faire demi-tour

avec ce genre de sécurité le premier pékin venu ouvre la porte pour voir
et comme il n'y a rien d'autre comme sécurité il entre.

Pour qu'une sécurité fonctionne il faut que ce soit l'opérateur (le serveur) qui ouvre la porte et non le client

dans le cas d'un site web avec ou sans JS li faut que le client n'ai accès à rien avant d'être authentifié
il invoque le serveur pour s'authentifier
le serveur l'autorise et lui fourni le code de l'application. et seulement dans ce cas la pas avant.

effectivement sans être passé par l'authentification la session coté serveur n'est pas effective et SI (il y a bien un si) le reste est bien fait il ne parviendra pas à ses fin.

Mais on prends alors un gros risque car on donne au hacker beaucoup d'information sur le fonctionnement du site. il faut comprendre que toute information divulguée est une info de plus pour percer la sécurité du site. car dans le cas présent on peut non seulement changer un non en oui mais aussi récupérer toutes les url de service de l'application beaucoup d'info sur son organisation etc.

A+JYT

[thelvin]

Je n'ai pas lu l'article, mais l'explication de @sekaijin me semble claire.

[...] une requête AJAX demande au serveur les informations sur l'utilisateur. Lorsque la réponse arrive, le JS vérifie que l'utilisateur est autorisé [...]

On ne doit jamais validé, coté JS, une opération sécuritaire.

What ? Évidemment que le JS vérifie si l'utilisateur est autorisé, il faut bien déterminer d'une manière ou d'une autre si on affiche "Vous êtes maintenant connecté" ou "Vos identifiants sont invalides."
Ce n'est pas une opération sécuritaire, c'est de la UI pure.

en clair on te donne un papier à l'entrée d'un site sécurisé
sur le papier il est écrit
appeler le 01 01 01 01 01 et donner son son nom et son mot de passe
si la réponse de l'opérateur est OK alors ouvrir la porte.
si non faire demi-tour

avec ce genre de sécurité le premier pékin venu ouvre la porte pour voir
et comme il n'y a rien d'autre comme sécurité il entre.

Pour qu'une sécurité fonctionne il faut que ce soit l'opérateur (le serveur) qui ouvre la porte et non le client

Ouais sauf que la réponse de l'opérateur contient un laisser-passer qui est demandé par tous les stands derrière la porte. La porte est là que pour faire joli, il suffit de la pousser pour l'ouvrir et tu peux entrer si tu veux, mais tu feras rien dedans si tu arrives pas à fabriquer un faux laisser-passer... Et je vois mal comment tu comptes faire.

dans le cas d'un site web avec ou sans JS li faut que le client n'ai accès à rien avant d'être authentifié
il invoque le serveur pour s'authentifier
le serveur l'autorise et lui fourni le code de l'application. et seulement dans ce cas la pas avant.

effectivement sans être passé par l'authentification la session coté serveur n'est pas effective et SI (il y a bien un si) le reste est bien fait il ne parviendra pas à ses fin.

Mais on prends alors un gros risque car on donne au hacker beaucoup d'information sur le fonctionnement du site. il faut comprendre que toute information divulguée est une info de plus pour percer la sécurité du site. car dans le cas présent on peut non seulement changer un non en oui mais aussi récupérer toutes les url de service de l'application beaucoup d'info sur son organisation etc.

D'accord c'est ce que tu voulais dire. Enfin bon j'ai qu'à demander à quelqu'un qui a un compte de me le filer, ce code. Il vaut peanut ce maillon de sécurité.

[SylvainPV]

Non, il ne faut pas juger trop vite et voir au delà des apparences. Ce qu'il faut comprendre, c'est que ce n'est pas cette variable JavaScript data qui assure l'authentification mais bel et bien un cookie de session comme presque tous les sites web. La variable data n'est là que pour stocker un état applicatif : si on la modifie manuellement, on sera en effet capable de simuler l'état loggé côté client, mais toutes les requêtes pour obtenir ou modifier des données doivent échouer s'il n'y a pas de cookie valide. J'ai déjà utilisé ce principe sur plusieurs projets professionnels et cela n'engage pas de (nouvelle) faille de sécurité. Qu'importe la méthode ou les technos utilisées, l'adage "Never trust client" est toujours valide et doit toujours être respecté.

Reste la question de protéger ou non le code JavaScript de l'application une fois l'étape d'authentification passée. A vrai dire, je vois très peu de cas où cela peut présenter une réelle menace de sécurité. Il est très courant de voir tous les scripts JavaScript d'un service accessibles directement sans authentification ; on peut d'ailleurs les placer avec les CSS, images et autres ressources statiques sur un serveur différent des machines middle-tier afin d'augmenter les performances (typiquement un nginx/apache filer et un Tomcat/JBoss pour le middleware). Bien souvent, les informations sensibles sur le fonctionnement d'un service sont dans ce qu'on a coutume d'appeler "couche métier" ou "business layer". Le code sensible de la couche métier ne devrait pas être délocalisé côté client. On peut éventuellement mettre côté client une sous-partie des fonctions de l'application pour de la compensation de latence ou un mode offline par exemple, mais il faut toujours avoir à l'esprit que c'est du code public. S'il s'agit d'un site à accès réservé type intranet et que l'on vérifie le cookie d'auth à la requête du script, on peut dire au mieux qu'il s'agit de code semi-public. Mais certainement pas de code privé, avec ou sans authentification.

[Paul TOTH]

...
Lorsque l'utilisateur le valide, une requête AJAX demande au serveur les informations sur l'utilisateur.
Lorsque la réponse arrive, le JS vérifie que l'utilisateur est autorisé et affiche l'interface de l'application.

C'est ce principe qu'il ne faut JAMAIS suivre.
...
On peut toujours essayer de sécuriser ce code, cela ne changera jamais rien. Il sera toujours possible pour quelqu'un d'intervenir sur le traitement de la réponse et de passer outre.

De plus avant même que l'utilisateur ait tenté de se loger il possède déjà le code de l'application. Il peut donc l'analyser et invoquer des services directement sans être passé part une quelconque authentification.

le code JS ne permet pas de le savoir, c'est au serveur de s'assurer que l'utilisateur est authentifié, peu importe ce que fais le JS...le serveur doit de toute façon toujours contrôler les requêtes qui peuvent toujours êtres trafiquées.

C'est un principe de base du dev JavaScript: la sécurité est toujours assurée par le serveur.
Moins l'utilisateur a de code et d'info, moins il a de clefs pour hacker l'application.

Si vous envisagez une telle approche pour la sécurité de votre application, je ne peux que vous conseiller de revenir dessus. Pour assurer un max de sécurité, il faut que lorsque l'utilisateur ouvre l'application il n'obtienne que le strict minimum.
Et si l'authentification échoue, il faut qu'il n'ait aucune information supplémentaire.

A+JYT

c'est un problème inhérent à JavaScript, tout le code de la partie client est disponible...certes il est parfois obfusqué ou révélé uniquement après login, mais ça reste plus lisible que du code machine Ceci dit c'est aussi vrai des application Flash, .Net ou Java qu'on peut assez facilement décompiler en un code lisible.