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