Google gaat vanaf februari javascript als bijlage blokkeren in Gmail

Google heeft aangekondigd dat het vanaf 13 februari bijlagen in Gmail gaat blokkeren die gebruikmaken van de js-bestandsextensie. Het bedrijf doet dat omdat javascript-bestanden gebruikt kunnen worden voor de verspreiding van malware.

In de aankondiging schrijft Google dat gebruikers die alsnog javascript-bestanden willen versturen bijvoorbeeld gebruik kunnen maken van Google Drive. Google blokkeert sommige bestandstypes in Gmail omdat deze mogelijk voor de verspreiding van malware kunnen dienen. De blokkering moet binnen twee tot drie dagen na release halverwege februari voor alle gebruikers gelden.

Daarmee volgen js-bestanden andere extensies, zoals exe, cmd, vbs en jar. Ook in gecomprimeerde vorm zijn deze extensies niet toegestaan. Archiefbestanden die zijn voorzien van een wachtwoord kunnen eveneens niet als bijlage aan een Gmail-bericht worden toegevoegd.

De beperking van extensies kan gebruikers tegen verschillende vormen van malware beschermen. Andere methodes, bijvoorbeeld phishing, zijn nog wel mogelijk. Zo waarschuwde een beveiligingsbedrijf onlangs over een Gmail-phishingcampagne die inloggegevens van gebruikers poogt te stelen met afbeeldingen die eruitzien als bijlagen.

Reacties (79)

Goede beslissing. Alleen vind ik het persoonlijk irritant dat er geen password protected zip/rar meer mee verzonden kunnen worden. Snap an sich de reden wel, maar ik verstuur ze niet voor niks met password erop.

Ik heb op mijn werk vaak genoeg met zulke mailfilters gewerkt; niet alleen via gmail.

Vaak werkt het om een bestand.zip te hernoemen naar bestand.renametozip als je iets naar een collega moet mailen. De collega weet dan wel dat het er aan komt.

Wellicht werkt dubbel zippen (binnenste met encryptie, buitenste niet) zoals andere gebruikers hier al suggereren.

Het ligt er uiteindelijk aan hoe slim de filters van de mailserver zijn.

Malware zou in theorie natuurlijk ook een alternatieve extensie kunnen gebruiken; maar de kans dat een gebruiker dan zelf de extensie naar iets bruikbaars gaat hernoemen terwijl het onverwachts binnenkomt (helemaal van een onbekend mailadres) is verwaarloosbaar klein.

De extensie hernoemen heeft weinig zin, de header zal hetzelfde blijven. Google lijkt mij wel slimmer dan alleen de bestandsextensie controleren.

Dat dacht ik ook, ze kijken vast wel naar de mimetype, niet naar de extensie.
Je moet nooit van de extensie uitgaan wat de inhoud is.
Het is handig om te zien wat je verwacht wat het is.
Dus het zou alleen voor de mens handig moeten zijn, niet voor de machine die het controleert.

Die rename is niet eens nodig. Heel veel mail malware maakt gebruik van jpeg envelopping.

Je gaat als mailbedrijf natuurlijk niet jpegs standaard blokkeren.

Dubbel zippen werkt niet:
uit google documentatie hierover:
"Archives whose content includes a password protected archive"

Dubbel zippen werkt niet volgens Google:

Gmail doesn't allow you to attach certain types of files, including:

• Archives whose content includes a password protected archive

en als je de extensie weglaat? dan is het gewoon een binary blob

Dan is het een binary blob die begint met de handtekening van een zip bestand. Een standaard .zip bestand zou moeten beginnen met "PK..", volgens deze wikipedia pagina:
https://en.wikipedia.org/wiki/List_of_file_signatures

Ik ga ervan uit dat Google daar ook naar kijkt, en niet alleen naar de extensie. Ik heb wel eens rond zo'n filter gewerkt door met de juiste editor een karakter toe te voegen vooraan het bestand, om het daarna weer weg te halen.

Mijn ervaring is dat dit wel werkt voor exe bestanden etc. Grootste reden is namelijk dat het niet meer een click to execute is (in mijn opinie).

Het verzenden van een email die je vraagt om een extensie te wijzigen zal minder infecties opleveren dan een email sturen met een download link, dus veilig genoeg.

