Torna indietro   Hardware Upgrade Forum > Networking e sicurezza > Antivirus e Sicurezza > Tutorial / How-To / F.A.Q.

Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
A distanza di circa 8 mesi arriva l’importante aggiornamento dei MacBook Air: nessun cambiamento estetico, ma una revisione hardware interna con l’upgrade al processore M3. Le prestazioni migliorano rispetto alle generazioni precedenti, e questo fa sorgere una domanda spontanea: a chi è rivolto oggi questo laptop? Cerchiamo di capirlo nella nostra recensione 
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
Da ASUS un monitor particolare ma molto completo: principalmente indirizzato al videogiocatore, può essere sfruttato con efficacia anche per attività creative e di produzione multimediale
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Il nuovo robot aspirapolvere domestico di Dreame abbina funzionalità complete a un moccio flottante che raggiunge al meglio gli angoli delle pareti. Un prodotto tutto in uno semplice da utilizzare ma molto efficace, in grado di rispondere al meglio alle necessità di pulizia della casa
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 18-07-2009, 01:24   #1
Sisupoika
Registered User
 
Iscritto dal: Nov 2006
Città: Espoo, Finland
Messaggi: 1631
Varianti XSRF (Cross Site Request Forgery) e furto di dati JSON

Come si sara' capito da precedenti posts, ogni tanto mi capita di cazzeggiare nelle ultime ore in ufficio del venerdi', da cui nasce questo post (che in realta' ho soltanto cominciato a scrivere in ufficio ma che ho dovuto completare a casa a causa di un impegno all'ultimo momento che mi ha intrattenuto ore!).

Ho notato, attraverso discussioni precedenti, che alcuni argomenti destano particolare interesse in questa sezione, soprattutto in relazione alla sicurezza delle applicazioni web. Di tanto in tanto, dunque, tempo permettendo, mi capita di postare delle piccole note o "pillole" per descrivere alcune tecniche, problemi, e cosi' via di cui si sente molto spesso parlare in news, articoli, discussioni, ma che spesso rimangono qualcosa di "nebuloso" e criptico per la maggior parte dei lettori.

Anche l'"appunto" di oggi riguarda alcuni rischi inerenti a JavaScript, nelle sue piu' moderne implementazioni ed usi.

