Discussion :

[schnee]

Bonjour,

Avec tous les types de navigateurs, dans de multiples versions, sous différents systèmes, il est impossible pour un développeur d'être absolument sûr que son code roulera sans problème chez tous les visiteurs qui entreront dans son site.
Je viens donc de développer dans mon système de gestion de contenu un système (merci window.onError) qui me permet de retracer et enregistrer (merci Ajax) les erreurs Javascript côté client, et j'ai fait des trouvailles !

En effet, je récupère même des erreurs dans du code qui n'appartient pas à mon système !
J'en conclus qu'il appartient à quelque plugin côté client.

Par exemple, j'obtiens cette erreur :
Template : https://in2.perfectnavigator.com/inj...php?id=Pj8sNyM
Message : Script error.
User agent : Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0

Je n'ai jamais inclus aucun script de chez perfectnavigator.com dans mon code.
perfectnavigator est un ad-server qui infeste probablement le navigateur de mon visiteur.

Mais alors je me pose la question suivante avec angoisse :
Si mon code déclaré dans MON window.onerror reçoit les erreurs d'un script étranger, ça veut dire que ce script est considéré comme appartenant au window de MA page, donc il doit avoir accès au document, aux forms dans le document, aux champs inputs dans les forms, y compris aux champs de mot de passe etc. ?
Mais c'est dingue ça !!!

[schnee]

... à part ça, je viens d'en chopper un autre qui en plus se permet de créer des cookies sur MON domaine ?!?
Forcément, s'il parasite MA page, il est sous MON domaine.
Donc il peut voir aussi les vrais cookies, y compris ceux qui définissent une session, il n'aura même pas besoin du mot de passe pour entrer dans le système

Comment Est-ce que je peux détecter TOUTES les portions de script dans ma page ?
J'ai pensé à document.getElementsByTagName("script"), mais Est-ce que tous les scripts parasites sont introduits par une balise <SCRIPT ? Pas sûr.

[SylvainPV]

A partir du moment où le navigateur a récupéré la page, ce n'est plus TA page. Elle ne t'appartient plus et le client peut faire tout ce qu'il veut avec. Il peut changer les couleurs, les logos, supprimer les pubs, modifier le contenu etc... et également exécuter plein de scripts sans s'en rendre compte, via une extension ou un user-script qui s'est glissé dans son navigateur. Tu ne peux rien faire de plus, ça sera de sa faute s'il se fait choper son login/pass.

Mais il y a pire: les failles XSS (cross-site-scripting). Là, c'est la faute du développeur s'il ne prend pas garde au risque d'injection de scripts sur son site. Et cela peut permettre de faire exécuter à d'autres utilisateurs du code JavaScript malicieux sur un site qui n'appartient pas au hacker. Et malheureusement, ces failles sont encore très nombreuses y compris sur des sites grand public.

[schnee]

A partir du moment où le navigateur a récupéré la page, ce n'est plus TA page.

Quand je disais MA page, je veux dire la page créée par mon système bin sûr.
Mais à partir du moment où la page qui devient celle du visiteur peut servir à pirater mon site et à ajouter des cookies sur MON domaine, alors que normalement ça n'est pas possible, ça devient MON problème.

Il peut changer les couleurs, les logos, supprimer les pubs, modifier le contenu etc...

Ça, si ça peut l'amuser, ça ne me dérange pas ;-)

ça sera de sa faute s'il se fait choper son login/pass.

Ouais, mais là encore, si un intrus vient planter le bousin dans MON système, ça devient MON problème, même si c'est SA faute.

Je peux comprendre qu'un navigateur puisse exécuter un script quand il reçoit une page, mais que ce script soit intégré à la page et puisse interagir avec comme s'il en faisait partie, sous couvert d'une session ouverte grâce à une identification adéquat et avec les mêmes droits que les scripts légitimes, ça ça me sidère.

Mais il y a pire: les failles XSS (cross-site-scripting). Là, c'est la faute du développeur s'il ne prend pas garde

Ouais, bien sûr, mais là ça se passe sur le serveur, c'est plus facile a contrôler, et mon système est bien protégé contre ça, bien sûr.

[Bovino]

Bah oui mais tout ça, c'est quand même la base de la sécurité en développement Web (et pas que) : Never Trust User Input !
Donc c'est à toi, côté serveur, de vérifier que les données que tu reçois (que ce soit en GET, POST et même COOKIE voire SESSION) sont cohérents.
Si ton appli peut être détournée ou piratée, ce n'est pas de la faute de l'utilisateur mais de la tienne.

[schnee]

Never Trust User Input !

Bon, alors en somme on n'a plus qu'à fermer boutique ?
Parce qu'il est impossible de vérifier à 100% tout ce qui arrive sur nos serveurs.

Par contre, les développeurs des applications côté client, en particulier des navigateurs, ont la responsabilité de limiter autant que faire ce peut les brèches.
Par exemple, j'ai du galérer plusieurs jours pour trouver un contournement dans mon éditeur de texte le jour où Mozilla a décidé de désactiver l'accès au clipboard parce que c'était trop « dangereux ».
Alors j'ai du mal à comprendre comment on peut décider de limiter l'accès au clipboard, mais d'un autre côté laisser n'importe quel plugin avoir accès à tout le document ! C'est complètement disproportionné.

[SylvainPV]

Bien sûr qu'il est possible de vérifier 100% des entrées serveur, sinon le Web serait en ruine depuis longtemps... Ça n'a rien de sorcier de faire valider les inputs à l'aide de contraintes et d'expressions régulières, c'est même intégré nativement dans certains environnements comme le .NET.

Et non, les éditeurs de navigateurs n'y peuvent rien ; ce n'est pas eux qui vont faire la différence entre ton code JavaScript et celui d'un autre, qu'il ait été ajouté par XSS, par userscript ou par une quelconque extension. Si brèche il y a, elle se situe côté serveur.

Le problème du clipboard est différent car il concerne cette fois un défaut de confidentialité entre l'utilisateur et le service: si un site avait accès au contenu du clipboard, il pourrait avoir accès à des données privées. Pour la même raison, JavaScript ne permet pas d'aller se balader partout sur le filesystem du client.