Hangt dan weer van het OS af. Windows kijkt naar extenties, *nix kijkt naar de magic byte om het bestandstype te bepalen. Onder *nix systemen zijn extenties ook grotendeels gewoon een indicatie naar de eindgebruiker toe om een idee te krijgen. Je zou dus ook de magic byte eruit moeten halen (of aanpassen) om zeker te zijn.

Daar heb je tot op zeker hoogte gelijk in, maar volgens mij moet je dat bestand nog steeds executable permissie geven (chmod +x), anders kan je hem niet direct openen uitvoeren. Ik kan het overigens fout hebben.

Overigens zijn .sh shell scripts wel gewoon toegestaan in Gmail. Blocked file types

[Reactie gewijzigd door Qauters op 26 januari 2017 13:49]

volgens mij moet je dat bestand nog steeds executable permissie geven (chmod +x), anders kan je hem niet direct openen.

als je geen +x hebt dan kan je hem misschien wel openen (read), maar iig niet uitvoeren

Dan is het een binary blob die begint met de handtekening van een zip bestand. Een standaard .zip bestand zou moeten beginnen met "PK..", volgens deze wikipedia pagina:
https://en.wikipedia.org/wiki/List_of_file_signatures

Ik ga ervan uit dat Google daar ook naar kijkt, en niet alleen naar de extensie. Ik heb wel eens rond zo'n filter gewerkt door met de juiste editor een karakter toe te voegen vooraan het bestand, om het daarna weer weg te halen.

Laatste keer dat ik iets wilde sturen dat geblokkeerd werd heb ik het in een .rar gestopt en vervolgens de .rar extensie weggelaten. Probleem opgelost. Handig is het natuurlijk niet. Gelukkig hebben we tegenwoordig Dropbox, OneDrive, Googledrive, enz.

moet je als het zo ver is eens proberen ik vraag het me nu namelijk ook af

Eerst inpakken met wachtwoord en dan nog een keer zonder erbovenop geen optie om erdoor te glippen?

uit google documentatie hierover:
"Archives whose content includes a password protected archive"

Je weet toch wel dat de beveiliging op zo'n ZIP flinterdun is?
Er is software die de beveiliging van de meeste zipfiles binnen een seconde kan verwijderen.


Er zijn ook wel zips die wel goede encryptie gebruiken maar dat kun je aan de buitenkant niet zien.l

De zip beveiliging is niet moeilijk te kraken, maar de encryptie van rar is veel lastiger. Volgens mij werkt alleen de brute-force methode. Als je de afzender kent is het wachtwoord meestal sneller zelf te raden.

Tja, ik gebruik Rar nooit en Zip alleen als minder adepten het moeten kunnen openen.

Ooit van Jar gehoord en nee, dan bedoel ik niet Java Archive (dat is gewoon zip) maar Robert Jung's de opvolger van zijn ARJ-formaat. Tja je moet wel naar de console daarvoor want het is, net als zip en rar, al stokoud.

Daarnaast is er PeaZip, dat comprimeert in zip, 7-zip en pea-formaat en dat laatste is speciaal geschikt voor encryption.

Lekker dan. Als ik een beveiligde bijlage wil versturen of ontvangen, omdat ik niet wil dat iets/iemand anders het kan lezen, dan kan dat niet. Want google moet meelezen om mij te "beschermen". Een simpele waarschuwing of de bijlage in quarantine plaatsen had me genoeg geleken.

Zoals @mark-k zegt kan je je zip beveiligen met een password, en dan nog een keer inpakken zonder. Dan glip je er waarschijnlijk wel doorheen

uit google documentatie hierover:
"Archives whose content includes a password protected archive"

Ah dan word dat ook geblokkeerd. Ik gebruik het eigenlijk nooit. Is de oplossing dan uploaden op drive en die link invoegen oid?

Het verdien model van Google is informatie. Nog een reden voor hen om dit niet toe te laten

Terecht punt.
Het blokkeren van password protected zip bestanden is niet het eerste waar ik aan zou denken bij het bestrijden van malware?

Lekker dan. Als ik een beveiligde bijlage wil versturen of ontvangen, omdat ik niet wil dat iets/iemand anders het kan lezen, dan kan dat niet. Want google moet meelezen om mij te "beschermen". Een simpele waarschuwing of de bijlage in quarantine plaatsen had me genoeg geleken.