Premessa: sto lavorando ad un nuovo framework (che ho chiamato "Application Factory" e che sara' ad uso interno degli sviluppatori delle nostre sedi in UK e gli altri paesi) che si basa dietro le quinte su tecnologie esistenti, ma che si pone l'obiettivo di raccogliere un certo numero di best practices riguardanti, in particolare: prestazioni, interattivita', usabilita', e sicurezza. In pratica, attraverso questo framework (che soltanto per la parte dati si basa su .NET/MSSQL, dal momento che grossa parte della nostra roba e' su piattaforma Microsoft, e che per molti versi e' ispirato a Ruby on Rails e
Django), i nostri sviluppatori saranno in grado di "sfornare" molto rapidamente delle applicazioni amministrative di vario tipo (lavoro nel settore del marketing/advertising online, per chi non lo sapesse) che saranno belle da vedere, facili e interessanti da usare, estremamente veloci, e molto piu' sicure della media; cio' potra' essere fatto in tempi rapidi, ma con totale controllo su quanto accade.

Per ottenere i risultati cercati per i primi punti (tralasciando, cioe', la sicurezza per un attimo), ho progettato la cosa in modo da sposare una parte a volte significativa della logica sul client. Parlo naturalmente, di quella logica che non ha niente a che vedere (nella stra grande maggioranza dei casi) con dai sensibili, o con sistemi di autenticazione e autorizzazione; quella parte di logica che e' puramente necessaria sul client per la presentazione e per l'interazione dell'utente con l'applicazione stessa.
Tutto cio', se fatto opportunamente, puo' contribuire a migliorare sensibilmente la responsivita' delle applicazioni web.

Tornando in topic, e' chiaro che gestire una parte di logica sul client significa dover affrontare, e possibilmente prevedere, dei problemi di sicurezza che possono essere a volte anche molto diversi e piu' complicati da quelli di piu' "tradizionali" applicazioni web (con il serve che fa tutto e manda del semplice HTML ecc al client), comprendendo naturalmente anche essi.

In questi giorni sto lavorando all'implementazione, nel core della parte client di Application Factory, di un numero di tecniche di prevenzione e controllo per molti threats odierni.

Sperando di non avervi gia' assonnato con la premessa ( ): spesso si e' parlato di varie tecniche che sfruttano JavaScript per compiere azioni "legittime" se si pensa al funzionamento dei vari meccanismi che sono alla base di Internet (protocolli, browsers, etc), ma che in realta' possono compremettere dati, privacy, ecc anche in modo molto serio.

Si e' visto che molti dei rischi e threats odierni riguardano tecniche classificabili, molto generalmente parlando, come Cross Site Scripting (XSS) and poi in altre categorie come Cross Site Request Forgery (XSRF), Cross Site Tracing (XST), e cosi' via. Ma un aspetto che spesso passa inosservato e' che in queste "sotto categorie" spesso ci sono talmente tante varianti, possibilita', e tecniche diverse, da avere in comune soltanto parte dello scopo.
Per questo motivo spesso soluzioni ad alcune varianti piu' comuni o generiche (che sono talvolta confuse col problema sui cui esse semplicemente si basano) possono essere piu' o meno inutili contro altre varianti che pur diverse vanno classificate per un motivo o per l'altro nella stessa categoria.

Un caso particolare con una enorme varieta' di tecniche anche molto diverse e' quello del Cross Site Request Forgery. Abbiamo visto qualche esempio in altre occasioni, e oggi voglio parlare un po' di un metodo IMHO molto carino ed interessante e su cui stavo lavorando oggi per AF.

Si tratta di un esempio che si basa su qualcosa di comune ad altre XSRF tecniche, ma che sfrutta allo stesso tempo una particolare buca di JavaScript, ancora presente nella maggioranza dei browsers e che la maggioranza degli sviluppatori ignora (come al solito).

Parliamo dunque di una particolare XSRF che ha lo scopo di operare il furto ("hijacking") di dati JSON altrimenti non ottenibili.

Per capire di che si tratta, supponiamo di avere:
- un sito vittima, che chiameremo "sito-vittima.com" (che fantasia, eh...)
- un sito maligno, che chiameremo "sito-maligno.com" (uhm...)
- un utente indifeso

Supponiamo, allo stesso tempo, che
- il sito vittima sia stato realizzato coi piedi, cioe' come per la maggior parte dei siti (ndr )
- che il sito vittima fornisca dati sensibili al client, anche attraverso JavaScript
- e che in particolare, affinche' cio' funzioni:
a) passi questi dati serializzati in formato JSON
b) non usi (come la maggior parte dei siti) i cookies in modalita' http only, in modo da poter effettuare solite richieste di prelievo dati anche con JavaScript(se ne e' parlato qui, ricordate?)

In pratica, quando l'utente indifeso e' loggato al sito vittima e visita una pagina che visualizzi tali dati (ripeto l'invito a pensare a dati "sensibili" per capire, in seguito, come questa roba puo' essere seria), accade cio:

1) del codice JavaScript presente in quella pagina (ricordate: stiamo parlando di una applicazione che fornisca dati in formato JSON attraverso codice client / tecniche AJAX) effettuera' una richiesta normalmente di tipo GET per prelevare quei dati, che vengono ritornati in formato JSON, serializzati
2) tale richiesta, a causa delle condizioni di cui sopra, portera' con se' il cookie che conserva le informazioni di autenticazione che saranno necessarie all'applicazione per verificare se l'utente e' loggato, prima di rispondergli con i dati richiesti
3) una volta che la richiesta e' stata completata, un metodo di callback verra' automaticamente eseguito e ad esso verranno passati, quale parametro, i dati richiesti dall'utente.
4) tale funzione di callback poi, avendo quei dati finalmente a disposizione come parametro, potra' visualizzarli, elaborarli o quello che e'.

Per capire meglio come tutto cio' funziona, leggete qui e qui a proposito di "JSONP".

In breve: si tratta semplicemente di un metodo per scambiare dati tra client e server anche attraverso tecniche AJAX basate su JavaScript.
In realta', JSONP e' sfruttato anche e soprattutto per lo scambio di dati tra siti di diverso dominio, cioe' in quel famoso contesto di Cross Domain / Cross Site nel quale altrimenti lo scambio di dati non sarebbe possibile. JSONP aiuta in molti casi ad aggirare brillantemente questo ostacolo. Per i dettagli leggete i links di cui sopra; cmq, in breve, funziona cosi':
quando un sito dominio1.com vuole richiedere dati ad un sito dominio2.com, accade cio':

