Websites kunnen via Chromium-browsers inhoud automatisch naar klembord kopiëren

Websites kunnen bij een Chromium-browser automatisch en zonder enige vorm van toestemming inhoud kopiëren naar het klembord van het apparaat van de gebruiker. Instellingen die dat verhinderden, zijn uitgeschakeld in een voorgaande Chromium-build.

Gebruikers van een Chromium-browser zoals Google Chrome, Microsoft Edge, Opera en Brave Browser kunnen via de website Webplatform News zelf nagaan hoe deze site automatisch tekst naar het klembord van hun apparaat kan plakken zonder dat een gebruiker daarvan op de hoogte is of zelfs een handeling heeft uitgevoerd.

Volgens ghacks.net gaat dit ook deels op voor de Firefox- en Safari-browsers. Bij deze browsers zou het wel noodzakelijk zijn om een handeling, zoals het selecteren en kopiëren van tekst, uit te voeren voordat een website automatisch inhoud naar het klembord kan plakken. Tweakers heeft de beweringen getest, maar zag dat er bij Firefox en Safari geen tekst naar het klembord gekopieerd werd na het uitvoeren van gebruikershandelingen zoals het kopiëren van tekst.

Op een Chromium-webpagina voor ontwikkelaars wordt dieper ingegaan op het probleem. Daar valt te lezen dat een vereiste gebruikershandeling in combinatie met de readText- en writeText-api van Chromium, problemen veroorzaakt bij NewTabPageDoodleSharing-functie. Daarom werd die vereiste uitgeschakeld.

Update, 14.00 uur: Oorspronkelijke titel gewijzigd. Die was voorheen: 'Chromium-browsers laten sites toe om inhoud automatisch naar klembord te plakken'. Het werkwoord 'kopiëren' gebruikt in plaats van 'plakken'.

Reacties (76)

[itcrowd]

Ik ben een beetje verward door de tekst en kop van het artikel. Gaat het nu om kopiëren of plakken? Het lijkt op kopiëren maar er staat steeds "plakken naar klembord"..(?)

[Keypunchie]

Het gaat om de stap van data op het klembord zetten.

Leuk om te injecteren op een site met de suggestie voor handige scripts (maakt niet uit voor wat) dat je dit ‘alleen maar’ op terminal hoeft uit te voeren.

Iemand knipt een ogenschijnlijk onschuldig commando, er wordt heel snel met *andere* data overschreven en iemand doet plakken&enter.

[blorf]

Het betekent ook schrijfpermissie buiten het cookie-framewerk. Het is niet bij elk OS precies hetzelfde maar over het algemeen is het klembord gewoon een locatie op permanente opslag. Daar wil je een website niet bij laten.

[latka]

Welk OS zet het plakbord op je HDD/SSD behalve swap? Zover ik weet is dit altijd in memory (voor de bug niet zo relevant overigens).

[mcyh]

Klembordhulprogramma’s (geschiedenis) wellicht., dit kan bv in windows 10 mits een activeren van een setting, win+V is dacht ik te sneltoets voor de klembordgeschiedenis.

[blorf]

De browser kan bestanden ophalen van het lokale systeem die geen cookies zijn. Eigenlijk wel interessant of dat dan nog wel per sessie wordt gescheiden, anders krijg je de situatie dat sites elkaars achtergelaten data kunnen gebruiken.

[Ablaze]

Dat werkt "goed" voor crypto transacties. Iemand maakt geld over, plakt onwetend het verkeerde adres en bam, het geld is naar een scammer overgemaakt.

Naar mij idee is data op het klembord zetten exact wat de functie Kopiëren doet, dus ik begrijp eveneens weinig van de gekozen termen in dit artikel.

[fapkonijntje]

Ja er klopt weinig van. Het gaat hier om het kopiëren van tekst, waarna het op het klembord terecht komt. Dat zou je, als je mensen echt in de war wilt brengen, kunnen noemen als plakken naar het klembord, omdat je iets op/in je klembord plakt, maar handig is die omschrijving totaal niet natuurlijk.