Het kan wel maar je moet je encryptie elders vandaan halen en niet de ingebouwde encryptie van ZIP gebruiken. Als je het bestand met PGP versleuteld mag je het wel mailen.

Betekent wel dat voor werk als programmeur dit erg lastig kan zijn.
Zeker als een zip bestand met password ook al niet mag.

Vermoed dat er veel professionals zullen afhaken.

Betekent wel dat voor werk als programmeur dit erg lastig kan zijn.

Ik heb nog nooit meegemaakt dat iemand sourcecode in een mail stuurt. Gaat altijd via een private repository of dropbox e.d.

Orde van de dag als je kleine projectjes moet draaien voor opdrachten op school. Gewoon plain text in mail of via messenger.

WhatsApp werkt niet zo goed dankzij URL encoding. Die snapt nog niet dat JavaClass.CONSTANT geen URL is.

Volgens mij is het probleem eerder dat jij niet snapt dat JavaClass.CONSTANT prima een domeinnaam kan zijn. daar gaat Whatsapp ook gewoon vanuit, omdat de gemiddelde leek geen http(s):// voor een url typt.

Voor de rest ben ik het wel met je eens, vaak toch even een proefversie per mail oid. het gebeurd genoeg...

Nee dat kan niet want .CONSTANT is geen legale TLD. Net als javaObject.getMinValue().

Het gaat uiteraard om Placeholders in het voorbeeld. Je gebruikt namelijk nooit JavaClass.CONSTANT in je code.

"Nee dat kan niet want .CONSTANT is geen legale TLD."

Ik kan snappen dat oa. Whatsapp vooruitloopt op de nieuwe private TLD's en geen zin heeft om databases daarvan the checken bij elke domain-request.

Ik niet.

Whatsapp doet bij idere URL namelijk standaard een request naar de pagina om een preview te laden. Je hoeft dus helemaal geen database met TLDs bij te houden.

Daarnaast heeft een TLD nooit hoofdletters (die worden namelijk genegeerd in de domeinnaam) en kunnen er geen niet alfanumerieke karakters zoals haakjes in zitten.

Dergelijke shit parsen naar URL is vragen om problemen met XSS en Injection binnen whatsapp. Dan is de hele url encoding namelijk compromised (als ze zulke dingen al toelaten...)

"Daarnaast heeft een TLD nooit hoofdletters (die worden namelijk genegeerd in de domeinnaam)"
Ahh dus je denkt dat truus van de hoek weet wat de vormregels voor TLD's zijn?

Daarnaast heb je nog interne TLD's die gebruikt worden door de PDC.

Truus om de hoek zal dan ook nooit hoofdletters gebruiken voor een TLD.

En als ze dat wel doet, jammer dan

Online veiligheid mag nooit afhankelijk zijn van wat de gebruiker wel of niet weet over URL building.

Telegram staat bestandsdeling toe...

Just saying...

Voor studenten (vooral met groepsprojecten) is Telegram drastisch superieur aan Whatsapp.

Klopt. Dat is ook een beter optie dan plain text alles doorsturen. Google drive of dropbox is ook een veelgebruikt alternatief.

Ik stuur dagelijks een ZIP met de laatste php en js bestanden naar mijn compagnon in Spanje.

Wel balen als dat niet meer zo makkelijk kan als nu. Dan maar met wetransfer maar dat is aardig wat meer gedoe.

Dan maak je toch een gedeelde map op je google drive? Dan hoef je alleen maar te mailen of appen dat er een nieuwe versie staat. Lijkt me ook een stuk efficiënter.

En jij denkt dat Google Drive privé is?
Google weet precies wat je erop hebt staan / erop zet, en gebruiken dat om hun "ads" voor je aan te passen, Uh ik bedoel die die ze door je strot willen drukken / opdringen/mee spammen.

Probeer eens wat versleutelde bestanden daarop te zetten, of te versturen.... foutmeldingen van hier tot.... << Ze blokkeren dat gewoon.

IMHO
Voor private / beveiligde bestanden voor privé of werk, gewoon een (ftp) servertje met ssh/ssl verbinding maken. En mail natuurlijk via je eigen mailserver of via een mail server waar je WEL alles mag versleutelen.!

