Spcnet.it

2026-05-02 14:41:55

Deserializzazione JSON sicura in .NET 10: guida completa a JsonSerializerOptions.Strict

Considera questo payload JSON in arrivo alla tua API:

{"Amount": 100, "Amount": -999}

Due proprietà con lo stesso nome. La sezione 4 di RFC 8259 dice che i nomi degli oggetti dovrebbero essere univoci, ma non lo impone. System.Text.Json, di default, adotta l’approccio permissivo: vince l’ultima scrittura, nessun avviso, nessun errore. Il valore dell’attaccante passa silenziosamente.

Questo non è solo un problema di proprietà duplicate. La deserializzazione di default ignora anche campi extra che un attaccante potrebbe iniettare, lascia scivolare i valori null nelle proprietà non-nullable e salta dati richiesti mancanti. Ogni di queste “comodità” è una potenziale vulnerabilità al confine della tua API.

JsonSerializerOptions.Strict: cinque protezioni in un solo preset

.NET 10 introduce JsonSerializerOptions.Strict, un nuovo preset di sola lettura che si affianca a Default e Web. Mentre Default dà priorità alla retrocompatibilità e Web ottimizza per le API HTTP tipiche, Strict segue le best practice di sicurezza attivando cinque impostazioni protettive simultaneamente.

var strict = JsonSerializerOptions.Strict;
// AllowDuplicateProperties:             False
// UnmappedMemberHandling:               Disallow
// PropertyNameCaseInsensitive:           False
// RespectNullableAnnotations:            True
// RespectRequiredConstructorParameters:  True

Confronto tra i tre preset

Impostazione	Default	Web	Strict
AllowDuplicateProperties	true	true	false
UnmappedMemberHandling	Skip	Skip	Disallow
PropertyNameCaseInsensitive	false	true	false
RespectNullableAnnotations	false	false	true
RespectRequiredConstructorParameters	false	false	true

I dati serializzati con Default possono essere deserializzati con Strict. La compatibilità va in una sola direzione: Strict è più severo su ciò che accetta, non su ciò che produce.

1. Proprietà duplicate vietate

I protocolli che stratificano il parsing JSON (OAuth 2.0, OpenID Connect, firme webhook) possono essere sfruttati se parser diversi gestiscono input duplicati in modo diverso. Con Strict, ogni tentativo di deserializzare JSON con proprietà duplicate genera immediatamente una JsonException:

string duplicateJson = @'{"Amount": 100, "Amount": -999}';

try
{
    JsonSerializer.Deserialize<Payment>(duplicateJson, JsonSerializerOptions.Strict);
}
catch (JsonException ex)
{
    // JsonException: Duplicate property 'Amount' encountered during deserialization
    Console.WriteLine(ex.Message);
}

public record Payment(int Amount);