1) un tag SCRIPT e' dinamicamente aggiunto alla pagina su dominio1.com, attraverso JavaScript, del tipo:

Codice:
<script type='text/javascript' src='//dominio2.com/data_page_location?optional_parameters'></script>
Questo perche' e' consentito eseguire in una pagina del codice JavaScript proveniente da altro dominio.

2) Cio' causera' una richiesta di tipo GET verso dominio2.com per lo URL //dominio2.com/data_page_location?optional_parameters.

3) Poiche' si tratta di JavaScript, a causa di come i browsers scaricano e interpretano JavaScript (leggere qui), altri (eventuali) richieste verranno posticipate sino al completamento di questa richiesta, cioe' sino a quando quel codice JavaScript richiesto sara' disponibile.
Ma altre richieste/downloads a parte, si tratta di una richiesta asincrona, cioe' il browser esegue il codice JavaScript successivo a quello che ha aggiunto lo SCRIPT tag di cui al punto 1, causando quella richiesta iniziale dei dati in formato JSON.

4) Poiche' la richiesta e' asincrona, e' necessario che la pagina richiedente in dominio1.com, abbia a disposizione una funzione JavaScript (appunto il metodo di "callback" di cui parlavo prima) separata, che visualizzi oppure operi sui dati richiesti una volta che questi sono stati ricevuti.

5) Perche' JSONP funzioni, e' necessario che la pagina su dominio2.com che deve restituire i dati richiesti, sappia qual'e il nome della funzione di callback da richiamare. Cio' e' di solito possibile in due modi:

- i due siti comunicanti stabiliscono a priori il nome della funzione da usare come callback (in tal caso i due siti "devono conoscersi")
- oppure il sito richiedente dominio1.com passa a dominio2.com il nome della funzione come parametro attraverso la query string (nell'esempio sopra: //dominio2.com/data_page_location?optional_parameters&callbackMethod=nome_della_funzione)

6) Supponendo che il nome della funzione sia "ShowResults" nel nostro esempio, la pagina su dominio2.com che fornisce i dati restituira' un responso (con content type "text/javascript") di questo tipo:

Codice:
ShowResults(i dati verranno passati qui come parametro);
7) La funzione "ShowResults" verra' automaticamente eseguita non appena quel JavaScript sara' stato ricevuto dal client, e avra' i dati richiesti a disposizione poiche' essi, come abbiamo visto, sono stati passati come parametro.


Chiudo questa lunga parentesi su JSON/JSONP per tornare a descrivere la tecnica di attacco di tipo XSRF che e' topic di questo post (era pero' indispensabile far capire come JSON/JSONP rientrano in questo contesto, onde evitare confusione).

Supponiamo ora che

- sitovittima.com verifichi il cookie di autenticazione (che, come abbiamo visto, viene trasferito avanti e indientro tra client e server quando la richiesta JSONP viene eseguita), per accertarsi che l'utente richiedente i dati sia loggato, prima di fornire i dati richiesti.