Google drive is net zo privé als gmail. Begrijp je opmerking bij dit nieuwsbericht niet. Gaat erom dat je geen bijlages bij gmail meer kunt sturen, dan lijkt mij gdrive een prima alternatief.

Waarom maak je dan niet gewoon een (private) github repo aan? Kan je ook gelijk/samen aan de code werken.

Simpele oplossing om je gepassworde zip bestand alsnog per mail te kunnen versturen. Verander de extentie naar .txt en hij gaat er doorheen...

tja, maar het is toch te gek voor woorden dat je zoveel moeite moet doen om het gewoon verstuurd te krijgen.. Dit gaat mij allemaal te ver.

Dit werkt niet, de headers van het bestand blijven hetzelfde dus Google ziet nog steeds een zip.

En een mooi verpakte smoes om gebruikers naar Google Drive te krijgen.

[Reactie gewijzigd door HansvDr op 26 januari 2017 11:13]

Je hebt Drive al als je een Gmail-account hebt. Dus er naartoe krijgen lijkt me niet echt van toepassing.

[Reactie gewijzigd door ItsNotRudy op 26 januari 2017 10:28]

Daar gaat het ook niet om. Het gaat erom dat je het ziet en dan gaat gebruiken; dat wil Google natuurlijk graag.

Het maakt voor hen uiteindelijk geen verschil. Je bijlages en Google Drive maken allen deel uit van de storage die je hebt bij Google. Of je het nu via Gmail of Drive upload, de bestanden hebben ze.

Nee, maar wanneer je actief gebruik gaat maken van GDrive, dan ga je het misschien wel meer en meer gebruiken, tot op het punt dat je er ook daadwerkelijk voor gaat betalen.

Precies. Wellicht dat je dan sheets en docs bijvoorbeeld opent en gaat gebruiken. Uiteindelijk hoopt google natuurlijk storage te verkopen bijvoorbeeld.

Die mensen zaten al op GMail en moeten perse naar Drive denk je? Wat zou daar het business voordeel van zijn stel je je zo voor?

Drive is het gratis Docs gedeelte van Gmail (of Google Apps / G Suite) dus dat hebben de gebruikers er al gratis bij. Dus er is inderdaad niet echt een business voordeel. Het werkt overigens wel lekker. Ik zet steeds meer docs en excel dingen in drive neer, o.a. als backup.

Google Docs en Gmail delen sowieso al dezelfde opslagruimte binnen je Google account.

Het enige dat dit bereikt, is dat met Google Drive er een hoop meer, een stuk betere tools tot je beschikking staan voor bestandsdeling en manipulatie.

De overstap naar een andere mail-provider steeds minder de moeite waard maken. En andere gebruikers naar drive halen, als ik een bijlage wil zien van een g-mail gebruiker en die verstuurd enkel een link naar G-Drive dan moet ik daar naar toe.

Als die ander zorgt dat het bestandje is gedeeld voor iedereen met de link zonder aan te hoeven melden merk je daar verder ook niet zo veel van.

Archiefbestanden die encrypted zijn kan gmail niet lezen, heeft sowieso ook de voorkeur om te gebruiken. Maar je kunt gewoon archiefbestanden in alle soorten en maten mailen

Archiefbestanden die encrypted zijn kan gmail niet lezen, heeft sowieso ook de voorkeur om te gebruiken. Maar je kunt gewoon archiefbestanden in alle soorten en maten mailen

Ik stuur het gewoon als bestand.zip.rename , werkt gewoon zonder encryptie

[Reactie gewijzigd door Neko Koneko op 26 januari 2017 10:27]

Ow wist ik niet, ik meende in een ver verleden dat ik dat ook ooit getest had en het niet werkte, want ik gebruikte gmail toen meer als usb stick (voordat usb sticks in kwamen en betaalbaar werden). Maar het is wat meer werk maar het is toch een veiliger idee mbt privacy dat google de inhoud niet kan scannen.

WTF, ik bepaal toch wat ik wil ontvangen, en juist als het netjes gezipped is moet het gewoon door gaan. Nu moet je dus weer extensies gaan zitten veranderen. En je kunt dus eigenlijk helemaal niets bijzonders meer als attachement sturen, want code naar collega zou dan ook niet meer gaan, hell of een test applicatie richting een klant (welke dan netjes gezipped is) kan je ook al niet versturen..