[teun95]

Naar het klembord schrijven zou voor mij het minst verwarrend zijn geweest. Een vertaling van een veelgebruikte manier om het in het Engels te zeggen.

[Polydeukes]

Nu staat er "kopiëren op klembord", nog steeds onduidelijk. Ik zou zeggen "kopiëren naar klembord" maar goed.

[Dreamvoid]

Kunnen sites dit ook doen als Javascript is uitgeschakeld?

[seapip]

Nee, meeste APIs inclusief de sync/async functies om naar het klembord te schrijven zijn JavaScript. Zonder JavaScript blijft er nog maar weinig over kwa functionaliteit naast een layout renderen en stylen met css.

[NoobishPro]

naast een layout renderen en stylen met css.

Kleine toevoeging;

- Wat tegenwoordig op vrijwel iedere moderne website ook via javascript wordt gedaan.

[Cyb]

Dat is niet mijn ervaring. Al hoewel bijna alle websites ergens wel JS gebruiken, werken relatief veel sites prima zonder JS. Het "stylen met CSS" komt vooral voor als er externe resource libraries (voor icoontjes etc) gebruikt worden. Het gaat dan niet om de layout van de site, maar om kleinere details. Zo werkt Bootstrap voor een groot deel ook prima zonder JS.

[phex]

Met react, angular, svelte en Vue worden complete sites in JavaScript gebouwd, ook de html en css. Dit is heel populair. Maar zonder JavaScript zie je echt niks.

Echter omdat Google dat minder goed kan indexeren zijn er server side variaties zoals Next.js Nuxt, Astro en Remix die eerst voorgerenderde html en css statisch serveren, en daarna pas de js mergen met de statische content.

Daardoor kan een site in theorie prima zonder JavaScript werken.

[Reactie gewijzigd door phex op 23 juli 2024 14:10]

[Luminair]

Echter omdat Google dat minder goed kan indexeren zijn er server side variaties zoals Next.js Nuxt, Astro en Remix die eerst voorgerenderde html en css statisch serveren

Dit is al een lange tijd niet meer waar; Google, en veel andere crawlers, renderen in veel gevallen de javascript op een pagina.

[phex]

Ik zei minder goed, al was het alleen maar omdat je Google ranking potentieel omlaag gaat door de zwaardere download en rendering tijd van je pagina als je alles in JS opbouwt.

[divvid]

Het is een peuleschil om serverside JavaScript sites te renderen. Als het mij zelfs lukt om op die manier screenshots te maken via een scriptje dan kan google dat zeer zeker

De invloed die dat heeft op je ranking zegt meer iets over de echte relevantie van je site. Persoonlijk klik ik bij searches direct door naar pagina X om alle valse rankings, meestal advertentiefuiken, te omzeilen. Maw, als je echt wat te bieden hebt vinden mensen je toch wel

[Wielink]

Deze search engines stellen wellicht dat ze Javascript crawlers hebben. De praktijk blijkt in veel gevallen anders. Ik kan met geen mogelijkheid de keywords van mijn Angular 2 pagina zoekbaar krijg in Google. Alleen de statische keywords werken.

[Luminair]

Dan zou ik toch eens in een analytics-dashboard kijken, want dat moet gewoon werken. In hun crawler-documentatie leggen ze uit dat een pagina zelfs na load met JS een titel kan veranderen, en dat dat gewoon moet werken.

Vermoed toch dat het haast wel aan je code moet liggen dan. Misschien icm de user agent van de crawler? Zo'n analytics test moet in elk geval wel uitwijzen hoe het wordt uitgelezen.

[Cyb]

Die SPA frameworks zijn inderdaad erg populair, maar waar mijn reactie om ging is: de meeste sites gebruiken het niet. De sites die het gebruiken zijn wel vaak de wat grotere bedrijven, omdat daar meer kennis zit, ondanks dat het (SPA client side) voor kleinere sites net zo goed kan.