- vi sia un sito, sitomaligno.com, che in una pagina (di nascosto), effettui una richiesta JSONP verso sitovittima.com, per un particolare URL (supponiamo, for argument's sake, //sitovittima.com/transazioni_bancarie)

Se l'utente indifeso che visita sitomaligno.com e', in quel momento, loggato su sitovittima.com, cosa accade?
Accade che, di nascosto, il cookie di autenticazione verra' inviato a sitovittima.com che, a sua volta, accettera' l'utente come gia' loggato e percio' restituira' i dati richiesti, che verranno in realta' raccolti da sitomaligno.com: la pagina sul sito maligno avra' una funzione con lo stesso nome usato per la funzione di callback, e potra' catturare dunque i dati appartenenti a quell'utente ed inviarli in svariati modi all'attaccante.

Interessante, fin qui? Non e' finita.

Come ci si protegge da cio'?

Innanzitutto, usando quanto meno possibile JSONP, e usando http only cookies e' possibile ridurre i rischi legati a questo problema.

Tempo fa, poi, si incomincio' ad usare dati JSON in modo leggermente diverso e (si pensava! ) piu' sicuro - che descrivero' tra un minuto - a patto che i dati JSON vengano resi disponibili soltanto al dominio che li genera, cioe' in contesto di same origin policy.

Naturalmente, come avrete capito, questo rovina la possibilita' di scambio dati JSON tra siti diversi, ma - se non avete afferrato questa parte, il problema e' che molti sviluppatori, prima (e in realta' ancora oggi) abusano di JSONP anche per operazioni all'interno del singolo dominio, ignorando i rischi possibili a causa delle proprieta' di JSONP in casi di cross site.

Una "parziale" (vedremo subito il perche') protezione da problemi dovuti a JSONP, e' quella di abolire i metodi di callback.
Invece di JSONP e del trucchetto col SCRIPT tag su cui si basa (che ha il vantaggio di essere molto piu' semplice e cross browser compatibile con pochissimo sforzo!), affinche' si rimane all'interno dello stesso dominio (cioe' il sito che fornisce i dati, intende fornire tali dati soltanto a pagine appartenenti a se stesso), e' possibile fare un passo indietro ed utilizzare XML HTTP per caricare i dati JSON (nota: come visto in altre occasioni questo implica altri problemi, a causa del possibile furto di cookies di autenticazione - a meno di usare un secure cookie protocol).
In questo caso non esiste nessuna funzione di callback, e i dati JSON sono passati direttamente nel response text creato da sitovittima.com invece di essere passati come parametro al callback. Il responso conterra', cioe', invece di:

Codice:
ShowResults(qui i risultati);
questo:

risultati qui, direttamente nel testo del responso


Se vi state chiedendo perche' questo cambiamento protegge dal problema JSONP di cui sopra (o almeno si credeva ), la risposa e' semplice:

Se il famoso sitomaligno.com prova il trucchetto adesso, in teoria il browser di utente indifeso ritornera' errori di sintassi ecc. a causa del JavaScript caricato di nascosto da sitovittima.com a sua insaputa.
L'utente al massimo notera' un errore (con IE piu' probabilmente, o con Firefox+console/firebug etc.) e potra' proseguire come al solito, mentre l'attacco sara' completamente fallito.

Facciamo un esempio con dati fittizi per capirne il perche'.
Supponiamo che i dati forniti siano nel formato JSON siano:

Quote:
{ username: "Sisupoika", location: "London", ecc. ecc }
(nell'ipotesi che i dati siano quelli del profilo dell'"utente indifeso" o qualcosa di simile - giusto come esempio).

Se il codice fosse

Quote:
var returnedData = { username: "Sisupoika", location: "London", ecc. ecc }
la sintassi sarebbe corretta e il codice verrebbe eseguito senza che il browser si lamenti. Notare che pero' in questo caso quei dati sarebbero accessibili attraverso la variabile "returnedData" una volta ottenuti attraverso JSONP.

Ma poiche' nell'esempio, per le ragioni spiegate sopra non stiamo assegnando quell'oggetto coi dati ad una variabile, la sintassi del testo ottenuto come responso della richiesta JSONP causera' un errore nel browser, e l'attacco sara' fallito.

Avvicinandoci alla conclusione, la domanda e': funziona come protezione da questo particolare tipo di vulnerabilita' a causa di JSONP?

La risposta, contrariamente a quanto si credeva sino a poche settimane fa, e': DIPENDE.

Nell'esempio sopra, i dati JSON sono ritornati nella sintassi tipica di un oggetto JavaScript, che causa l'errore e fa fallire l'attacco.

Ma esiste un particolare tipo di dati, in JavaScript, che NON causa errori nel browser se eseguito anche senza che quei dati vengano assegnati ad una variabile o passati come argomento di una funzione o come valore di una proprieta' di un oggetto: ARRAYS.

Supponiamo che i dati ritornati siano nel formato (anch'esso valido JSON):

Quote:
[ { name: "Bill", surname: "Gates" }, { name: "Steve", surname: "Jobs" } ]
In questo caso abbiamo un array di oggetti.
Se adesso ripetiamo il tentativo di prima, cioe' usiamo JSONP per caricare dati JSON in realta' non destinati all'uso con JSONP, otterremmo un primo "positivo" effetto (dal punto di vista di un attaccante): come anticipato,il browser non lamentera' errori si sintassi, ed eseguira' allegramente quel codice JavaScript.

A questo punto i piu' attenti si chiederanno: ma se non assegnamo quei dati ad una variabile o proprieta' di un oggetto, ne' li passiamo come argomento di una funzione, come potremmo catturarli, o meglio: come potrebbe un attaccante rubarli se quel codice viene semplicemente eseguito senza "conservare i dati" da qualche parte che sia accessibile ad altro codice?

Veniamo dunque a quanto rende un attacco basato su JSONP possibile anche con dati in formato JSON ma non designati all'uso con JSONP.

Si tratta di una particolare proprieta della programmazione ad oggetti con javascript: gli arrays sono - "dietro le quinte" - trattati dall'interprete come un particolare tipo di oggetti, quindi funzionano in maniera un po' di diversa da altri linguaggi. L'unica differenza e' nel costruttore dell'oggetto, che e' leggermente diverso. Non sto a parlare di costruttori ecc. perche' ci discosteremmo troppo dall'argomento.

E' possibile ridefinire ("override") la struttura di un oggetto prima che esso venga inizializzato, agendo sul prototype.
Ad esempio, se volessimo aggiungere un custom method a tutte le stringhe che consenta di ottenere il contenuto della stringa tutto in maiuscolo, potremmo usare del codice di questo tipo:

Codice:
String.prototype.tuttoMaiuscolo = function () { return this.toUpperCase(); }
Una volta eseguito questo codice, quel metodo sara' disponibile per qualunque stringa.

Tornando a noi, c'e' una interessante chicca a proposito di prototype che e' possibile usare per sfruttare (= rubare) i dati JSON il cui codice, come spiegato prima, viene eseguito senza errori dal browser nelle condizioni esposte poco fa.

Poiche' vogliamo sfruttare un array, e poiche', come si e' visto, gli arrays dietro le quinte sono oggetti, possiamo ridefinire il metodo __defineSetter__ agendo sul prototype di Object:

Codice:
Object.prototype.__defineSetter__('name', function(data) {
// abbiamo catturato i dati! facciamo che ci pare!
});
In pratica, abbiamo fatto si' che ogni volta la proprieta' di nome "name" viene settata in un oggetto, ne catturiamo il valore, e possiamo recuperarlo in una marea di modi!
Naturalmente, e' possibile catturare tutte le proprieta' degli oggetti i cui dati si vogliono rubare.

Un punto interessante e' che questa tecnica e' ancora validissima oggi con molti browsers.
Una eccezione certa e' Internet Explorer 8, che a quanto pare non supporta affatto il metodo defineSetter
Sinceramente non ho trovato informazioni per capire se cio' e' di proposito per motivi - appunto - di sicurezza, o se e' un nuovo esempio di come Microsoft interpreta le specifiche a modo suo per poi dare un browser che funziona come gli pare....
Con le versioni precedenti, ma anche con Firefox, Chrome, Safari, Konqueror, e forse Opera, questa tecnica e' ancora oggi possibile.

Fortunatamente c'e' la possibilita' di renderla molto piu' difficile, e il buon esempio questa volta viene da Microsoft, che l'ha implementata in ASP.NET 3.5:

1) Bisogna far si' che qualunque serializzatore di dati in formato JSON non ritorni mai arrays direttamente, ma soltanto oggetti, in modo da far fallire un attacco di quel tipo e causare errori nel browser in caso di tentativi.
ASP.NET 3.5 fa questo incapsulando il risultato della serializzazione (anche arrays) all'interno di un oggetto contenitore chiamato "d" (che forse sta per "data").
In questo modo, non otterremo mai arrays direttamente eseguibili e manipolabili nel modo descritto.
Per gli sviluppatori .NET in ascolto che forse si saranno chiesti, in precedenza, cosa fosse quel "d", adesso lo sapete

2) Bisogna far si' che le richieste di dati JSON vengano accettate soltanto se effettuate col verbo POST anziche' GET.
Da un lato, questo va contro le regole di buon uso dell'HTTP che, come gia' detto in altra occasione, dicono:
a) usare GET per leggere dati
b) usare POST per modificare dati
e che sono le regole alla base delle moderne applicazioni web di tipo RESTful.
D'altra parte, cosi' facendo, le richieste effettuate con JSONP attraverso l'aggiunta dinamica di SCRIPT tags, verrebbero rifiutate in quanto esse sono sempre di tipo GET.

3) In aggiunga, ASP.NET obbliga l'uso di uno specifico content type, text/json.

