Selon La Poste, si la fenêtre du navigateur est trop petite, alors il s'agit forcément d'un appareil mobile... *facepalm*

Chers développeurs, ne connaissez-vous donc pas les user agent et consorts ?

J'ai tenté de débusquer et comprendre le code JS fautif, mais je jette l'éponge : c'est indigeste, même en dé-minifiant 🤢

Tout ce que je peux dire, c'est que ça se trouve dans ce fichier : https://www.post.ch/api/headerjs?serviceid=ttb

Je ne sais pas dans quelle mesure cela est encore d'actualité, mais il semblerait que Kaspersky Internet Security 15 se permette d'injecter un script JS dans chaque page visitée ! Ce script servirait à communiquer entre le module KIS du navigateur et le programme principal.

Visiblement, c'est impossible à désactiver et cause de problèmes.

"This behaviour (injecting main.js) was implemented with KIS2015 and it seems to be by design to permit communication between browser plugins and the main kaspersky program.

ANNOYANCES:
This script sends endless XHR POST requests exactly every 2000ms as defined in main.js. i've seen 15.000 + requests recorded on a single active tab."

Pour créer une timeline à intégrer sur son site (pour illustrer un parcours professionnel, par exemple, ou l'historique d'une société).

Mon Dieu... Je regardais le code source de la page de login d'un site (dont l'absence de design en disait long) et je suis tombé sur une perle...

Déjà, je trouvais bizarre qu'il y ait une réimplémentation de MD5 en JS (seul code présent, d'ailleurs). Enfin soit, pourquoi pas, ça peut se justifier !

Je présentais un truc horrible et, malheureusement, mes craintes se sont trouvées fondées lorsque je suis tombé sur cette ligne (un peu modifiée pour des raisons de confidentialité et pour mieux y voir) :

<input name="login" type="submit" value="ENTRER" onClick="password.value = md5(md5(password.value) + 35755);">

Oui, regardez bien le code JS implémenté dans l'événement onClick : password.value = md5(md5(password.value) + 35755);

Visiblement, quelqu'un s'est renseigné sur comment sécuriser ses mots de passe, mais sans rien y comprendre au final oO

Ici, il fait un double hash MD5 du mot de passe (avec un sel)... c'est bien... mais du côté client !

Au final, ce hash sera envoyé au serveur et comparé tel quel avec celui stocké en BDD. Il est où l'intérêt ? Autant envoyer le mot de passe directement et le stocker en clair dans la BDD !

Évidemment, la connexion n'est pas sécurisée...