[NoobishPro]

Ik benoemde dan ook "Vrijwel iedere moderne website".

De meeste websites zijn oud. Waarschijnlijk is 80% van het internet intussen oud. Vooral grote websites lopen achter, zoals nieuws sites en grote webshops.

Jouw ervaring verandert weinig aan hoe websites tegenwoordig in elkaar steken en wat de webdevelopment standaarden zijn.

[Cyb]

Ik heb inderdaad het woord "moderne" in je post over het hoofd gezien, waardoor mijn reactie niet helemaal past van jouw bericht.

De meeste websites zijn oud. Waarschijnlijk is 80% van het internet intussen oud. Vooral grote websites lopen achter, zoals nieuws sites en grote webshops.

Op grote sites zie je juist wél vaak nieuwe technologieen gebruikt worden, vooral bij grote tech bedrijven.
Het zijn juist de kleinere bedrijfjes en sites die wordpress blogs en standaard html/css only sites gebruiken.
Neem bijv. grote bedrijven als Ikea, Thuisbezorgd, Deliveroo, Netflix, Twitter, Facebook, etc. Die lopen een stuk verder voorop dan de gemiddelde website.

Jouw ervaring verandert weinig aan hoe websites tegenwoordig in elkaar steken en wat de webdevelopment standaarden zijn.

Beetje onduidelijk wat je bedoeld met "tegenwoordig", zoals je zelf net al aan gaf zijn "80%" van de sites "oud". Is daar iets mis mee? Nee, zolang alles voldoet aan de gewenste functionaliteit, compabiliteit en veiligheidseisen, is dat geen enkel probleem.

[divvid]

Precies dit. In mijn vakgebied zit er iemand die handmatig literatuur uitpluist en zijn conclusie op een website plakt, in ouderwetse html tabellen bijna zonder css en 1995 look…..maar wel zeer relevant

[Remzi1993]

Dat is verspilling van processing en als web developer kan ik je vertellen dat we zo min mogelijk JavaScript willen gebruiken en zo kort mogelijke code en alles minified en in een bundle zodat alles maar 1 keer gedownload hoeft te worden (1 HTML bestand, 1 gebundeld CSS bestand en 1 gebundeld JavaScript bestand).

Om dan onnodig JavaScript voor styling te gebruiken is namelijk niet alleen verspilling, maar ook een bad practice of scheiding van opmaak, code en data. Je wilt namelijk die 3 zo veel mogelijk gescheiden houden. Dus geen data in HTML maar alles wordt uit de database, Json of whatever opgehaald en zo veel mogelijk gecached en offline lokaal opgeslagen, je opmaak en styling (HTML en CSS) wil je zo veel mogelijk gescheiden houden (dus geen online CSS en geen JavaScript die styling doet of een mix daarvan) en code wil je ook zo veel mogelijk gescheiden houden.

Dat zijn een van de vele best practices.

[lilmonkey]

als web developer kan ik je vertellen dat we zo min mogelijk JavaScript willen gebruiken en zo kort mogelijke code en alles minified en in een bundle zodat alles maar 1 keer gedownload hoeft te worden (1 HTML bestand, 1 gebundeld CSS bestand en 1 gebundeld JavaScript bestand).

Voor een simpele hobby-site wellicht, maar voor real world sites is dit echt totale onzin. Alles in één bundel is juist enorm slecht. Alle enigszins moderne bundlers ondersteunen dan ook 'bundle splitting'.

Daarnaast zorgt HTTP/2 ervoor dat het serveren van vele kleinere bestanden niet zo problematisch meer is dan het met HTTP/1 was.

Om dan onnodig JavaScript voor styling te gebruiken is namelijk niet alleen verspilling, maar ook een bad practice of scheiding van opmaak, code en data.

Wat een onzin. Als je je HTML en CSS met JS schrijft, zoals dat gebruikelijk is met de meeste moderne front-end frameworks, betekent dat niet per se dat het ook bij elkaar hoeft te staan. Je kunt dus prima die domeinen gescheiden houden ook als het allemaal met JS gegenereerd wordt.