Questa protezione si estende oltre i POCO (plain-old C# objects): funziona anche con JsonDocument, JsonNode e Dictionary<string, T>.

2. Rifiuto dei membri non mappati

La deserializzazione di default scarta silenziosamente le proprietà JSON che non corrispondono al tuo tipo .NET. È comodo durante lo sviluppo, ma è pericoloso a un confine di fiducia perché non sai cosa sta inviando il client.

string extraFieldJson = @'{"Name": "Alice", "Role": "user", "IsRoot": true}';

// Default: ignora silenziosamente "IsRoot"
var user = JsonSerializer.Deserialize<User>(extraFieldJson);
// Name=Alice, Role=user - "IsRoot" scompare senza tracce

// Strict: rifiuta la proprieta' non mappata
JsonSerializer.Deserialize<User>(extraFieldJson, JsonSerializerOptions.Strict);
// throws: The JSON property 'IsRoot' could not be mapped to any .NET member

public record User(string Name, string Role);

3. Corrispondenza case-sensitive dei nomi di proprietà

In modalità Strict, la case sensitivity diventa un contratto preciso: i nomi delle proprietà JSON devono corrispondere esattamente ai nomi delle proprietà C#. Se i tuoi client inviano camelCase ma i tuoi tipi usano PascalCase, aggiungi [JsonPropertyName("nomeCamelCase")] per rendere il contratto esplicito nella definizione del tipo.

4. Enforcement delle annotazioni nullable

I nullable reference types di C# aiutano a intercettare i problemi di null a compile time, ma System.Text.Json li ignora di default durante la deserializzazione. Con Strict, se hai dichiarato string Name (non string? Name), il serializzatore rifiuterà qualsiasi JSON con null per quella proprietà:

string nullNameJson = @'{"Name": null, "Email": "alice@example.com"}';

// Default: null va nella stringa non-nullable senza errori
var contact = JsonSerializer.Deserialize<Contact>(nullNameJson);
// contact.Name == null (silenzioso!)

// Strict: genera eccezione
JsonSerializer.Deserialize<Contact>(nullNameJson, JsonSerializerOptions.Strict);
// throws: The constructor parameter 'Name' doesn't allow null values

public record Contact(string Name, string Email);

5. Parametri obbligatori del costruttore

I record type e le classi con costruttori parametrizzati possono avere parametri obbligatori silenziosamente riempiti con valori di default quando il JSON manca dei dati. Strict lo impedisce:

string missingParamJson = @'{"FirstName": "Alice"}';

// Default: LastName mancante diventa silenziosamente null
var person = JsonSerializer.Deserialize<Person>(missingParamJson);
// person.LastName == null

// Strict: richiede tutti i parametri
JsonSerializer.Deserialize<Person>(missingParamJson, JsonSerializerOptions.Strict);
// throws: JSON deserialization was missing required properties: 'LastName'

public record Person(string FirstName, string LastName);

Integrazione in ASP.NET Core Minimal APIs

Nei demo sopra usiamo JsonSerializer direttamente. In un’applicazione web, configuri le opzioni JSON una volta e ogni endpoint le eredita. Nota: JsonSerializerOptions.Strict è un singleton frozen, quindi non puoi passarlo direttamente a ConfigureHttpJsonOptions che richiede un’istanza mutabile. Imposta le singole proprietà:

builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.AllowDuplicateProperties = false;
    options.SerializerOptions.UnmappedMemberHandling =
        System.Text.Json.Serialization.JsonUnmappedMemberHandling.Disallow;
    options.SerializerOptions.PropertyNameCaseInsensitive = false;
    options.SerializerOptions.RespectNullableAnnotations = true;
    options.SerializerOptions.RespectRequiredConstructorParameters = true;
});

app.MapPost("/payments", (Payment payment) =>
{
    // Se il body ha proprieta' duplicate, campi non mappati o dati mancanti,
    // il framework risponde con 400 Bad Request prima che questo codice venga eseguito.
    return Results.Ok(payment);
});

Il framework intercetta JsonException durante il model binding e restituisce un 400 Bad Request con problem details. Il tuo endpoint vede solo oggetti validi e completamente inizializzati.

Configurazione per-endpoint

Se hai bisogno di validazione strict su alcuni endpoint ma parsing più flessibile su altri, puoi deserializzare manualmente dal body della richiesta con le opzioni desiderate:

app.MapPost("/api/strict", async (HttpContext context) =>
{
    var payment = await context.Request.ReadFromJsonAsync<Payment>(
        JsonSerializerOptions.Strict);
    return Results.Ok(payment);
});

Supporto per i Source Generator

Per scenari AOT o per i benefici prestazionali dei source generator, configura manualmente le impostazioni equivalenti su JsonSourceGenerationOptionsAttribute. Non esiste una scorciatoia Strict per l’attributo: ogni proprietà va impostata individualmente.

[JsonSourceGenerationOptions(
    AllowDuplicateProperties = false,
    UnmappedMemberHandling = JsonUnmappedMemberHandling.Disallow,
    PropertyNameCaseInsensitive = false,
    RespectNullableAnnotations = true,
    RespectRequiredConstructorParameters = true
)]
[JsonSerializable(typeof(Payment))]
internal partial class StrictJsonContext : JsonSerializerContext;

Il codice generato include tutta la logica di validazione a compile time, senza overhead di reflection.

Quando usare Strict (e quando no)

Usalo ai confini di fiducia: endpoint token, ricevitori di webhook, controller API che accettano JSON da client non controllati completamente. Il costo è una JsonException quando i payload non corrispondono al contratto. Questo è esattamente lo scopo.

