Discussion :

[senacle]

Bonjour,

J'ai souvenir qu'il y a quelques années, il était fortement conseillé de désactiver javascript lorsqu'on naviguait pour des raisons de sécurité.

Puis javascript est revenu en force avec la redécouverte de XMLHttpRequest.
Sont apparus alors ajax et de nombreux framework.
Et le problème de sécurité semblait avoir disparu (en tout cas, je n'en ai jamais entendu parler quant aux avantages des framework...)

Avec la toute récente alerte de sécurité d'IE, on nous conseille à nouveau de désactiver javascript.

Ma question donc :

le principe d'ajax est-il sûr ?
peut-on faire confiance aux framework javascript ?

[E.Bzz]

Bonjour,
un article sur la sécurité web en général t'aidera peut être à te faire une idée ...

A+

[senacle]

Des extraits de l'article :

Ne transférez pas de logique chez le client, car il peut en faire ce qu'il veut. Ainsi, évitez une logique métier dans du Javascript, de nombreuses astuces permettent de la détourner. Un appel Ajax doit chercher des données sur le serveur, et on ne doit pas itérer un objet au format JSON posté sur le client.
De la même manière, utilisez le client pour valider les données est totalement hors sujet. Utiliser javascript pour valider un formulaire ne sert strictement à rien. Cette étape doit être assurée par le serveur. Qui dit que javascript est activé ? Qui dit que le client est un navigateur web qui affiche une page ? Personnellement en quelques temps je crée une application PHP qui peut requêter une page tierce, et lui renvoyer des données, que je peux manipuler...

Bon, ben les framework javascript, ça sert à rien alors ?
Ou en tout cas, de nombreuses fonctionnalités sont inutiles, voire à proscrire du point de vue de la sécurité...

[Bovino]

Salut.

La problématique n'a rien à voir avec JavaScript, AJAX ou les bibliothèques existantes mais avec l'utilisation que l'on en fait.
Si on prend l'exemple d'une page d'inscription à un site, que la demande soit envoyée par AJAX après vérifications JavaScript ou via une validation de formulaire revient strictement au même et doit aboutir à la même logique coté serveur : la vérification systématique des données reçues, selon le bon vieux principe de "Never Trust User Input" (ne jamais faire confiance aux données utilisateur).

Maintenant, c'est sûr que si tu vérifies coté client qu'un mot de passe correspond à l'accès admin de ton site...

[RomainVALERI]

Un des extraits de l'article :

Ne transférez pas de logique chez le client, car il peut en faire ce qu'il veut. Ainsi, évitez une logique métier dans du Javascript, de nombreuses astuces permettent de la détourner. Un appel Ajax doit chercher des données sur le serveur, et on ne doit pas itérer un objet au format JSON posté sur le client.
De la même manière, utilisez le client pour valider les données est totalement hors sujet. Utiliser javascript pour valider un formulaire ne sert strictement à rien. Cette étape doit être assurée par le serveur. Qui dit que javascript est activé ? Qui dit que le client est un navigateur web qui affiche une page ? Personnellement en quelques temps je crée une application PHP qui peut requêter une page tierce, et lui renvoyer des données, que je peux manipuler...


Bon, ben les framework javascript, ça sert à rien alors ?
Ou en tout cas, de nombreuses fonctionnalités sont inutiles, voire à proscrire du point de vue de la sécurité...

Une nuance à mettre ici, quand même ^^

>>> faire reposer le contrôle des données entrantes sur le code JS client est effectivement mauvais du point de vue sécurité, on est bien d'accord.

>>> par contre, dire "ça ne sert strictement à rien" est faux. Cela sert, comme tout JS présent sur une page, à proposer à ceux qui le veulent (en l'occurrence : ceux qui ont activé leur JS) un confort supplémentaire grâce à certaines pré-vérifications (formats notamment). Ce n'est pas de la sécurité, c'est de l'ergonomie.

Tout ça pour dire que la question n'est pas "Faut-il contrôler côté client OU côté serveur ?", car l'un n'empêche pas l'autre, ces deux types de contrôles n'ayant pas du tout les mêmes objectifs.

[senacle]

Une nuance à mettre ici, quand même ^^

>>> faire reposer le contrôle des données entrantes sur le code JS client est effectivement mauvais du point de vue sécurité, on est bien d'accord.

>>> par contre, dire "ça ne sert strictement à rien" est faux. Cela sert, comme tout JS présent sur une page, à proposer à ceux qui le veulent (en l'occurrence : ceux qui ont activé leur JS) un confort supplémentaire grâce à certaines pré-vérifications (formats notamment). Ce n'est pas de la sécurité, c'est de l'ergonomie.

Effectivement, je crois qu'il faut prendre les framework javascript pour le côté ergonomie

Tout ça pour dire que la question n'est pas "Faut-il contrôler côté client OU côté serveur ?", car l'un n'empêche pas l'autre, ces deux types de contrôles n'ayant pas du tout les mêmes objectifs.

Pour ma part, je le fais des deux côtés, en tout cas pour ce qui concerne le format des données (un nombre de 5 chiffres ou une adresse courriel par exemple).

Maintenant, c'est sûr que si tu vérifies coté client qu'un mot de passe correspond à l'accès admin de ton site...

Mais bien sûr je ne vérifie pas la valeur de la donnée côté client (donc javascript), mais côté serveur (php, python,...).

[senacle]

La problématique n'a rien à voir avec JavaScript, AJAX ou les bibliothèques existantes mais avec l'utilisation que l'on en fait.

Autre extrait de l'article :

Il y a 3 types d'attaques XSS différents, mais qui fonctionnent globalement tous de la même manière : un code
javascript malicieux est executé dans l'environnement local de la victime, le plus souvent à son insu, permettant de
récupérer ses informations de connexion, ou d'éxecuter des scripts locaux avec ses droits.
La plupart des navigateurs modernes possèdent javascript d'activé nativement, et la plupart des sites web modernes
acceptent que l'utilisateur puisse mettre en forme un texte avant de l'envoyer, avec diverses balises. Ce sont les 2
causes majeures de la prolifération des failles XSS sur Internet.
Google y a eu droit, Yahoo aussi, Myspace, etc....

(...)

Si on veut être sûr à 100% de ne pas être vulnérable au XSS en tant que client, on désactivera Javascript. Mais on
risque alors de ne plus pouvoir profiter d'un grand nombre de site éstampillés "web2.0", qui utilisent abondamment
javascript.


Pour qu'un framework javascript fonctionne, il faut bien sûr que javascript soit activé...et donc l'application web est fragilisée.

[senacle]

Les années sont passées, les Framework ont évolué, les navigateurs aussi, mais les principes restent les mêmes :

les frameworks permettent d'avoir une bonne ergonomie
vérifier systématiquement côté serveur les données arrivant du client