Iets met een klok en een klepel.

[NoobishPro]

Klinkt alsof je van de oude stempel bent. Ik ben óók een webdeveloper en ik was één van de eersten die begon content in te laden met Javascript. Destijds werd ik belachelijk gemaakt, nu is het de norm.

Je hebt in principe wel gelijk over good practice. Ik vind het stylen via JS ook absoluut achterlijk en ben zeker geen fan van frameworks als react, maar dat maakt in deze ook helemaal niets uit.

De werkelijkheid is dat Javascript tegenwoordig wordt gebruikt om je HTML en CSS dynamisch, lazy-load style in te laden. Geen Javascript = geen inladen van CSS en HTML.
Zo simpel is het. Dan kun je van hot naar her springen om te roepen dat CSS en HTML niet in de Javascript horen, waar ik het mee eens ben, maar dan verandert dit nog steeds niet dat Javascript het wél binnen harkt en in de DOM klapt.

[Zenomyscus]

Echter vind ik persoonlijk die laatste stap volstrekt onnodig. Dat het veel gebeurd wil niet zeggen dat het een goede ontwikkeling is.

Naar mijn mening zit er een verschil tussen applicaties die niet statisch en geindexeerd hoeven worden en websites die je vooral statisch wilt serveren. In het laatste geval zou ik JS, HTML en CSS zoveel mogelijk gescheiden houden, enkel kleine bewerkingen in JS zo ik prima vinden. Bij applicaties zou ik de complete DOM opbouwen in Javascript. CSS blijft bij mij ook daar gescheiden.

[supersnathan94]

Dat is verspilling van processing en als web developer kan ik je vertellen dat we zo min mogelijk JavaScript willen gebruiken en zo kort mogelijke code en alles minified en in een bundle zodat alles maar 1 keer gedownload hoeft te worden (1 HTML bestand, 1 gebundeld CSS bestand en 1 gebundeld JavaScript bestand).

Zo min mogelijk code maken is sowieso altijd goed, maar de rest wat je omschrijft kan ik mij niet zo goed in vinden.

Om dan onnodig JavaScript voor styling te gebruiken is namelijk niet alleen verspilling, maar ook een bad practice of scheiding van opmaak, code en data. Je wilt namelijk die 3 zo veel mogelijk gescheiden houden. Dus geen data in HTML maar alles wordt uit de database, Json of whatever opgehaald en zo veel mogelijk gecached en offline lokaal opgeslagen, je opmaak en styling (HTML en CSS) wil je zo veel mogelijk gescheiden houden (dus geen online CSS en geen JavaScript die styling doet of een mix daarvan) en code wil je ook zo veel mogelijk gescheiden houden.

Data in HTML? Je bedoelt dan pre-rendered HTML? Daar verschillen de meningen nog wel over.

Zelfde geldt voor styling. Juist iets wat met styled components weer in JavaScript wordt gefietst. Komt uiteindelijk wel als CSS je browser in, maar wordt wel door het component zelf geregeld. En een beetje website heeft toch al gauw een 20-tal van dat unieke soort componenten.

[Reactie gewijzigd door supersnathan94 op 23 juli 2024 14:10]

[Dreamvoid]

Alles-met-JS is inmiddels ouderwets te noemen (dat is een beetje de oude Flash-mindset), moderne websites doen de styling met HTML5/CSS, en JS voor de dingen die echt niet anders dan client-side code kunnen zijn - anders is een site niet bruikbaar zonder JS.

Zeker nu Lockdown Mode op de iPhone eraan komt wordt het steeds belangrijker dat sites functioneel blijven zonder JS.

[NoobishPro]

Ik heb geen idee in welke wereld jij leeft, maar JS is juist zo ongeveer de absolute core van HTML5. Heel HTML5 is gemaakt rondom JS en de nieuwe JS mogelijkheden. Dit is zelfs de reden dat het populaire jQuery praktisch irrelevant is geworden, omdat HTML5 de simpliciteit van vanilla JS gebruik dusdanig heeft verhoogd dat de belangrijkste functionaliteit van jQuery intussen al ingedekt was.