Evitalo per l’ingestione flessibile: se consumi JSON da API di terze parti con schemi inconsistenti, la modalità strict rifiuterà payload che potresti voler gestire con più grazia. In questi casi usa Default o Web e valida dopo la deserializzazione.

Migra in modo incrementale: non è necessario passare tutto a Strict subito. Inizia dagli endpoint ad alto rischio, intercetta JsonException, registra i problemi, correggi i client che inviano payload non conformi, poi espandi.

Sappi i limiti: Strict valida le violazioni del contratto strutturale ma non protegge da JSON profondamente annidato (usa MaxDepth), payload eccessivi (imposta limiti HTTP) o type confusion polimorfico. È un layer di difesa, non l’unico.

Conclusione

Ogni endpoint API che accetta JSON è un confine di fiducia. La deserializzazione permissiva rende quel confine poroso. JsonSerializerOptions.Strict non aggiunge nuova logica: attiva protezioni già presenti in System.Text.Json ma disattivate di default per retrocompatibilità. Una riga di configurazione le attiva tutte.

Questo è particolarmente rilevante ai confini di protocollo come OAuth 2.0 e OpenID Connect, dove una proprietà duplicata o un campo inatteso non è solo un bug — è un potenziale vettore di exploit.

Fonte: Harden Your .NET JSON Deserialization with System.Text.Json and JsonSerializerOptions.Strict — Khalid Abuhakmeh, Duende Software (30 aprile 2026)

Harden Your .NET JSON Deserialization with System.Text.Json and JsonSerializerOptions.Strict

Learn how .NET 10's new JsonSerializerOptions.Strict preset activates five security protections in System.Text.Json to close gaps at your API trust boundaries.

^{Khalid Abuhakmeh (Duende Software)}

(in)sicurezza digitale

2026-05-01 08:07:57

18 estensioni browser AI come RAT e Spyware: Unit 42 smonta la facciata dei tool GenAI per la produttività

Con la diffusione esplosiva degli strumenti di intelligenza artificiale generativa, il Chrome Web Store è diventato il nuovo vettore privilegiato per la distribuzione di malware camuffato da produttività. Il team Unit 42 di Palo Alto Networks ha pubblicato il 30 aprile 2026 una ricerca sistematica che documenta 18 estensioni browser ad alto rischio — commercializzate come assistenti AI per email, coding e ricerca — che nascondono Remote Access Trojan (RAT), attacchi meddler-in-the-middle (MitM), infostealer e spyware a tutti gli effetti. Google ha rimosso o emesso avvisi sulle estensioni segnalate, ma la ricerca espone un problema strutturale: il modello di permessi delle estensioni browser, combinato con la fiducia degli utenti verso i tool AI, crea una superficie di attacco lato client difficile da presidiare.

Perché le estensioni AI sono un bersaglio ideale

Le estensioni browser operano all’interno del processo trusted del browser con permessi concessi dall’utente. Possono leggere e modificare contenuti web, intercettare richieste di rete, accedere ai cookie e comunicare con server esterni — le stesse capacità di strumenti legittimi come ad blocker, password manager e tool per sviluppatori. La distinzione tra uno strumento legittimo e uno malevolo è invisibile all’utente medio.

L’AI generativa amplifica il rischio in modo qualitativo. Quando un utente digita un prompt in un servizio AI come ChatGPT o Claude, condivide routinariamente codice proprietario, bozze di comunicazioni riservate e piani strategici. Un’estensione posizionata tra l’utente e il servizio AI intercetta dati di valore incomparabilmente superiore ai metadati di navigazione tradizionalmente presi di mira dal browser malware. Unit 42 ha rilevato campioni specifici che prendono di mira i prompt inviati a ChatGPT prima che lascino il dispositivo, esfiltrandoli verso domini a bassa reputazione.

Le tecniche di attacco documentate da Unit 42

L’analisi retrospettiva di Unit 42 ha identificato cinque tecniche ricorrenti nelle 18 estensioni ad alto rischio:

1. WebSocket C2 persistente

Le estensioni stabiliscono connessioni WebSocket bidirezionali verso server C2 remoti. La connessione si riconnette automaticamente agli interrupt di rete e persiste attraverso i riavvii del browser senza richiedere iniezione di processo. Il traffico appare come normale traffico HTTPS dal punto di vista della rete. L’esempio più esplicito è “Chrome MCP Server – AI Browser Control”: mascherato da tool di automazione basato su Model Context Protocol, è di fatto un RAT completo che si connette a wss://mcp-browser.qubecare[.]ai/chrome, con la listing che riportava falsamente “100% local processing – your data never leaves your browser”.

