Un malware su 6000 siti basati su WordPress

ho capito che a te piacciono gli effettini e non puoi vivere senza...
cmq, liberissimo di tenere js attivo e ricorrere a mille addon ed antivirus.

Come rilevi una infezione lato client scusa?
Questi sono server compromessi, e un server per definizione risponde con qualcosa se lo chiami, questi sono server che rispondono con pagine infette.

Un client infetto come lo rilevi da Internet? Risponde mica perchè non è un server.

Gli studi che hanno fatto in passato erano basati su botnet il cui protocollo di comunicazione era stato hackerato, quindi si poteva comunicare con questi PC compromessi usando gli stessi canali dei criminali che li controllavano.

Se non sai i protocolli/crittazione/chessò coi client infetti non ci parli.

Si ma ripeto, tu stai valutando solo un tipo di utenza, ovvero un utente generalista che fa browsing su un sito.
In ambito aziendale, o lavorativo in genere quasi nessuno usa codice sviluppato in proprio, ma nemmeno le società che sviluppano, per le necessità interne (es anagrafiche, documentali, gestionali etc etc) costa meno adottare soluzioni già pronte e sviluppate da terze parti che perdere tempo a svilupparle custom in proprio, è tutto tempo sottratto a progetti e quindi fatturazione.
L'imperativo da ormai 10 anni è avere interfacce web based che sostituiscano i client locali (cazzata immonda imho, ma non decido io le sorti dell'IT) e quindi ti ritrovi costretto a usare prodotti infarciti di javascript che non hai sviluppato tu, dove non sai cosa avviene dietro le quinte.
Oppure ti ritrovi a lavorare su progetti già avviati dove non sai come funzionano e non sai a quali vulnerabilità sono soggetti (i vulnerability assessment costano), eppure ci devi lavorare sopra.
Insomma come già detto da altri l'approccio "whitelist" non è sostenibile, è comunque inaffidabile e non è gestibile a tempo indeterminato o in generale.

Io capisco la tua avversione al javascript, però è inevitabile doverlo usare su siti/software trustati e non; puoi concederti il lusso di schivarlo (se ci riesci) in ambito privato ma tutto questo ha certamente un costo in termini di tempo e features a cui rinunci, e non è realistico fare altrettanto in altri ambiti.
Oggettivamente poi bisogna ammettere per onestà intellettuale che l'uso avanzato di javascript (ovvero l'uso che se ne sta facendo negli ultimi anni con millemila framework diversi, non certo la validazione delle form che si faceva 15 anni fa) ha letteralmente rivoluzionato il web (in positivo e in negativo), non se ne parla mai se non in ambito tecnico però è stata una rivoluzione paragonabile se non superiore a quella del web dinamico e dei linguaggi di scripting server side che l'hanno permesso (php, jsp, asp etc etc).

cosa c'entrano le "necessità interne" aziendali e una intranet con il wide (wild) web?
è ovvio che su una intranet locale per la gestione di sistemi interni lo scripting lo tieni attivo, anche perchè se non ti fidi della tua stessa rete tanto vale spegnere i pc.
si parla di navigazione dell'utente comune su siti generalisti.

Sta dicendo che non si sa se fidarsi neanche dei siti interni delle webapplicashions aziendali, e che la decisione di fidarsi è presa così sulla parola senza fare test di sicurezza, esattamente come viene fatto per i siti fuori.

Cioè che l'unico javascript sicuro è un javascript morto, sia in azienda che sul web.

beh, se uno sviluppatore professionale piglia degli script di terzi e li sbatte sul suo sistema di produzione senza dare un occhio a cosa fanno...
beh, forse non è proprio così pazzescamente "professionale"
Va bene per il sitino amatoriale fatto gratis o quasi, non per roba fatta da (presunti) professionisti, imho.

no, quello l'ho detto io

Hai una strana idea di come funziona a livello aziendale. Il sistema di produzione non è "dello sviluppatore" ma della ditta, lo sviluppatore è un esecutore, deve eseguire ordini del management.

I manager che non sanno accendere un portatile si fanno intortare da un venditore che usa una webapplicashion scriptata (cioè falsa) e usa le giuste buzzword del momento, comprano il software/webapplicashion e poi lo danno ai professionisti/sistemisti/admin da far girare sulle macchine dell'azienda.

Punto.

Ai professionisti viene solo chiesto di far girare questo schifo, non di controllare che sia sicuro, nè di renderlo migliore.

Io sto dicendo che su quel punto ti sta dando ragione.

in tal caso si suppone che se compri un sw (per quanto merdoso), ti fidi del sw.
altrimenti sarebbe come comprare office e poi non fidarsi a lanciarne l'exe.

cmq, per tornare al succo del discorso, ed escludendo i casi di ambienti chiusi e "locali" suddetti, un sito di contenuti grafici e testuali che per funzionare nei suoi elementi basilari richiede necessariamente JS attivo imho è una merda

ovvio che roba più complessa (tipo mappe ecc.) lo scripting ci vuole. Ma non per farmi leggere una cagata di articoletto, vedere due foto o aprire un menu che si fa benissimo coi css.
liberi di pensarla diversamente

Bella discusisone, ma



Ghostery è il tracker dei tarcker. Praticamente si ferma i singoli tracker, ma colleziona dati, li analizza e rivende le analisi. Io userei altre estensioni per controllare le richieste di contenuti e script da siti terzi, certo sono piu spartane e bisogna whitelistare tutto su ognuna e quasi fanno innervosire alla prima visita di un sito, ma se uno ha veramente questa sensibilità su questi temi tanto vale che lo faccia correttamente, non avrebbe senso sapere che un sito ha n tracker se poi alla fine questi tracker le informazioni che vogliono indirettamente le comprano lo stesso. Anzi, forse è peggio, perchè un tracker traccia solo visitando tra quelli in cui è installato, ghostery ha in mano tutta la cronologia, bella mole di info direi


Concordo in pieno, ma non credo sia possibile tornare indietro, ormai la quantità di contenuti esterni caricati da certi siti anche per mezzo di javascript è pazzesca: gallerie, webfonts, librerie di effetti in javascript stesso e servizi vari. Certe cose sono una comodità per gli sviluppatori, che con scatolette chiuse realizzano siti che altrimenti richiederebbero dieci volte in piu di tempo. Con il rischio che poi se non è piu raggiungibile il contenuto remoto il sito diventa inutlizzabile: tipico caso quando librerie esterne divengono obsolete e chi le fornisce le rimuove e lascia solo le ultime versioni, in quel caso o metti mano al sito per aggiornare alle nuove o il sito si vede a metà o mal formattato. Con uno scenario del genere non occorre avere tanta fantasia per immaginare che è possibile attaccare il repository dei contenuti esterni, (es. js) riesco a iniettare sporcizia creata ad hoc in nmila siti che usano quei contenuti.

si, tutte minchiate. i webfont poi in genere sono solo fastidiosi e faccio di tutto x disabilitarne l'uso, preferisco il vecchio arial.
interessante e preoccupante lo scenario dell'iniezione massiva remota di malware... attaccarne uno per colpirne tanti... una struttura fragilissima e prona a millemila punti di debolezza...