[R4gnax]

Ik heb geen idee in welke wereld jij leeft, maar JS is juist zo ongeveer de absolute core van HTML5. Heel HTML5 is gemaakt rondom JS en de nieuwe JS mogelijkheden. Dit is zelfs de reden dat het populaire jQuery praktisch irrelevant is geworden, omdat HTML5 de simpliciteit van vanilla JS gebruik dusdanig heeft verhoogd dat de belangrijkste functionaliteit van jQuery intussen al ingedekt was.

Dat heeft niets maar dan ook 100% niets met HTML5 te maken. Mensen gebruiken te pas en te onpas de naam van die standaard voor zaken die er helemaal niet door gedekt worden.

[lilmonkey]

De moderne HTML specificatie dekt veel meer dan alleen markup. Ook een hoop gerelateerde CSS en DOM API's, en HTTP extensies worden door de standaard behandeld.

[R4gnax]

De moderne HTML specificatie dekt veel meer dan alleen markup. Ook een hoop gerelateerde CSS en DOM API's, en HTTP extensies worden door de standaard behandeld.

Dat zijn allemaal losse specificaties en standaarden.
Fijn dat je ze allemaal onder het kopje 'HTML5' wilt gooien, maar dat klopt dus niet.

[Reactie gewijzigd door R4gnax op 23 juli 2024 14:10]

[lilmonkey]

Ook. Maar veel zaken worden in de HTML specificatie gedefinieerd.

[jerisson]

Vroeger werd JS veelal gebruikt voor zaken die nu standaard met HTML5 en CSS kunnen. Denk dan aan het nagaan of de invoer in een form correct is (nu zijn er "required" en "pattern"), het geven van feedback bij foute invoer (vroeger element met JS zetten, nu de juiste CSS selector gebruiken :valid en :invalid), animaties (CSS keyframes, etc.), responsive UI's, ...

Voor veel van die dingen is JS gewoonweg niet meer nodig, en is JS, zoals @Dreamvoid aangeeft, ouderwets.

Anderzijds ben je voor de meeste inhoudelijk dynamische zaken nog steeds afhankelijk van JS, hetgeen logisch is daar HTML5 en CSS "opmaaktalen" zijn en geen programmeertalen zoals JS.

Voor een gewone website (+95% van het web) vind ik de "alles met JS"-approaches ook gewoon overkill. Voor (web)applicaties daarentegen valt er wel iets voor te zeggen.

[supersnathan94]

Moderne, goed ontworpen websites werken ook zonder JS - tweakers.net bv.

ze zijn bruikbaar, maar goed werken is een ander verhaal. Zo typ ik dit nu in een kompleet losse pagina en kan ik alle andere berichten die mensen hebben geschreven niet meer zien, zelfs het originele artikel niet, dus quoten van informatie uit de tekst kan ik nu wel vergeten,

Het complete menu aan de zijkant is verdwenen en zo ook het menu met knoppen voor opmaak van dit bericht. plaatsen van hyperlinks of externe quotes moet ik nu dus met het handje doen.

Het volledige moderatie systeem is niet bruikbaar en niet inzichtelijk. Ik kan nog wel filteren via de opties hierboven, maar dat betekent weer dat ik een compleet nieuwe pagina geserveerd krijg. ALLES opent als nieuwe pagina, zelfs de "reageer" knop.

Voordeel is wel weer dat je geen advertenties en trackers hebt, nadeel is weer dat geen enkele embedded content meer werkt.

Verder is de ervaring gewoon totaal ruk. Het werkt, maar UX zuigt en het kost heel veel data en reloads. Ik durf wel te stellen dat een javascript handler op een knop minder resources kost dan iedere keer de complete DOM weer opnieuw te laden en alles opnieuw te renderen.