2. Browser API Hooking

Gli script di contenuto sostituiscono le API native del browser (window.fetch o XMLHttpRequest) per intercettare le richieste di rete prima della trasmissione. In questo modo l’estensione può leggere il payload di qualsiasi richiesta — incluse quelle cifrate — prima che lascino la pagina. Questa tecnica permette la cattura di prompt, credenziali di form e token di sessione.

3. Osservazione passiva del DOM

Gli script di contenuto monitorano passivamente le modifiche al Document Object Model (DOM) in applicazioni target come Gmail o Notion. L’estensione legge il contenuto renderizzato — testo in chiaro di email composte, note, messaggi — e lo trasmette in chiaro a server esterni. Unit 42 ha documentato casi in cui il contenuto delle email e gli OTP vengono esfiltrati tramite questa tecnica prima ancora dell’invio.

4. Traffic Proxying via PAC

Alcune estensioni configurano le impostazioni proxy del browser tramite file PAC (Proxy Auto-Configuration) per instradare il traffico attraverso infrastrutture controllate dall’attaccante. Questo approccio non richiede permission esplicite per i singoli siti e opera in modo trasparente per l’utente.

5. Decifrazione HTTPS via Chrome Debugger Protocol

La tecnica più sofisticata: alcune estensioni agganciano il Chrome Debugger Protocol per leggere il corpo delle risposte HTTPS già decifrate. Questo bypassa la protezione della cifratura transport-layer, consentendo l’intercettazione di qualsiasi risposta HTTPS — incluse risposte delle API AI, contenuti bancari e dati di sessione autenticati.

Il ruolo degli LLM nella produzione industriale di malware browser

Un dato particolarmente significativo: diversi campioni analizzati da Unit 42 contenevano fingerprint di codice generato da LLM. I threat actor stanno utilizzando strumenti di code generation AI per accelerare lo sviluppo di estensioni malevole e scalare le campagne. Questo abbassa drasticamente la barriera tecnica per la produzione di browser malware sofisticato e rende obsoleta la correlazione tra qualità del codice e minaccia reale. La stessa tecnologia che promette produttività agli utenti legittimi viene weaponizzata per costruire più velocemente gli strumenti del crimine informatico.

Le estensioni analizzate (case study)

Tra le 18 estensioni documentate da Unit 42 con comportamenti ad alto rischio, i principali case study includono: Chrome MCP Server – AI Browser Control (RAT completo via WebSocket), Supersonic AI (infostealer di prompt), Reverse Recruiting (esfiltrazione di dati di profilo e comunicazioni), Chat AI for Chrome (intercettazione conversazioni AI), e l’estensione di traduzione Huiyi (spyware con DOM observation). Tutti si presentavano come tool di produttività AI legittimi con descrizioni convincenti sullo store Chrome.

Qualche raccomandazione

• Gestione centralizzata delle estensioni: le organizzazioni dovrebbero implementare policy di allowlisting delle estensioni browser tramite Chrome Enterprise o equivalente, vietando l’installazione autonoma da parte degli utenti su dispositivi aziendali.
• Principio del minimo privilegio per le estensioni: auditare i permessi richiesti da tutte le estensioni installate. Un’estensione che chiede accesso a debugger, webRequest, proxy e storage.sync contemporaneamente dovrebbe essere trattata con estrema cautela.
• Diffidare delle promesse di privacy locale: affermazioni come “100% local processing” non sono verificabili dall’utente e sono state documentate come false in almeno un caso della ricerca.
• Monitoraggio del traffico di rete: le connessioni WebSocket persistenti verso domini a bassa reputazione da processi browser sono un segnale di allarme rilevabile a livello di proxy/firewall aziendale.
• Aggiornare le policy di sicurezza per includere esplicitamente le estensioni browser AI come superficie di rischio, alla stregua di software di terze parti installato.

Fonte primaria: Unit 42, Palo Alto Networks, “That AI Extension Helping You Write Emails? It’s Reading Them First”, 30 aprile 2026. Le 18 estensioni sono state segnalate a Google, che ha rimosso o inviato avvisi ai proprietari per violazione delle policy.

