Action malveillante possible pour BeatsByDrDre La marque hi-fi, Beats (le fameux b) souffre d’un problème de sécurité sur son site Internet qui pourrait nuire à ses visiteurs/clients. C’est Mazaki, un lecteur, qui nous a alerté sur le sujet. La vulnérabilité, une XSS, un cross-site scripting. L’idée de cette faille, provoquer un enchainement d’actions malveillantes à partir d’un site officiel. En gros, soit par courrier électronique (XSS non-permanent comme pour gMail, ndlr datasecuritybreach.fr) ou directement stocké sur le site incriminé par la faille (XSS permanent), le pirate peut orchestrer différents types de piratages.
Vous vous demandez comment, par exemple, un pirate a pu voler la session de votre compte de courrier électronique, votre accès web ? Tout « simplement » via un vol du cookies. Le XSS permet l’interception de ce document caché au fin fond de votre ordinateur. Le pirate peut aussi afficher de fausses informations à l’écran, mettre en place une page de type hameçonnage de données ou, plus vicieux encore, installer un code malveillant (logiciel espion, keylogger) dans l’ordinateur de l’espace visité. Il est aussi possible, dans certains cas, d’accéder à la base de données et à ses petits secrets (mails, mots de passe, messages privés). Bref, comme le précise un expert du genre dans notre émission tv d’avril sur zatazweb.tv, le Cross-Site Scripting n’est pas à prendre à la légère. Notre cas du jour, vise donc B. Le protocole d’alerte de ZATAZ a été déclenché au sujet de cette potentialité malveillante. En attendant une hypothétique correction, datasecuritybreach.fr vous déconseille fortement de cliquer sur le moindre lien renvoyant vers le portail de Beats. Préférez taper directement, dans votre navigateur, l’url concerné.
Une correction ? Il existe moult méthodes pour éviter un XSS. Nous vous passerons l’utilisation d’un firewall (pare-feu) qui permet de filtrer les informations envoyées au serveur/site. Un contrôle du flux de données rentrantes/sortantes loin d’être négligeable. Le coût est l’un des freins de son utilisation. Parmi les solutions, mettre son nez dans le code source de son « précieux ». D’abord, protéger les variables (form et/ou url et/ou cgi et/ou cookies). Pour cela, il faut définir « scriptProtect » du tag <cfapplication>.
Comme le rappel Wikipedia : « Filtrer les variables affichées ou enregistrées avec des caractères ‘<‘ et ‘>’ (en CGI comme en PHP). De façon plus générale, donner des noms préfixés par exemple par « us » (user string) aux variables contenant des chaînes venant de l’extérieur pour les distinguer des autres, et ne jamais utiliser aucune des valeurs correspondantes dans une chaîne exécutable (en particulier une chaine SQL, qui peut aussi être ciblée par une injection SQL d’autant plus dangereuse) sans filtrage préalable« . Dernier point, non négligeable, faites appels à des personnes compétentes à qui vous laisserez du temps pour auditer sérieusement code source et espaces numériques exploités.