edit: Oh ik kom er net achter dat de notificatie knop niet meer werkt. Zelfde geldt ook voor DM's en vergelijken, "meer" opent slechts de voorpagina in een ander tabblad en je profiel ding ook. Sommige dingen stoppen dus gewoon compleet met werken.

[Reactie gewijzigd door supersnathan94 op 23 juli 2024 14:10]

[lilmonkey]

Totale onzin. Moderne website development is juist enorm JS-focused. Wel is het zo dat met SSR (Server-Side Rendering) de use case van JS uit op de client ondervangen kan worden, maar dat betekent gewoon dat de JS op een andere plek wordt uitgevoerd.

[Dreamvoid]

Moderne, goed ontworpen websites werken ook zonder JS - tweakers.net bv.

Grote voordeel is security, en ook de snelheid - veel client-side JS maakt sites erg zwaar qua geheugen/cpu.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 14:10]

[Verwijderd]

Laat dat moderne maar weg.

[Dreamvoid]

Nou ja, er zijn zeker nog een hoop oudere websites die JS nodig hebben.

[Verwijderd]

Mijn punt is: JS is de nieuwste laag op het html fundament. Als ontwikkelaar vind ik ook dat je daar altijd mee moet beginnen, als je geen gecontroleerde doelgroep hebt. Dan css erop met feature detection en als kers op de taart, als het nodig is, JavaScript.

[Cyb]