(in)sicurezza digitale

2026-04-30 08:41:34

GLITTER CARP e SEQUIN CARP: la Cina spia giornalisti e attivisti con phishing mirato e OAuth abuse

Si parla di:
Toggle

Il Citizen Lab dell’Università di Toronto ha pubblicato un rapporto dettagliato che svela due distinti gruppi di hacker allineati con la Repubblica Popolare Cinese — denominati GLITTER CARP e SEQUIN CARP — responsabili di una campagna sistematica di sorveglianza digitale e phishing contro giornalisti investigativi, attivisti uiguri, tibetani, taiwanesi e hongkonghesi. La ricerca, condotta in collaborazione con l’International Consortium of Investigative Journalists (ICIJ), rappresenta un’ulteriore conferma della pervasività della repressione digitale transnazionale (DTR) orchestrata da Pechino.

Il contesto: la repressione digitale transnazionale della Cina

La Cina ha una lunga storia di persecuzione dei propri oppositori all’estero. Dagli anni ’90, le autorità di Pechino hanno minacciato, intimidito e fisicamente attaccato cittadini cinesi residenti all’estero che esprimevano dissenso verso il Partito Comunista. Nel corso dei decenni, la platea dei bersagli si è ampliata per includere esponenti delle diaspore tibetana, uigura, taiwanese e hongkonghese — i cosiddetti “Cinque Veleni” secondo la terminologia del CCP — oltre ai praticanti del Falun Gong e ai giornalisti che ne documentano le attività.

Il rapporto del Citizen Lab (Report No. 193, pubblicato il 27 aprile 2026) analizza come questa repressione si sia evoluta verso un modello di Military-Civil Fusion: attacchi state-sponsored eseguiti da contractor civili privati, con una netta divisione del lavoro tra i vari gruppi coinvolti. GLITTER CARP e SEQUIN CARP rappresentano due nodi distinti di questa rete, con TTP differenti ma finalità complementari.

GLITTER CARP: phishing massivo e furto di credenziali email

GLITTER CARP è attivo almeno dall’aprile 2025 e conduce una campagna di phishing ad ampio spettro, ma chirurgicamente mirata in termini di selezione delle vittime. Il gruppo ha colpito il World Uyghur Congress, lo Uyghur Human Rights Project (UHRP), TibCERT (la rete di risposta agli incidenti per la comunità tibetana), il media taiwanese Watchout e numerosi attivisti individuali come Carmen Lau, figura di spicco dell’attivismo hongkonghese.

Le tecniche adottate rivelano un’accurata preparazione operativa. In un caso emblematico, l’attivista uiguro-canadese Mehmet Tohti ha ricevuto un messaggio apparentemente proveniente da un noto regista uiguro, con una richiesta di visionare un documentario in anteprima. Il link non conduceva ad alcun video, ma a una pagina di login Google contraffatta. Il Citizen Lab ha inoltre identificato l’uso sistematico di tracking pixel nascosti nelle email di phishing, per verificare che il messaggio venisse aperto prima di procedere con la fase successiva dell’attacco.

L’infrastruttura di GLITTER CARP è stata documentata anche da Proofpoint, che ha osservato il riuso degli stessi domini e delle stesse identità impersonate in attacchi contro molteplici target. Il Citizen Lab ha identificato oltre cento domini correlati, alcuni dei quali probabilmente impiegati in operazioni non ancora rese pubbliche. L’obiettivo primario del gruppo sembra essere l’accesso iniziale ad account email, suggerendo un contratto specializzato all’interno del sistema Military-Civil Fusion che delega la compromissione dei dispositivi ad altri attori.

SEQUIN CARP: OAuth abuse e spionaggio dei giornalisti ICIJ

SEQUIN CARP opera con metodologie più sofisticate e ha come bersaglio principale i giornalisti dell’ICIJ impegnati nell’indagine “China Targets” — un progetto che documenta le pratiche di repressione transnazionale del CCP. La giornalista Scilla Alecci, coordinatrice del progetto, è stata oggetto di almeno tre tentativi di compromissione tra giugno 2025 e marzo 2026.