Usando questo o simili tecniche, quell'attacco diventa pressocche' impossibile o estremamente difficile.
Ma cio' non toglie che
- il 99.99% degli sviluppatori e' all'oscuro di tutto cio'
- JSONP troppo spesso abusato e, senza particolari precauzioni, anche in quei casi nei quali JSONP non dovrebbe essere consentito, e cioe' quando non e' previsto che dati JSON debbano essere disponibili anche ad altri siti con differenti domini.
- la maggior parte dei browser attuali e' ancora vulnerabile a questa tecnica

direi che forse e' tutto sommato un'altra possibilita' da non sottovalutare.



Spero che, nonostante la lunghezza, troviate questo post interessante, informativo, o quantomeno utile.

Ciaps,
S

Ultima modifica di Sisupoika : 18-07-2009 alle 18:01.
Sisupoika è offline   Rispondi citando il messaggio o parte di esso
Old 18-07-2009, 01:25   #2
Sisupoika
Registered User
 
Iscritto dal: Nov 2006
Città: Espoo, Finland
Messaggi: 1631
(sto completando la parte finale - ho inviato per sbaglio )


edit: completato.

Ultima modifica di Sisupoika : 18-07-2009 alle 01:54.
Sisupoika è offline   Rispondi citando il messaggio o parte di esso
Old 18-07-2009, 21:32   #3
Sisupoika
Registered User
 
