Discussion :

[emstar]

Bonjour a tous,

Je développe un site utilisant du Javascript, et je viens d'apprendre par un amis que c'est un langage bourré de failles et a ne surtout pas utiliser. Apparement après quelques recherches, j'ai lu ca :

" Cette généralité s'explique parce que le bug affecte les boites de dialogue JavaScript, système évidemment commun. Le hic tient spécialement en ce que ces boites n'affichent pas correctement ou n'incluent pas leur origine. Du coup, cela permet, depuis une fenêtre, à une personne malintentionnée d'ouvrir une boite de dialogue piégée en faisant croire à l'usager qu'elle provient d'un site de confiance. "

Je voudrais connaitre l'avis de personnes vraiment qualifiées sur ce sujet !

- Est il vraiment risqué d'utilisé le JS ?
- Dans quels cas les failles sont accessibles ?
- Quelles précautoins faut il prendre ?

Merci d'avance

[denisC]

- Est il vraiment risqué d'utilisé le JS ?

Pour qui? Le javascript s'execute sur le client, ça ne peut normalement être dangeureux que pour lui

- Dans quels cas les failles sont accessibles ?

Toujours.

- Quelles précautoins faut il prendre ?

Ne jamais faire confiance à ce qui revient d'un page web. Javascript te propose de donner plus de dynamisme à tes pages. Mais il ne te permettra jamais de leur donner de la sécurité.... Il faut voir que si tu fais du javascript, c'est pour l'interactivité. La sécurité, ça reste une prérogative uniquement du serveur.

[FMaz]

Le javascript est un language coté client.
En ce sens la source est lisible. Déjà la, on ne gère donc pas beaucoup de "sécurité" avec le JS.

Ensuite, ca me semble tourné à l'envers. S'il y a un risque de sécurité avec le JS, à mon avis, c'est du point de vu des autres language qui le gère. Exemple: ne pas controler les possibles inclusions de javascript dans les message d'un forum -> Donc c'est la faute du webmaster qui a pas codé quelque chose en PHP ou en ASP par exemple.


Dernier truc: Ton ami il est pas un peu ridicule de voir tout noir ou tout blanc. Tu crois vraiment que si ce language était SI mauvais, que 98% des internautes l'aurrais d'Activer que qu'autant de site l'utiliserais ?

L'assembleur aussi c'est pas sécuritaire: il y a pleins de virus !

[SpaceFrog]

un piège à geek ...
déja l'autre fenetre en arrière plan ...
et puis bon je sais pas trop ce que l'on peut retirer comme info à partir d'une boite confirm ...
Faut tout de même saisir volontairement l'information ...
genre si une boite de dialogue s'ouvre sur google me demandant mon numéro de carte bleue et le code ... je suis pas sur de vouloir les saisir ...
C'est aussi dangereux qu'un vendeur de bible en 43 volumes qui fait du porte à porte ... un piège à C.. qui n'attrappe que les ....

Et j'ajouterais que le confime est coté javascript, faudrait au moins un ajax derrière ou rebasculer l'info sur la page principale et faire un autosubmit d'un form ......

[supermanu]

Le javascript te permet d'avoir plus d'intéractivité avec l'utilisateur. En effet, tu peux par exemple vérifier directement si ce qu'il tape dans un formulaire est correcte et afficher des messages d'erreur...

Par contre tu dois aussi faire ces vérifications côté serveur (en php, java...) car il est facile de passer outre le javascript (voir section 2) :
http://www.td.unige.ch/wsh/failles_applications_web.pdf

[denisC]

Par contre tu dois aussi faire ces vérifications côté serveur (en php, java...) car il est facile de passer outre le javascript (voir section 2) :

Opéra (le navigateur web) laisse l'utilisateur rédéfinir n'importe quelle fonction javascript sur la page qu'il est en train de consulter.

C'est super pratique pour virer les scripts qui mettent de la pub dans tous les coins de ta fenetre

[emstar]

Effectivement, c'est ce que j'essaye d'xpliquer a mon ami !
Le fait qu'il soit interprété coté client par le navigateur n'avais de risque que pour le client !

Mais pour les sites de e-commerce, ce n'est pas plu risqués ? Etant donné les informations sensibles, et les payements ?

FMaz

Ensuite, ca me semble tourné à l'envers. S'il y a un risque de sécurité avec le JS, à mon avis, c'est du point de vu des autres language qui le gère. Exemple: ne pas controler les possibles inclusions de javascript dans les message d'un forum -> Donc c'est la faute du webmaster qui a pas codé quelque chose en PHP ou en ASP par exemple.

Que veux tu dire ? Que faut il éviter de faire ?

denisC:

Ne jamais faire confiance à ce qui revient d'un page web.

Que faut il faire ? des verifications de ce qui reviens ?

[denisC]

Mais pour les sites de e-commerce, ce n'est pas plu risqués ? Etant donné les informations sensibles, et les payements ?

Ben c'est toujours pareil, c'est le client qui rentre son numéro de carte bleu qui prends tous les risques.... C'est clair que si sur un site, il y a marqué "télépayement sécurisé par Javascript", je vais acheter ailleurs....

Que faut il faire ? des verifications de ce qui reviens ?

Oui, toujours. Il faut vérifier les informations sur le client en Javascript, parceque c'est plus interactif et joli, et revérifier sur le serveur. Par exemple, si tu veux être sur que l'utilisateur ne saisit que des chiffres dans un champ texte, tu fais la verif en JS et sur le serveur. Si tu n'as pas le temps de faire les deux, tu laisses tomber le JS.

[FMaz]

Généralement (j'exclu le AJAX volontairement), le javascript sert à:
- effectuer des validation POUR le visiteur, ce qui va peut-etre lui éviter de devoir tout ressaisir dans un formulaire s'il c'est trompé
- Rendre une interface dynamique (masquer des zone, afficher une confirmation, etc etc)

En ce qui concerne la validation, elle n'est la QUE pour le client. Toi tu dois ensuite REVÉRIFIER sur le serveur (en PHP ou ASP par exemple).

[emstar]

ok ! Merci a tous pour vos réponses ;-)

Je me dis toujours : il ne faut pas croire tout ce qu'on entend xD

[SpaceFrog]

Encore une fois javascript n'est dangereux que pour l'utilisateur client ...
il n'y a aucun danger à bourrer son site de javascript.
Il peut en revanche y avoir des codeurs mal intentionnés qui vont utiliser les possibilités offertes par javascript pour essayer de récupérer certaines informations mais il doit y avoir une saisie volontaire ou encore sous IE utiliser des activeX qui peuvent s'avérer plus dangereux ...
En l'occurence le but de cette fenetre "piègée" est de recupérer une information saisie par le client en lui faisant croire que la zone de saisie dépend de la fenetre visible en arrière plan.
Ce qui impose pour arriver au site "parasité" de passer par le site parasiteur...
Il n'est pas possible en javascript de venir se greffer sur l'ouverture de google (l'exemple que j'en ai trouvé étant sur un parasitage de google)
Au passge on peut faire encore plus vicieux sous IE en incrustant sur le site parasité une zone de saisie sans passer par une boite de dialogue ...