Il vettore d’attacco distintivo di SEQUIN CARP è il phishing OAuth: anziché rubare password, il gruppo induce le vittime a concedere autorizzazioni di accesso a email e calendario a un’applicazione di terze parti apparentemente legittima. Questa tecnica è particolarmente insidiosa perché:

• Non richiede la conoscenza della password della vittima
• Il token OAuth mantiene l’accesso anche dopo un cambio di password
• L’accesso persiste finché la vittima non revoca manualmente il permesso dall’elenco delle app autorizzate
• Le attività di lettura delle email non lasciano tracce nei log di accesso tradizionali

Per rendere credibili i propri approcci, SEQUIN CARP costruisce personas elaborate basate su narrative reali. In un caso, gli attaccanti hanno impersonato Bai Bin, un ex funzionario di un tribunale di Pechino la cui storia era già stata riportata da media cinesi, usando la sua identità per avvicinare la giornalista Alecci con una richiesta di informazioni apparentemente plausibile. Nonostante le capacità tecniche avanzate, il gruppo ha commesso errori operativi significativi che hanno permesso al Citizen Lab di tracciarne l’infrastruttura.

Attribuzione e implicazioni geopolitiche

Il Citizen Lab valuta con alta confidenza che entrambi i gruppi operino in favore della Repubblica Popolare Cinese, inserendosi nel pattern più ampio di repressione digitale transnazionale documentato negli ultimi anni. La coesistenza di due attori distinti con TTP differenti ma target sovrapposti suggerisce un ecosistema di contractor specializzati che risponde a mandati governativi specifici — un modello coerente con il sistema Military-Civil Fusion del governo cinese.

Proofpoint aveva già documentato attività correlate a GLITTER CARP contro altri soggetti legati agli interessi di Pechino, rafforzando l’ipotesi di una campagna coordinata e continuativa piuttosto che di operazioni episodiche. La duplice attenzione sull’ICIJ — con due attori separati che perseguono strategie diverse — evidenzia quanto l’organizzazione e i suoi giornalisti siano percepiti come minacce significative dalla leadership cinese.

Indicatori di Compromissione (IoC)

# Infrastruttura GLITTER CARP (domini impersonation identificati dal Citizen Lab)
# Categorie principali di impersonation:
# - Servizi Google (login, accounts, security-alerts)
# - Pagine ICIJ false
# - Profili di attivisti noti impersonati

# Tattiche SEQUIN CARP - OAuth Abuse
# Endpoint di autorizzazione OAuth abusati per accesso persistente a Gmail
# Tipologia di permessi richiesti: mail.read, calendar.readonly
# Vettore: email di spear-phishing con link a pagina di consent OAuth fake

# Tracking pixel:
# - Pixel nascosti nelle email per confermare apertura messaggio
# - Utilizzati come trigger per avanzamento attacco

# Referenza report completo:
# https://citizenlab.ca/research/how-chinese-actors-use-impersonation-and-stolen-narratives-to-perpetuate-digital-transnational-repression/

Come proteggersi: raccomandazioni per i difensori

Il Citizen Lab fornisce indicazioni pratiche per chi opera in ambienti ad alto rischio. In primo luogo, è fondamentale effettuare revisioni periodiche delle applicazioni OAuth autorizzate nel proprio account Google o Microsoft, revocando immediatamente qualsiasi accesso non riconosciuto o non più necessario. L’uso di chiavi di sicurezza hardware (FIDO2/WebAuthn) come secondo fattore di autenticazione rappresenta la misura più efficace contro i tentativi di phishing tradizionali, poiché il token fisico non può essere replicato su siti contraffatti.

Per i giornalisti e gli attivisti ad alto rischio, il Citizen Lab raccomanda l’adozione di strumenti come Access Now’s Digital Security Helpline e una formazione specifica sui pattern di spear-phishing legati alla repressione cinese. La verifica dell’identità dei contatti attraverso canali alternativi prima di cliccare su qualsiasi link — anche apparentemente proveniente da persone conosciute — rimane la misura preventiva più critica in questo contesto operativo.

Fonte primaria: Citizen Lab Report No. 193, “Tall Tales: How Chinese Actors Use Impersonation and Stolen Narratives to Perpetuate Digital Transnational Repression”, 27 aprile 2026. In collaborazione con ICIJ.