Iscritto dal: Nov 2006
Città: Espoo, Finland
Messaggi: 1631
C'e' una parte molto importante che ho saltato mentre scrivevo, cmq noto che non c'e' molto "traffico" da queste parti al momento
quindi l'aggiungo appena ho qualche minuto in piu'
Sisupoika è offline   Rispondi citando il messaggio o parte di esso
Old 19-07-2009, 08:04   #4
sampei.nihira
Senior Member
 
Iscritto dal: Aug 2006
Messaggi: 4350
Resto sintonizzato Sisu.

Io nonostante sia proverbiale la pazienza dei pescatori con l'età inizio ad averne di meno e tu fai post "eccessivamente lunghi" specie come nel mio caso se lo leggi la domenica mattina (a quest'ora) quando devi anche andare al mare
sampei.nihira è offline   Rispondi citando il messaggio o parte di esso
Old 19-07-2009, 17:52   #5
riazzituoi
Bannato
 
Iscritto dal: Aug 2007
Messaggi: 3847
.

Ultima modifica di riazzituoi : 30-04-2010 alle 14:20.
riazzituoi è offline   Rispondi citando il messaggio o parte di esso
Old 03-08-2009, 21:37   #6
medus@
Member
 
L'Avatar di medus@
 
Iscritto dal: Jun 2008
Messaggi: 79
grazie delle info sisu...iscritta
medus@ è offline   Rispondi citando il messaggio o parte di esso
Old 05-08-2009, 15:56   #7
xcdegasp
Moderatore
 
L'Avatar di xcdegasp
 
Iscritto dal: Nov 2001
Città: Fidenza(pr) da Trento
Messaggi: 27465
spostato in tutorial/faq
xcdegasp è offline   Rispondi citando il messaggio o parte di esso
Old 05-08-2009, 15:58   #8
Sisupoika
Registered User
 
Iscritto dal: Nov 2006
Città: Espoo, Finland
Messaggi: 1631
Quote:
Originariamente inviato da xcdegasp Guarda i messaggi
spostato in tutorial/faq
Sounds good. Cheers
Sisupoika è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Apple MacBook Air M3: chi deve davvero comprarlo? La recensione Apple MacBook Air M3: chi deve davvero comprarlo...
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ul...
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza Dreame L10s Pro Ultra Heat: la pulizia di casa t...
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere HONOR Magic6 Pro: come funziona Magic Portal, il...
L'innovazione richiede fiducia: Workday si propone come guida nell'era dell'IA L'innovazione richiede fiducia: Workday si propo...
RocketStar FireStar Drive: un propulsore...
Roscosmos: il lancio del razzo spaziale ...
Italia strategica per Oracle. Arriva la ...
Sam-Bankman Fried: 25 anni di reclusione...
Mobility Analytics di WINDTRE Business p...
Il lander lunare JAXA SLIM si è r...
Warframe conquista l'iPhone: senza soluz...
Marvel Rivals!, l'inaspettato shooter Pv...
Twitch aggiorna le linee guida sui conte...
Galaxy M55 ufficiale: la nuova fascia me...
Google corregge sette vulnerabilit&agrav...
IA: le imprese italiane sono in prima li...
Garmin Dash Cam 57: un'alleata perfetta ...
Elgato Facecam MK2: come rendere ancora ...
2 iRobot Roomba al prezzo più sco...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 00:33.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Served by www3v