in browser port scanning... altro?
Cari nexiani, un amico molto tecnico mi segnala questo articolo molto tecnico, che in buona sostanza rivela come Ebay e molti altri clienti di LexisNexis utilizzino *anche* la tecnica del port scanning del PC sul quale funziona il browser (via Javascript) per profilare i visitatori. Il port scanning è una tecnica che serve per sapere quali porte sono "aperte" su un host e di conseguenza stabilire quali servizi sono in funzione sul quell'host. Siamo sicuri che una tecnica analoga non possa essere usata anche per **esporre** un'intera rete locale attraverso un reverse tunnell "in browser" sfruttando questa tecnica: https://github.com/MDSLab/wstun?!? (chiedo scusa se ai non addetti ai lavori sembra arabo) Qualche esperto websocket/Javascript in lista può dirmi se sono eccessivamente paranoico? «Ebay is port scanning visitors to their website - and they aren't the only ones», by Dan Nemec, 24 May 2020 https://blog.nem.ec/2020/05/24/ebay-port-scanning/ --8<---------------cut here---------------start------------->8--- [...] actually discussing a different type of port scanning, one initiated directly by a website the target loads in their browser. It’s an ingenius, if not insidious, technique that allows would-be port scanners to paradrop straight into an internal network and scan it using Javascript from within the browser context. As an aside, this is something that a browser extension could block, however the company behind the port scanning uses techniques to prevent widespread blocking of their trackers, as we’ll see later. How Browser Port Scanning Works While modern browsers allow Javascript to make requests to other domain names than the one you’re currently visiting (e.g. www.ebay.com), they layer on security controls to ensure the target data allows the calling website to access it. This prevents, for example, a malicious website from requesting the account details from you bank’s website. However, even without knowing the contents of the remote site, details about the connection itself (such as the time it takes to connect or time out) can be used to infer whether or not a website exists at the given host and port. A bit of Javascript code can wrap that into a package and allow any site to scan a user’s internal network, determining which IP addresses and ports have services running. Further, because many well-known services are commonly available on the same port (there is a registration page, but it’s more of a guideline than a hard and fast rule), it’s possible to also infer some programs that a user may be running on their network depending on whether the port is open or not. [...] In trying to load Ebay locally I found that I couldn’t replicate the behavior in Linux even after spoofing a Windows User Agent and disabling all of my extensions. There must be some check hidden in the Javascript, but as of yet I haven’t found one. After that, I loaded a Windows VM, installed the latest Edge, fired up https://www.ebay.com, and I finally replicated the port scanning behavior. However, I had some trouble replicating the behavior reliably, and after some trial and error I found that https://signin.ebay.com/ was far more reliable for triggering the port scanning. [...] To summarize what we’ve found so far: * Ebay collects data on whether certain ports are open on your local PC * This data is shipped to an Ebay domain, but does not seem to be used * otherwise Additional data like User Agent and IP are also sent [...] the domain where data is exfiltrated is not a subdomain of ebay.com - it’s ebay-us.com. Still, a quick check shows that it’s owned by somebody at Ebay, so at the very least it isn’t phishing malware. Twitter user Armchair IR pointed out that similar behavior has been seen by Facebook and it traced to a company called ThreatMetrix, an identity tracking/anti-fraud company. Checking the DNS records for src.ebay-us.com, sure enough it’s a CNAME to h-ebay.online-metrix.net, a domain owned by ThreatMetrix Inc. [...] It’s not just Ebay scanning your ports, there is allegedly a network of 30,000 websites out there all working for the common aim of harvesting open ports, collecting IP addresses, and User Agents in an attempt to track users all across the web. And this isn’t some rogue team within Ebay setting out to skirt the law, you can bet that LexisNexis lawyers have thoroughly covered their bases when extending this service to their customers (at least in the U.S.). --8<---------------cut here---------------end--------------->8--- Saluti, Giovanni. -- Giovanni Biscuolo
Lo fa anche il governo Russo. E sì permette anche di mappare una rete interna. Si tratta di un attacco che ho ideato 2 anni fa, come esempio di una vasta classe di attacchi possibili su un browser, visto che mi si chiedeva un Proof-of-concept. O meglio, qui si fanno le cose complicate: basta cercare di caricare una GIF e misurare il tempo in cui ricevi l'errore. La segnalazione a Mozilla (e successivamente a Chrome) è qui: https://bugzilla.mozilla.org/show_bug.cgi?id=1487081 L'attacco in questione fu uno dei primi che mi venne in mente e lo descrissi qui: https://dev.to/shamar/the-meltdown-of-the-web-4p1m Successivamente, uno dei miei tanti detrattori inziali si accorse che ci si poteva appunto mappare l'intera rete https://rain-1.github.io/in-browser-localhostdiscovery Ma in realtà, in un mondo di IoT con telecamere accessibili via HTTP, ci si può fare molto di più! ;-) D'altronde è solo uno dei possibili attacchi che appartengono a quella classe. Ne descrissi altri, in varie sedi, ma sembrava che a nessuno fregasse niente. Peraltro, se è venuto in mente a me due anni fa, probabilmente era già molto diffuso in rete perché io sono solo un programmatore competente, non un ethical hacker esperto in penetration tests! Non sono mica un "esperto", io... ;-) DUE anni dopo questi attacchi sono ancora possibili. D'altronde, come mi risposero da Mozilla nella issue, "this is the Web functioning as designed" E vedrai quando tutti useranno il DNS-over-HTTPS di Cloudflare! Avremo un canale cifrato ed insospettabile per inviare ad un server DNS tutti i dati sottratti attraverso questi trucchetti! Giacomo
Aggiungo una nota Giovanni, anche se so che a te sembrerà scontata. L'aspetto più grave di questa classe di attacchi via JavaScript è che ovviamente sono personalizzabili se si è in condizione di indentificare l'utente. Ed in un Web come quello mainstream, in cui ogni sito Web integra script provenienti da decine di sorgenti (e CDN) è possibile attaccare un visitatore di un sito completamente ignaro. E naturalmente, con un header HTTP di Cache-Control appropriato, puoi cancellare qualsiasi traccia dell'attacco dal PC della vittima ricaricando i file dell'attacco con versioni innocue. Se fai attenzione a preservare la dimensione dei file, nemmeno negli eventuali log del proxy HTTP rimarrà alcuna anomalia osservabile. Giacomo On Sunday, 7 June 2020, Giacomo Tesio <giacomo@tesio.it> wrote:
Lo fa anche il governo Russo. E sì permette anche di mappare una rete interna.
Si tratta di un attacco che ho ideato 2 anni fa, come esempio di una vasta classe di attacchi possibili su un browser, visto che mi si chiedeva un Proof-of-concept. O meglio, qui si fanno le cose complicate: basta cercare di caricare una GIF e misurare il tempo in cui ricevi l'errore.
La segnalazione a Mozilla (e successivamente a Chrome) è qui:
https://bugzilla.mozilla.org/show_bug.cgi?id=1487081
L'attacco in questione fu uno dei primi che mi venne in mente e lo descrissi qui:
https://dev.to/shamar/the-meltdown-of-the-web-4p1m
Successivamente, uno dei miei tanti detrattori inziali si accorse che ci si poteva appunto mappare l'intera rete
https://rain-1.github.io/in-browser-localhostdiscovery
Ma in realtà, in un mondo di IoT con telecamere accessibili via HTTP, ci si può fare molto di più! ;-)
D'altronde è solo uno dei possibili attacchi che appartengono a quella classe. Ne descrissi altri, in varie sedi, ma sembrava che a nessuno fregasse niente.
Peraltro, se è venuto in mente a me due anni fa, probabilmente era già molto diffuso in rete perché io sono solo un programmatore competente, non un ethical hacker esperto in penetration tests! Non sono mica un "esperto", io... ;-)
DUE anni dopo questi attacchi sono ancora possibili. D'altronde, come mi risposero da Mozilla nella issue,
"this is the Web functioning as designed"
E vedrai quando tutti useranno il DNS-over-HTTPS di Cloudflare! Avremo un canale cifrato ed insospettabile per inviare ad un server DNS tutti i dati sottratti attraverso questi trucchetti!
Giacomo
Ciao Giacomo, so di sfondare un portone aperto con te, quindi quello che ci diciamo tra noi praticamente vale come uno sfogo tra due brontoloni di mezza età considerati competenti ma un po' troppo paranoici da molti, persino da coloro cui vogliamo bene :-O Giacomo Tesio <giacomo@tesio.it> writes:
Lo fa anche il governo Russo. E sì permette anche di mappare una rete interna.
Oh certo, lo davo per scontato. Rimane il mio terrificante dubbio: è possibile usare il browser _anche_ per attivare un reverse tunnell via websocket via Javascript per farci passare traffico TCP (o UDP) arbitrario?!? Di solito do per scontato che tutte le macchine sulla mia rete locale (le appliances "smart" sono _disconnesse_ dalla rete qui) siano fidate e per questo alcuni servizi interni sono meno blindati del solito: non vorrei essere costretto a considerare **ostile** la mia rete locale per il solo fatto che c'è una macchina con un browser :-O
Si tratta di un attacco che ho ideato 2 anni fa, come esempio di una vasta classe di attacchi possibili su un browser, visto che mi si chiedeva un Proof-of-concept. O meglio, qui si fanno le cose complicate: basta cercare di caricare una GIF e misurare il tempo in cui ricevi l'errore.
La segnalazione a Mozilla (e successivamente a Chrome) è qui:
Aggià, quando ho scritto il messaggio dimenticavo di "riaprire una vecchia ferita": confesso di non aver letto tutto tutto dei vari thread annessi e connessi, ma ho letto molto :-) Per dirtela tutta l'ultimo dei miei problemi è che in qualche modo un "sito esterno" riesca a *infiltrare* contenuti illegali o meno nella cache del mio browser: so come difendermi da questa specie di attacchi puerili (e aiutare chi ha la sfortuna di conoscermi personalmente a difendersi, se lo capisce). Quando navigo "il web" e più del 60% (a spanne) di quello che visito non funziona senza Javascript dico la verità: mi arrendo e lo abilito, affidandomi a qualche buona pratica e a uBlockOrigin (e qualche volta LibreJS)... provo di tanto in tanto a usare NoScript ma l'esperienza di navigazione è terribile. E in questa casa non sono l'unico a usare il browser; neanche in ufficio :-S ...però, però, però più passa il tempo più mi rendo conto di quanto sia disperata la situazione della sicurezza del **mio** browser, anche se il **mio** browser di default è ungoogled-chromium installato via Guix (in poche parole un binario ultra affidabile) La morale della favola è che per tenere al sicuro la mia rete locale dal mio browser dovrei usare una virtual machine (o un container) con tanto di rete dedicata... che menata! [...]
Successivamente, uno dei miei tanti detrattori inziali si accorse che ci si poteva appunto mappare l'intera rete
Me lo ero perso: interessante
Ma in realtà, in un mondo di IoT con telecamere accessibili via HTTP, ci si può fare molto di più! ;-)
Tipo "Lasciate ogni speranza oh voi ch'entrate" (...o uscite?!?) [...]
DUE anni dopo questi attacchi sono ancora possibili. D'altronde, come mi risposero da Mozilla nella issue,
"this is the Web functioning as designed"
E purtroppo hanno anche la faccia tosta di avere ragione: grazie a Javascript il web oggi è progettato da far schifo, e con Webassembly le cose peggioreranno a livelli tali che - almeno mi auguro - crollerà tutto. La cosa è talmente drammatica che per chi distribuisce browser (il cui sviluppo è finanziato da chi? in che modo?) significherebbe buttare nel cestino gli ultimi 10 anni di penosi sviluppi e tornare a XHTML e un ecosistema di **trasmissione ipertesto** sano. Chi ha pensato di **abusare** del browser per trasformare il web in un sistema computazionale distribuito ha fatto proprio una boiata intergalattica. Punto. Chiudo con le parole di "spycrowsotf" nel thread Lobste.rs che hai salvato: http://www.tesio.it/documents/Mozilla-Bug1487081-Attachments/Undetectable_Re... --8<---------------cut here---------------start------------->8--- [...] If you want to run something, run it on your servers and get off my laptop, phone, tv or even production-machines. Those are mine and if your website can’t handle it, then your website is simply terrible from a user experience viewpoint, dreadfully inefficient and doomed to come back hunting you when you are already in a bind because of an entirely different customer or issue. As a consequence of this way of thinking, a few web-driven systems I wrote more than a decade ago, are still live and going strong without a single security incident and without any performance issues while at the same time reaping the benefits of the better hardware they’ve been migrated to over the years. Therefore it is still my firm belief that a browser is primarily a tool to display content from random URLs I throw at it and not an application platform which executes code from the URLs thrown at it. --8<---------------cut here---------------end--------------->8--- [...] La cosa che mi rattrista molto è che ormai da più di 10 anni molte persone molto in gamba hanno capito perfettamente come (ri)costruire un ecosistema di comunicazione sano ma sono costretti a farlo coi fichi secchi perché le risorse sono interamente risucchiate da chi ci sguazza alla grande in questa tristissima situazione. Saluti. Giovanni. -- Giovanni Biscuolo
Ciao Giovanni, il private network scan tramite browser e’ una realta’ ormai consolidata purtroppo e in genere si usa WebRTC per farlo: https://github.com/diafygi/webrtc-ips Il sito del NYTimes lo usa/usava per distinguere il traffico generato da bot da quello degli utenti reali (almeno questa e’ la versione ufficiale): https://news.ycombinator.com/item?id=9893561 Questo articolo di Princeton ne ha verificato l’adozione sui siti piu’ popolari di Internet nel 2016 (sezione 6.3): https://dl.acm.org/doi/pdf/10.1145/2976749.2978313 Tendenzialmente queste tecniche sono usate per anti-frode o per riconoscere il traffico dei bot. Come quasi sempre accade con la raccolta di dati, tuttavia, non c’e’ modo di verificare quanto viene dichiarato. Stefano On 7 Jun 2020, at 18:39, Giovanni Biscuolo <giovanni@biscuolo.net<mailto:giovanni@biscuolo.net>> wrote: Cari nexiani, un amico molto tecnico mi segnala questo articolo molto tecnico, che in buona sostanza rivela come Ebay e molti altri clienti di LexisNexis utilizzino *anche* la tecnica del port scanning del PC sul quale funziona il browser (via Javascript) per profilare i visitatori. Il port scanning è una tecnica che serve per sapere quali porte sono "aperte" su un host e di conseguenza stabilire quali servizi sono in funzione sul quell'host. Siamo sicuri che una tecnica analoga non possa essere usata anche per **esporre** un'intera rete locale attraverso un reverse tunnell "in browser" sfruttando questa tecnica: https://github.com/MDSLab/wstun?!? (chiedo scusa se ai non addetti ai lavori sembra arabo) Qualche esperto websocket/Javascript in lista può dirmi se sono eccessivamente paranoico? «Ebay is port scanning visitors to their website - and they aren't the only ones», by Dan Nemec, 24 May 2020 https://blog.nem.ec/2020/05/24/ebay-port-scanning/ --8<---------------cut here---------------start------------->8--- [...] actually discussing a different type of port scanning, one initiated directly by a website the target loads in their browser. It’s an ingenius, if not insidious, technique that allows would-be port scanners to paradrop straight into an internal network and scan it using Javascript from within the browser context. As an aside, this is something that a browser extension could block, however the company behind the port scanning uses techniques to prevent widespread blocking of their trackers, as we’ll see later. How Browser Port Scanning Works While modern browsers allow Javascript to make requests to other domain names than the one you’re currently visiting (e.g. www.ebay.com<http://www.ebay.com>), they layer on security controls to ensure the target data allows the calling website to access it. This prevents, for example, a malicious website from requesting the account details from you bank’s website. However, even without knowing the contents of the remote site, details about the connection itself (such as the time it takes to connect or time out) can be used to infer whether or not a website exists at the given host and port. A bit of Javascript code can wrap that into a package and allow any site to scan a user’s internal network, determining which IP addresses and ports have services running. Further, because many well-known services are commonly available on the same port (there is a registration page, but it’s more of a guideline than a hard and fast rule), it’s possible to also infer some programs that a user may be running on their network depending on whether the port is open or not. [...] In trying to load Ebay locally I found that I couldn’t replicate the behavior in Linux even after spoofing a Windows User Agent and disabling all of my extensions. There must be some check hidden in the Javascript, but as of yet I haven’t found one. After that, I loaded a Windows VM, installed the latest Edge, fired up https://www.ebay.com, and I finally replicated the port scanning behavior. However, I had some trouble replicating the behavior reliably, and after some trial and error I found that https://signin.ebay.com/ was far more reliable for triggering the port scanning. [...] To summarize what we’ve found so far: * Ebay collects data on whether certain ports are open on your local PC * This data is shipped to an Ebay domain, but does not seem to be used * otherwise Additional data like User Agent and IP are also sent [...] the domain where data is exfiltrated is not a subdomain of ebay.com<http://ebay.com> - it’s ebay-us.com<http://ebay-us.com>. Still, a quick check shows that it’s owned by somebody at Ebay, so at the very least it isn’t phishing malware. Twitter user Armchair IR pointed out that similar behavior has been seen by Facebook and it traced to a company called ThreatMetrix, an identity tracking/anti-fraud company. Checking the DNS records for src.ebay-us.com<http://src.ebay-us.com>, sure enough it’s a CNAME to h-ebay.online-metrix.net<http://h-ebay.online-metrix.net>, a domain owned by ThreatMetrix Inc. [...] It’s not just Ebay scanning your ports, there is allegedly a network of 30,000 websites out there all working for the common aim of harvesting open ports, collecting IP addresses, and User Agents in an attempt to track users all across the web. And this isn’t some rogue team within Ebay setting out to skirt the law, you can bet that LexisNexis lawyers have thoroughly covered their bases when extending this service to their customers (at least in the U.S.). --8<---------------cut here---------------end--------------->8--- Saluti, Giovanni. -- Giovanni Biscuolo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it<mailto:nexa@server-nexa.polito.it> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa — Stefano Traverso, PhD Chief Technical Officer @ Ermes Cyber Security Mail: s.traverso@ermessecurity.com<mailto:s.traverso@ermessecurity.com> Mobile: +393280367702
Ciao Stefano, Stefano Traverso <s.traverso@ermessecurity.com> writes: [...]
Tendenzialmente queste tecniche sono usate per anti-frode o per riconoscere il traffico dei bot. Come quasi sempre accade con la raccolta di dati, tuttavia, non c’e’ modo di verificare quanto viene dichiarato.
Grazie per gli ulteriori puntatori, li conserverò per le lunghe sere invernali quando racconterò ai miei nipoti quanto era triste il mondo in cui vivevamo, nel quale per consultare pagine web senza rischiare di essere oggetto di attacchi informatici era necessario indossare un analogo virtuale delle tute contro il rischio biochimico. [...] Mi rimane il mio dubbio terrificante:
Siamo sicuri che una tecnica analoga non possa essere usata anche per **esporre** un'intera rete locale attraverso un reverse tunnell "in browser" sfruttando questa tecnica: https://github.com/MDSLab/wstun?!?
[...] Saluti, Giovanni -- Giovanni Biscuolo
On 08/06/2020, Giovanni Biscuolo <giovanni@biscuolo.net> wrote:
Mi rimane il mio dubbio terrificante:
Siamo sicuri che una tecnica analoga non possa essere usata anche per **esporre** un'intera rete locale attraverso un reverse tunnell "in browser" sfruttando questa tecnica: https://github.com/MDSLab/wstun?!?
Risponderti è più complesso di quanto non sembri. I WebSocket non sono semplici socket TCP/UDP: anche dopo l'handshake con il servizio la comunicazione avviene attraverso uno scambio di messaggi composti da uno o più frame dal formato prestabilito https://tools.ietf.org/html/rfc6455#section-5 Dunque IN TEORIA non puoi usare un WebSocket per accedere ad un comune servizio telnet, primo perché non risponderebbe all'handshake, poi perché non rispetterebbe il protocollo. Tuttavia, se hai dei servizi WebSocket sulla tua rete (consapevolmente o meno), quelli sono ad un DNS rebinding di distanza da qualsiasi sito web che visiti con JavaScript abilitato. E naturalmente, se ti installi (consapevolmente o meno) un proxy WebSocket sulla tua rete o sulla tua macchina, a quel punto ogni sito web potrà accedervi allo stesso modo ed il proxy tradurrà l'eventuale protocollo telnet (o SSH o IMAP o...) verso le macchine di interesse. Dunque IN TEORIA, se usano WebSocket per accedere a servizi non WebSocket, i membri del WHATWG possono dire che la responsabilità è tua che non hai impedito a tuo figlio di installare il videogioco infetto dal malware. Ed IN TEORIA, la pratica corrisponde alla teoria. Ma in pratica non è così. La realtà è questa (prendo solo i primi link che ho sottomano): https://www.zdnet.com/article/google-reveals-chrome-zero-day-under-active-at... https://www.cisecurity.org/advisory/critical-patches-issued-for-microsoft-pr... https://www.theregister.com/2020/06/04/firefox_77_security_fixes/ Qui si enunciano convenientemente i gloriosi fix... ma fino al fix? Esatto, per parafrasare le tue parole: per tenere al sicuro la tua rete locale dal tuo browser DEVI usare una macchina dedicata con tanto di rete dedicata...
Grazie per gli ulteriori puntatori, li conserverò per le lunghe sere invernali quando racconterò ai miei nipoti quanto era triste il mondo in cui vivevamo, nel quale per consultare pagine web senza rischiare di essere oggetto di attacchi informatici era necessario indossare un analogo virtuale delle tute contro il rischio biochimico.
... o disabilitare JavaScript. ;-) Giacomo
Ciao Giacomo, Giacomo Tesio <giacomo@tesio.it> writes:
On 08/06/2020, Giovanni Biscuolo <giovanni@biscuolo.net> wrote:
Mi rimane il mio dubbio terrificante:
Siamo sicuri che una tecnica analoga non possa essere usata anche per **esporre** un'intera rete locale attraverso un reverse tunnell "in browser" sfruttando questa tecnica: https://github.com/MDSLab/wstun?!?
Risponderti è più complesso di quanto non sembri.
I WebSocket non sono semplici socket TCP/UDP: anche dopo l'handshake con il servizio la comunicazione avviene attraverso uno scambio di messaggi composti da uno o più frame dal formato prestabilito https://tools.ietf.org/html/rfc6455#section-5
Dunque IN TEORIA non puoi usare un WebSocket per accedere ad un comune servizio telnet, primo perché non risponderebbe all'handshake, poi perché non rispetterebbe il protocollo.
OK grazie mille di aver parzialmente colmato questa mia ignoranza (parzialmente perché non ho ancora stidiato websocket): non hai idea di quanto mi faccia stare tranquillo questa cosa :-) [...]
Dunque IN TEORIA, se usano WebSocket per accedere a servizi non WebSocket, i membri del WHATWG possono dire che la responsabilità è tua che non hai impedito a tuo figlio di installare il videogioco infetto dal malware.
E hanno ragione, è per questo che io - SCIENTIFICAMENTE - do per scontato che qualsiasi macchina che non adotta software libero **full stack** (possibilmente dal bootloader in su) è potenzialmente infetta e va trattata di conseguanza; diciamo che fino ad oggi me la sono cavata adottando sistemi operativi liberi (purtroppo non basta, ma è quello che posso fare oggi) *e* CONFINANDO ogni altra schifezza in una rete ALTAMENTE militarizzata. :-D
Ed IN TEORIA, la pratica corrisponde alla teoria. Ma in pratica non è così.
La realtà è questa (prendo solo i primi link che ho sottomano):
https://www.zdnet.com/article/google-reveals-chrome-zero-day-under-active-at...
https://www.cisecurity.org/advisory/critical-patches-issued-for-microsoft-pr...
https://www.theregister.com/2020/06/04/firefox_77_security_fixes/
Mamma mia, ogni volta che ricevo nella mia inbox la notifica di aggiornamenti di sicurezza dei broswer mi rovinano la giornata :-S
Qui si enunciano convenientemente i gloriosi fix... ma fino al fix?
... Fox?!?
Esatto, per parafrasare le tue parole: per tenere al sicuro la tua rete locale dal tuo browser DEVI usare una macchina dedicata con tanto di rete dedicata...
Grazie per gli ulteriori puntatori, li conserverò per le lunghe sere invernali quando racconterò ai miei nipoti quanto era triste il mondo in cui vivevamo, nel quale per consultare pagine web senza rischiare di essere oggetto di attacchi informatici era necessario indossare un analogo virtuale delle tute contro il rischio biochimico.
... o disabilitare JavaScript. ;-)
Mi piacerebbe ma ci sono un sacco di servizi a me indispensabili a cui posso accedere solo se JS è abilitato: vorrei contattare a uno a uno ogni songolo sviluppatore di quei servizi per *intimarli* a smetterla di usare JS mettendo a rischio la mia sicurezza, ma faccio prima a mettere in pista un sistema per "confinare" tutti i miei browser in un container innoquo :-) [1] Ciao, Giovanni [1] https://guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html («Another typical use case for containers is to run security-sensitive applications such as a web browser.») -- Giovanni Biscuolo
On Tuesday, 9 June 2020, Giovanni Biscuolo <giovanni@biscuolo.net> wrote:
Dunque IN TEORIA, se usano WebSocket per accedere a servizi non WebSocket, i membri del WHATWG possono dire che la responsabilità è tua che non hai impedito a tuo figlio di installare il videogioco infetto dal malware.
E hanno ragione...
No. Si chiama "victim blaming". È come se (attenzione: COME SE) avessero creato il covid 19 nella speranza di ridurre l'inquinamento planetario e poi se la prendessero con i malati perché non cambiano tutti i giorni le mascherine FFP3! Sono i membri del WHATWG, che hanno reso il Web questo colabrodo, non tu! E contrariamente a te (e me) loro potrebbero facilmente intervenire per tappare il buco più grosso. Ma non lo fanno. La responsabilità degli exploit e dei data branch che vengono effettuati attraverso il browser è loro, non tua. Ed anche a livello legale, dovrebbero risponderne. Dopo un paio di risarcimenti milionari, JS verrebbe disabilitato di default e la stragrande maggioranza dei siti web smetterebbe di usarlo. Giacomo
Ciao Giacomo, Giacomo Tesio <giacomo@tesio.it> writes:
On Tuesday, 9 June 2020, Giovanni Biscuolo <giovanni@biscuolo.net> wrote:
Dunque IN TEORIA, se usano WebSocket per accedere a servizi non WebSocket, i membri del WHATWG possono dire che la responsabilità è tua che non hai impedito a tuo figlio di installare il videogioco infetto dal malware.
E hanno ragione...
No. Si chiama "victim blaming".
Hai ragione, sono stato troppo cattivo... ma IMHO ogni utente deve sentirsi responsabile della sicurezza del software che installa sui propri sistemi... ma il discorso è complesso per affrontarlo qui. ...e sì, sostanzialmente oggi il browser è un sistema per installare software sul proprio computer. [...]
Sono i membri del WHATWG, che hanno reso il Web questo colabrodo, non tu!
Sì sì, su questo ho già commentato abbastanza e concordo sostanzialmente con te.
E contrariamente a te (e me) loro potrebbero facilmente intervenire per tappare il buco più grosso.
Ma non lo fanno. La responsabilità degli exploit e dei data branch che vengono effettuati attraverso il browser è loro, non tua.
Ed anche a livello legale, dovrebbero risponderne. Dopo un paio di risarcimenti milionari, JS verrebbe disabilitato di default e la stragrande maggioranza dei siti web smetterebbe di usarlo.
Le vie legali non hanno mai aiutato a migliorare il web, mi pare. Se "domani" sparisse il codice JS dai browser il 70% dei servizi disponibili via web smetterebbe di funzionare... quanto è triste la situazione! Purtroppo ormai il web è drogato di Javascript che viene eseguito nel browser [1], siamo nel pieno dell'era della Javascript Trap https://www.gnu.org/philosophy/javascript-trap.html.en... e saremo intrappolati ancora per diversi anni :-S Grazie, Giovanni. [1] per il Javascript eseguito lato server i problemi sono dei proprietari del server -- Giovanni Biscuolo
participants (3)
-
Giacomo Tesio -
Giovanni Biscuolo -
Stefano Traverso