Dat zippen heb ik al langer last van omdat als je zoals je zegt een projectje naar iemand stuurt je het normaal in een zipje doet.

Ik noem het bestand nu gewoon altijd anders. dus inplaats van .zip noem ik het .zipp etc.
Dit is voor beide partijen niet handig maar het is of dit of geen gmail(google drive of andere email dienst)

Heb liever dat ze het gewoon toestaan en dan een melding vertonen als je de attachement wilt downloaden, of net zoals op andere punten gebeurd, een analyse gebeurd of het kwaadaardig zou kunnen zijn, en dan een extra melding. blokkeren vind ik sowieso een no-no, zeker omdat gmail ook nogal door developers gebruikt wordt.

Dat mocht eens tijd worden zeg. Alle malware die naar ons kantoor wordt gestuurd is een .js bestand in een zip. Aangezien Windows .js bestanden default opent met Windows Script Host, en interpreteert als WScript (javascript maar met toegang tot je filesystem/registry/netwerk etc) is het versturen van .js bestanden heel aantrekkelijk voor malware-schrijvers.

Dit is een van de simpelste manieren om mensen virussen te laten downloaden. WScript is ontzettend krachtig, maar redelijk onbekend en weinig gebruikt. Ik heb nooit begrepen waarom Windows standaard alle .js als WScript uitvoert, en niet met Notepad ofzo. Ik heb in 25 jaar gebruik van Windows nog nooit WScript hoeven gebruiken om taken uit te voeren, of installaties te doen. De enige keren dat ik WScript tegenkom is het voor malware-downloaders (en in de WScript analyser voor nodejs waar ik al een tijdje aan werk, juist om dit soort malware-downloaders sneller te analyseren).

Dus goede zaak van Google dat ze dit nu ook gaan blokkeren. Nu is het tijd voor Microsoft om deze obscure scripttaal geheel uit te faseren.

[Reactie gewijzigd door anargeek op 26 januari 2017 12:00]

juist, maar je kunt dus nu geen beveiligde zip meer naar collega's/vrienden sturen, en blijkbaar ook al geen exe (in zip) etc meer..

Ik begrijp de bescherming heel goed, maar ze schieten hiermee wel door en Google Drive gebruiken om bestanden te delen bij de e-mail zuigt, zeker als de andere partij geen Google gebruikers zijn, danwel zich achter slecht internet bevind.
Onze workaround, is de bestanden zippen en op de website in een aparte folder zetten, en de link daarheen doormailen. Na bevestiging van download halen we de ZIP weer weg.

Wat 'zuigt' er precies aan Google Drive?
Hier werkt het allemaal prima, kan aangeven wie mag downloaden of creer een openbare link.
Tevens zullen er vast wel scripts te vinden zijn die werken met een expire optie.

Verder zou ik nooit zomaar bedrijfsgevoelige data op een clouddienst zetten. Zet dan gewoon zelf een kleine HTTP/git-server op, kleine bestanden kunnen prima op een rPi.

Of gewoon je bestanden kunnen mailen zoals het hoort, wat een omslachtige onzin allemaal.

GDrive zelf is het probleem niet, het probleem is dat er nu een workaround moet komen in de vorm van bvb GDrive, omdat Google iets wat erg veel wordt gebruikt niet meer toestaat. Het vervelende is dat er geen optie is die zegt 'Sta mogelijk gevaarlijke email-bijlagen toe' voor als je het nodig hebt. Het is bloedirritant om een snelle tool te willen versturen naar je vriend en dat je mailclient dan zegt dat het niet mag.

Google bemoeit zich met teveel dingen. Zij vinden het beter voor ons, ik had het liever als optie gezien wat je simpelweg uit kunt zetten.

Hetzelfde met Chrome op Android, ik heb vele, vele uren aan de animaties op mijn site gewerkt, zodat ze soepel verlopen op vrijwel elke browser en systeem, en dan besluit Google ineens dat de mobiele versie van Chrome ze niet meer laat zien omdat ze zogenaamd de browse ervaring vertragen. Lekker dan!