Feross (expert in het misbruiken van web api's) gebruikt dit ook voor The Annoying Site, door links van de site in het klembord te plaatsen, waardoor er een kleine kans is dat iemand het bijv. per ongeluk in een chat paste (denkende dat er in het klembord nog andere tekst zit).

[Reactie gewijzigd door Cyb op 23 juli 2024 14:10]

[Verwijderd]

Cyb schreef:

Feross (expert in het misbruiken van web api's) gebruikt dit ook voor The Annoying Site, door links van de site in het klembord te plaatsen, waardoor er een kleine kans is dat iemand het bijv. per ongeluk in een chat paste (denkende dat er in het klembord nog andere tekst zit).

Dank voor de links!

Maar ik maak mij meer zorgen over social engineering waarbij je gevraagd wordt om een URL, IBAN of Bitcoin-adres o.i.d. via het clipboard in een veld (of adresbalk) te plakken, terwijl de handeling op het moment dat jij de bedoelde waarde in dat clipboard zet, tot een clipboard-event in de app of DOM kan leiden - waarna de (web-) applicatie dat clipboard kan overschrijven met een andere waarde (net vóór het plakken dus).

Vooral ervaren "snelle" gebruikers (zoals ik) zouden het controleren, wat er vervolgens geplakt wordt, wel eens over kunnen slaan.

Toegang tot het clipboard is m.i. één van de vele jammer maar helaas voorbeelden van de zwaar-over-de-top featuritis die de W3C in onze (?) "webbrowsers" probeert te pushen.

[Verwijderd]

In Firefox is er de about:config optie om automatisch geselecteerde tekst te verplaatsen naar het klembord.

clipboard.autocopy: is a configuration option for the Firefox web browser; it accepts a boolean. True: Selecting text automatically copies it to the clipboard False (default)

[Verwijderd]

Het probleem hier lijkt niet gerelateerd aan clipboard.autocopy, die -zoals je aangeeft- default op false staat.

Het lijkt het meer generieke probleem dat Javascript in een webpagina, al dan niet na een druk op een (zichtbare, niet als zodanig herkenbare of onzichtbare) knop, of eventueel een ander event, data naar keuze naar het klembord/clipboard kan kopiëren.

Je kunt dat zelf zien in deze W3Schools pagina.

Als Firefox dit zou beperken tot een selectie van de tekst (en evt. andere items) plus de bekende popup box met (in mijn Engelstalige Firefox voor Android) de keuzes Copy | Search | Paste | Select All | Cut, dus niet tevens naar het clipboard zou kopiëren (wat nu óók gebeurt) zou ik dat een stuk verstandiger en veiliger vinden.

Helaas zijn webbrowsers steeds meer bloatware.

[markg85]

Ik vindt dit echt helemaal geen goede feature.
Het is wachten tot je daar een keer een foutje maakt.

Clipboard moet, naar mijn idee, een handmatige gebruikersactie zijn met ctrl+c/v

[thegve]

Dit gaat niet om 'een foutje', het is wachten op een combinatie met een OS lek ergens waardoor er code op de host kan worden uitgevoerd als je het in 'bijvoorbeeld' Word of een ander populair paste-doel plakt, of een lek ergens in het copy/paste systeem van de browser zelf.
Of als dat er niet is, een creatieve social engineering hack. Doe dit bij alle bezoekers van een populaire website (via een reclame JS injectie bijvoorbeeld), en er is vast wel iemand bij die verwachte een URL op zijn clipboard te hebben om iets te betalen oid.
Dit is best wel huge imho.

[markg85]

Ohh, ik zie het ook niet als een foutje.

Ik zie dit als een feature die nooit in een browser had mogen bestaan! Een feature die de nek moet worden omgedraaid. Niet enkel uit onder een vlaggetje, nee weg uit de codebase! Snap niet dat Google en Microsoft (die hebben de spec gemaakt) dit een goed idee vonden.

[R4gnax]

Vooruit; zal ik hem je dan maar geven?
Wil je een clone van bijv. een legitieme Github repository maken om ene patch in te dienen, dan zit daar een handig knopje om de repository URL naar je clipboard te kopiëren, zodat je deze makkelijk in kunt plakken in je CLI git commando.

Enige wat een malicious stukje code wat op een compleet andere browser tab actief kan zijn, hoeft te doen: continu in een lus de inhoud van het clipboard monitoren -- wat kan, want voor zowel de readText als de writeText gesture is de bescherming van een voorafgaand vereiste gebruikersinteractie weg -- en zodra er een Git-achtige URL gevonden wordt, deze subtiel aan te passen naar iets wat onder de controle van een aanvaller staat.

Met UTF-8 international domain names kan dat met gemak gedaan worden op zo'n manier dat die URL er voor het oog nog steeds net echt uitziet.
Dus jij kloont wat je denkt dat een legitieme repository is; en dat is ook grotendeels zo, alleen is als het bijv. een NodeJS package betreft er een postinstall script toegevoegd om ook een malware payload op je systeem te dumpen.

En voilà: rapen gaar.

Conclusie:
Chromium snijdt hiermee op een ongelooflijk lompe manier een hoek af die ze nooit af hadden moeten snijden, en hebben daarmee de deur wagenwijd opengezet voor een enorm gevaarlijke nieuwe variant van een supply-chain aanval.
Fan-tas-tisch!

[Reactie gewijzigd door R4gnax op 23 juli 2024 14:10]

[seapip]

Dit kon altijd al na een gebruikers interactie (gebruiker klikt op een random knop). Maar hier lijkt het geval te zijn dat die gebruikers interactie niet meer vereist is.

De oude sync methode vereiste een selectie van tekst (kan je ook automatiseren): document.execCommand('copy')

De nieuwe methode is async en vereist geen selectie van tekst, daarnaast worden meerdere formaten naast plain text ondersteund: navigator.clipboard.write()/writeText()

Het uitlezen van klembord vereist altijd nog toestemming of handeling van de gebruiker (plakken).

[Reactie gewijzigd door seapip op 23 juli 2024 14:10]

[Maarten69]

Los van dit vind ik het zoenzo gevaarlijk om toegang tot een klembord te geven. Met plakken zou je niet direct gevaar zien, dat klopt.

Als voorbeeld op mijn android telefoon zou het bij android 10 of hoger niet mogelijk moeten zijn voor apps om het klembord te lezen.
Zoals velen weten schuiven gekopieerde teksten door in het klembord. (Circa 30 plaatsen) uit mijn hoofd.
Je kunt dus soms wachtwoorden die je vorige week kopieerde nog terugvinden.

Als ik in een mail of browser een track & trace nummer kopieer, vervolgens postnl app open krijg ik een melding of ik naar dat id wil zoek.
Dit toont aan dat apps wel toegang hebben.

Ik gebruik al een paar jaar Clipboard Sweeper om alle entries te wissen. De app zelf geeft aan dat de app niet (meer) nodig is..

Misschien weten mensen hoe het zit?
Test zelf maar eens:
Doe alsof je iets wilt plakken, kies dan klembord. Je ziet dan veel oude geknipte/gekopieerde tekst en zelfs plaatjes.
Eng.

Edit: het kan ook de DHL app zijn.
Samsung telefoon idd @hieronder.

[Reactie gewijzigd door Maarten69 op 23 juli 2024 14:10]

[seapip]

- snip -

Blijkbaar zijn er idd meerdere entries weet alleen niet of de toetsenbord optie om dit uit te zetten ook het systeem limiteerd tot een enkele entry.

Of dat de systeem API om de lijst met entries uit te lezen simpelweg doorverwijst naar de implementatie en opslag van de toetsenbord app zelf terwijl het systeem maar een enkele entry ondersteund.

[Reactie gewijzigd door seapip op 23 juli 2024 14:10]

[Soldaatje]

Dat lijkt een functie te zijn van het toetsenbord, het Samsung toetsenbord heeft dat en Gboard waarschijnlijk ook. Je zou ook een simpel toetsenbord kunnen gebruiken die het klembord niet opslaat.
Dat maakt voor deze bug in de browser niet uit want die zal alleen bij het huidige, laatst gekopieerde item kunnen komen.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 14:10]

[F_J_K]

Met plakken zou je niet direct gevaar zien, dat klopt.

Dat ben ik niet met je eens. Als er 'zomaar' tekst in je klembord wordt gezet, wordt er zonder dat je het weet iets overschreven. Wat je misschien nog niet naar het doel had geplakt en nu permanent kwijt bent.

[Slashdotter]

No worries, in Windows kan je met de WIN + V shortcut het uit je clipboard history terughalen.

[Maarten69]

Schreef het misschien beetje onduidelijk. Ik zie zelf het gevaar wel.
Ik pakte net m'n vrouws mobiel en liet het aan haar zien. Die schrok er ook van.
Nig iemand een tip voor Samsung like toetsenbord zonder deze functionaliteit?

[rko4u]

Als ik het artikel goed lees gaat dit om kopieren naar het klembord. Kan ook gevaarlijk zijn, maar als developer ook reuze handig, als ik bijvoorbeeld een stuk code wil kopieren.

[avdongen]

Code kopieren? IDE's zouden alleen mogen knippen en plakken (verplaatsen). Elke andere kopieer-actie gaat in tegen DRY.

[avdongen gaat weer terug in zijn hok]

[rko4u]

Ik heb het over kopieren van voorbeeldcode vanaf het internet, maar als je het over DRY hebt, weer je mogelijk ook niet wat dat is.

[kodak]

Het probleem lijkt dus dat ontwikkelaars de vrijheid nemen om te bepalen hoe ze zichzelf meer rechten tot het systeem van de gebruikers geven om een eigen probleem op te lossen. Daarbij is onvoldoende verantwoordelijkheid om voor release te laten controleren of dit wel verstandig is.

[MazDaMan1970]

Slechte zaak, aangezien dit in de nabije toekomst vast voor allerhand vage hack pogingen zal gaan zorgen. Hopelijk kan dit via een feature-flag uitgeschakeld worden!

[Metal spoon]

Ik heb laatst de navigator api moeten gebruiken voor het automatisch kopiëren van een gegenereerde URL als je op een knop drukt.
Het moest ook werken op mobiele browsers maar ik kreeg het maar niet aan de praat.
Wat blijkt, om die navigator clipboard api op telefoons te kunnen gebruiken moet het met https geserveerd worden, maarja dat had mijn dev servertje natuurlijk niet.