Google a annoncé que les fichiers JavaScript (.js) ne pourront plus être attachés aux messages envoyés par Gmail. Gmail : il ne sera plus possible d'envoyer des fichiers JavaScript par email Pour des raisons de sécurité. Pour des raisons de sécurité, ces scripts ne pourront plus être envoyés en tant que pièces jointes, Google recommande désormais aux utilisateurs habitués à cette pratique de passer à d’autres services pour les partager. Cette mesure va entrer en vigueur à partir du 13 février prochain et fait partie des derniers efforts du géant de la recherche pour contrecarrer la montée en puissance des attaques informatiques et les pièges conçus pour faire tomber des victimes en recourant aux pièces jointes, comme les attaques d’hameçonnage et différents genres de messages de spam :
La plupart de ces fichiers ont un point commun, ils sont exécutables. Pour cette raison, ils peuvent être exploités par les pirates informatiques pour mener des attaques sur leurs cibles et les infecter. Les fichiers .js sont particulièrement dangereux puisqu’ils permettent d’exécuter automatiquement le Windows Scripting Host (WSH), un logiciel permettant d’exécuter des scripts directement sur le système d’exploitation Windows.
Il faut savoir que des cas de ransomwares se propageant par fichiers .js ont été détectés par le passé. Des rapports indiquent que les cybercriminels recourent de plus en plus à l’email pour infecter les victimes, malgré les campagnes de sensibilisation. Des fichiers Word aux fichiers .js bien cachés dans des archives .zip, ces techniques permettent aux pirates informatiques d’extorquer des milliards de dollars aux victimes. Gmail restreint actuellement certains types de fichiers (.exe, .msc et .bat) pour des raisons de sécurité et à partir du 13 février 2017, nous n’autoriserons plus les pièces jointes contenant des fichiers .js. Comme pour les autres fichiers prohibés, vous ne pourrez plus attacher un fichier .js, au lieu de cela, vous verrez un message d’alerte expliquant le motif de ce choix par l’éditeur », a expliqué Google dans un billet de blog.
Pour ceux qui sont habitués à partager des fichiers .js par email, Google recommande de passer à Google Drive, Google Cloud Storage ou d’autres solutions de stockage permettant de partager et envoyer des fichiers.
Aperçu du message d'alerte de Gmail
Les autres types de fichiers qui ne peuvent pas être envoyés sur Gmail incluent : .ADE, .ADP, .BAT, .CHM, .CMD, .COM, .CPL, .EXE, .HTA, .INS, .ISP, .JAR, .JSE, .LIB, .LNK, .MDE, .MSC, .MSP, .MST, .PIF, .SCR, .SCT, .SHB, .SYS, .VB, .VBE, .VBS, .VXD, .WSC, .WSF, .WSH. Gmail peut même scanner les versions compressées de ces fichiers dans des archives .ZIP et .RAR afin de bloquer leur envoi. Le service de messagerie bloque également les fichiers et les archives protégés par mot de passe qui peuvent être utilisés pour mener des attaques malicieuses sur les victimes. En tant que développeur, il m'arrive parfois d'envoyer des mails contenant des scripts en pièce jointe. Il est toujours possible de placer ses scripts dans un fichier compressé, les serveurs de Google (et autres) ne prennent pas la peine d'analyser le contenu en profondeur. Chrome 56 vient donc de débarquer sur les ordinateurs sous Linux, macOS et Windows. Pour Android et iOS, le navigateur arrive généralement quelques jours plus tard. L’une des principales nouveautés vient faire concurrence au nouveau Firefox, sorti hier: le marquage des connexions non sécurisées pour informer l’utilisateur.
Le fonctionnement est globalement le même: tout site possédant un formulaire d’identification ou permettant des paiements par carte bancaire affichera une étiquette « Non sécurisé » à gauche de la barre d’adresse si la connexion ne passe pas par HTTPS. Il s'agira par contre simplement d'un texte, et non d'un logo barré de rouge.
Notez que Google avait déjà précisé qu’il ne s’agissait que d’une première étape, comme chez Mozilla d’ailleurs. À terme, tous les sites HTTP classiques seront en effet signalés comme non sécurisés et sans doute de manière plus visible.
Du FLAC et du HTML5 pour tous
Comme vu récemment, Chrome 56 gère également le FLAC (Free Lossless Audio Codec). Particulièrement apprécié des mélomanes – il ne provoque pas de perte à la compression – il peut être lu directement par Chrome, soit depuis une page web, soit en déplaçant un fichier vers la fenêtre du navigateur. Un ajout intéressant, notamment sur macOS où le codec n’est pas nativement pris en charge (c’est le cas surWindows 10).
La nouvelle version du navigateur permet également d’activer le HTML5 pour tous par défaut. Traduction, Chrome utilisera automatiquement le HTML5 s’il le peut, plutôt que les technologies fournies par des modules tiers, dont Flash. On rappellera cependant que ce n’est pas vrai pour tous les sites.
Une liste blanche leur permettra de continuer à lire les contenus en Flash, pour des raisons de compatibilité. Cette liste s’amenuisera petit à petit au fur et à mesure des nouvelles versions.
De nombreux ajouts pour les développeurs, 51 failles de sécurité corrigées
Parmi les autres nouveautés, on signalera la prise en charge de l’API Web Bluetooth, qui permet aux pages web d’utiliser le Bluetooth Low Energy sur Android, Chrome OS et macOS, via quelques lignes en JavaScript.
Les développeurs pourront également profiter de la valeursticky, qui permet de fixer un élément CSS dans une page quand un certain niveau de défilement a été atteint. Comme Firefox 51 hier, Chrome 56 gère nativement WebGL 2.0. Pour rappel, ce futur standard n’est pas finalisé, le dernier brouillon datant du 14 janvier.
Sur Android, Chrome 56 apporte en outre le support des API WebVR et GamePad(toutes deux des standards du W3C).
Il faut savoir que des cas de ransomwares se propageant par fichiers .js ont été détectés par le passé. Des rapports indiquent que les cybercriminels recourent de plus en plus à l’email pour infecter les victimes, malgré les campagnes de sensibilisation. Des fichiers Word aux fichiers .js bien cachés dans des archives .zip, ces techniques permettent aux pirates informatiques d’extorquer des milliards de dollars aux victimes. Gmail restreint actuellement certains types de fichiers (.exe, .msc et .bat) pour des raisons de sécurité et à partir du 13 février 2017, nous n’autoriserons plus les pièces jointes contenant des fichiers .js. Comme pour les autres fichiers prohibés, vous ne pourrez plus attacher un fichier .js, au lieu de cela, vous verrez un message d’alerte expliquant le motif de ce choix par l’éditeur », a expliqué Google dans un billet de blog.
Pour ceux qui sont habitués à partager des fichiers .js par email, Google recommande de passer à Google Drive, Google Cloud Storage ou d’autres solutions de stockage permettant de partager et envoyer des fichiers.
Aperçu du message d'alerte de Gmail
Les autres types de fichiers qui ne peuvent pas être envoyés sur Gmail incluent : .ADE, .ADP, .BAT, .CHM, .CMD, .COM, .CPL, .EXE, .HTA, .INS, .ISP, .JAR, .JSE, .LIB, .LNK, .MDE, .MSC, .MSP, .MST, .PIF, .SCR, .SCT, .SHB, .SYS, .VB, .VBE, .VBS, .VXD, .WSC, .WSF, .WSH. Gmail peut même scanner les versions compressées de ces fichiers dans des archives .ZIP et .RAR afin de bloquer leur envoi. Le service de messagerie bloque également les fichiers et les archives protégés par mot de passe qui peuvent être utilisés pour mener des attaques malicieuses sur les victimes. En tant que développeur, il m'arrive parfois d'envoyer des mails contenant des scripts en pièce jointe. Il est toujours possible de placer ses scripts dans un fichier compressé, les serveurs de Google (et autres) ne prennent pas la peine d'analyser le contenu en profondeur. Chrome 56 vient donc de débarquer sur les ordinateurs sous Linux, macOS et Windows. Pour Android et iOS, le navigateur arrive généralement quelques jours plus tard. L’une des principales nouveautés vient faire concurrence au nouveau Firefox, sorti hier: le marquage des connexions non sécurisées pour informer l’utilisateur.
Le fonctionnement est globalement le même: tout site possédant un formulaire d’identification ou permettant des paiements par carte bancaire affichera une étiquette « Non sécurisé » à gauche de la barre d’adresse si la connexion ne passe pas par HTTPS. Il s'agira par contre simplement d'un texte, et non d'un logo barré de rouge.
Notez que Google avait déjà précisé qu’il ne s’agissait que d’une première étape, comme chez Mozilla d’ailleurs. À terme, tous les sites HTTP classiques seront en effet signalés comme non sécurisés et sans doute de manière plus visible.
Du FLAC et du HTML5 pour tous
Comme vu récemment, Chrome 56 gère également le FLAC (Free Lossless Audio Codec). Particulièrement apprécié des mélomanes – il ne provoque pas de perte à la compression – il peut être lu directement par Chrome, soit depuis une page web, soit en déplaçant un fichier vers la fenêtre du navigateur. Un ajout intéressant, notamment sur macOS où le codec n’est pas nativement pris en charge (c’est le cas surWindows 10).
La nouvelle version du navigateur permet également d’activer le HTML5 pour tous par défaut. Traduction, Chrome utilisera automatiquement le HTML5 s’il le peut, plutôt que les technologies fournies par des modules tiers, dont Flash. On rappellera cependant que ce n’est pas vrai pour tous les sites.
Une liste blanche leur permettra de continuer à lire les contenus en Flash, pour des raisons de compatibilité. Cette liste s’amenuisera petit à petit au fur et à mesure des nouvelles versions.
De nombreux ajouts pour les développeurs, 51 failles de sécurité corrigées
Parmi les autres nouveautés, on signalera la prise en charge de l’API Web Bluetooth, qui permet aux pages web d’utiliser le Bluetooth Low Energy sur Android, Chrome OS et macOS, via quelques lignes en JavaScript.
Les développeurs pourront également profiter de la valeursticky, qui permet de fixer un élément CSS dans une page quand un certain niveau de défilement a été atteint. Comme Firefox 51 hier, Chrome 56 gère nativement WebGL 2.0. Pour rappel, ce futur standard n’est pas finalisé, le dernier brouillon datant du 14 janvier.
Sur Android, Chrome 56 apporte en outre le support des API WebVR et GamePad(toutes deux des standards du W3C).
Commentaires