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-02 14:37:38

SHADOW-EARTH-053: la campagna APT cinese che spia governi asiatici, la NATO e i diplomatici cubani

Una campagna di cyberspionaggio di alto livello, attribuita ad attori allineati agli interessi strategici della Cina, ha colpito nell’arco degli ultimi mesi governi, contractor della difesa, aziende tecnologiche e media in almeno otto paesi asiatici e in Polonia, unico Stato membro della NATO nel mirino. Nell’ambito dello stesso quadro operativo, un’operazione parallela ha violato la casella email di 68 diplomatici cubani a Washington durante uno dei momenti di tensione geopolitica più acuti del 2026. Il quadro che emerge è quello di una macchina d’intelligence cinese capace di operare su più fronti simultaneamente, adattando toolchain e vettori di attacco a obiettivi molto diversi tra loro.

SHADOW-EARTH-053: profilo del gruppo e attribuzioni

Il 30 aprile 2026, Trend Micro ha pubblicato un’analisi tecnica dettagliata di un nuovo intrusion set temporaneo denominato SHADOW-EARTH-053. Il gruppo è attivo almeno dal dicembre 2024 e viene valutato con elevata confidenza come allineato agli interessi della Repubblica Popolare Cinese. I target identificati spaziano dall’Asia meridionale (Pakistan, India, Sri Lanka, Myanmar) a quella orientale (Taiwan) e sud-orientale (Thailandia, Malaysia), fino a un Paese europeo membro della NATO: la Polonia.

La campagna si concentra principalmente su organizzazioni governative e del settore difesa, ma ha colpito anche aziende del settore tecnologico, trasporti e media. L’ampiezza geografica e la diversità dei target riflettono le priorità di intelligence della Cina nella regione Indo-Pacifica, con la Polonia che rappresenta probabilmente un obiettivo correlato al monitoraggio dell’assistenza militare occidentale all’Ucraina.

Vettori di accesso iniziale: da Exchange a React2Shell

SHADOW-EARTH-053 dimostra notevole flessibilità nei vettori di accesso iniziale. Il gruppo sfrutta vulnerabilità note ma non patchate in Microsoft Exchange Server — in particolare la catena ProxyLogon (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065) — e nei server Internet Information Services (IIS). La presenza di server Exchange senza patch a distanza di anni dalla disclosure rimane un problema sistemico nelle reti governative di molti paesi target.

Più recentemente, il gruppo ha aggiunto al proprio arsenale lo sfruttamento di CVE-2025-55182, alias React2Shell, una vulnerabilità critica con CVSS score di 10.0 che affligge React Server Components, Next.js e framework correlati. La falla consente l’esecuzione di codice arbitrario remoto pre-autenticazione tramite una singola richiesta HTTP malevola. In alcuni casi, ShadowPad è stato recapitato anche tramite AnyDesk, mostrando adattabilità nella catena di compromissione.

La toolchain: ShadowPad, Godzilla e Noodle RAT

Dopo l’accesso iniziale, SHADOW-EARTH-053 installa web shell Godzilla per mantenere un accesso persistente al server compromesso. Godzilla consente l’esecuzione remota di comandi e offre funzionalità di gestione file, proxy SOCKS5 e memory injection, rendendola una piattaforma di staging ideale per le fasi successive.

Il payload principale è ShadowPad, un backdoor modulare di uso esclusivo dei gruppi APT cinesi sin dalla sua comparsa nel 2017. ShadowPad viene caricato tramite DLL sideloading di eseguibili legittimi firmati digitalmente (Microsoft, Samsung e altri vendor), con il payload cifrato spesso archiviato nel registro di sistema ed eliminato dopo il primo utilizzo. La persistenza è garantita da un task pianificato denominato “M1onltor”, configurato per eseguire il binario sideloaded ogni cinque minuti con i massimi privilegi disponibili.

Su infrastrutture Linux, i ricercatori hanno identificato con bassa confidenza campioni di Noodle RAT, una RAT cross-platform distribuita tramite la stessa infrastruttura e controllata via domini con temi office365. Ciò suggerisce un’espansione verso ambienti non-Windows, tipicamente meno monitorati nelle reti enterprise.

Movimento laterale e ricognizione interna

Post-compromissione, SHADOW-EARTH-053 esegue una ricognizione sistematica di Active Directory e Exchange direttamente dalla web shell: enumerazione degli admin di dominio, discovery dei domain controller tramite nltest, export AD via csvde e mapping di utenti e mailbox con Get-DomainUser di PowerView.

Per il movimento laterale il gruppo utilizza IOX, un tool di tunneling proxy, configurando LocalAccountTokenFilterPolicy = 1 per abilitare Pass-the-Hash sugli account amministratori locali. Il movimento laterale si avvale di WMIC per distribuire backdoor e tool su host Windows aggiuntivi, affiancato da un launcher RDP personalizzato (smss.exe) e da Sharp-SMBExec, un tool C# per operazioni SMB.

L’operazione sull’ambasciata cubana: spionaggio diplomatico in tempo reale

Parallelamente alla campagna SHADOW-EARTH-053, la società Gambit Security ha documentato un’operazione distinta ma stilisticamente riconducibile a gruppi di intelligence cinesi: la compromissione dei server di posta elettronica dell’ambasciata cubana a Washington. L’attacco è iniziato a gennaio 2026 e ha interessato le caselle email di 68 funzionari, tra cui l’ambasciatore e il suo vice. I vettori di intrusione sono stati — anche qui — vulnerabilità nei server Microsoft Exchange, rimaste non patchate per circa cinque anni.

La tempistica dell’operazione è significativa: gli hacker hanno letto corrispondenza diplomatica riservata proprio mentre gli Stati Uniti intensificavano le pressioni su Cuba sull’onda delle operazioni in Venezuela, con restrizioni alle forniture di petrolio che hanno causato blackout di massa sull’isola. Nella stessa finestra temporale, la stessa infrastruttura ha condotto attacchi contro il governo del Venezuela e il suo Ministero degli Affari Esteri. Separatamente, lo sfruttamento della vulnerabilità React (CVE-2025-55182) ha consentito al gruppo di ottenere accesso a circa 5.000 server in pochi giorni, inclusi sistemi governativi in Texas e aziende private.

Tecniche di evasione

SHADOW-EARTH-053 adotta diverse tecniche per ostacolare il rilevamento. Il packer RingQ viene usato per offuscare i payload. I tool come net.exe e PowerShell vengono rinominati con nomi casuali con estensione .log. I domini di command and control mimicano prodotti di sicurezza o servizi DNS legittimi. L’uso estensivo di living-off-the-land binaries (LOLBins) riduce ulteriormente la firma di rilevamento sugli endpoint.

Indicatori di compromissione (IoC)

# Tool e binari associati a SHADOW-EARTH-053
# Scheduled Task persistence
Task name: M1onltor
Trigger: ogni 5 minuti, SYSTEM privileges

# Strumenti post-compromissione
- IOX proxy tunneling tool
- Sharp-SMBExec (C# SMB lateral movement)
- RingQ packer (per offuscamento payload)
- PowerView (Get-DomainUser)
- csvde.exe (AD export)
- nltest.exe (domain controller discovery)

# Malware identificati
- ShadowPad backdoor (DLL sideloading via eseguibili firmati Microsoft/Samsung)
- Godzilla webshell
- Noodle RAT (variante Linux, bassa confidenza)

# CVE sfruttate
- CVE-2021-26855 / CVE-2021-26857 / CVE-2021-26858 / CVE-2021-27065 (ProxyLogon - Exchange)
- CVE-2025-55182 "React2Shell" (CVSS 10.0 - RCE pre-auth su React Server Components)

# Indicatori infrastrutturali
- Domini C2 che imitano prodotti di sicurezza o servizi DNS
- Domini con temi "office365" per Noodle RAT C2
- Eseguibili rinominati con estensione .log (net.exe, PowerShell)

Implicazioni e raccomandazioni per i difensori

La campagna SHADOW-EARTH-053 evidenzia alcune priorità difensive urgenti. Patch management su Exchange e IIS rimane critico: la persistenza di vulnerabilità come ProxyLogon a distanza di anni dalla divulgazione indica processi di patching inadeguati in molte organizzazioni pubbliche. Il monitoraggio di task pianificati con nomi insoliti (come “M1onltor”) e del DLL sideloading da processi firmati legittimi dovrebbe essere parte delle regole di detection SIEM standard. Il rilevamento di tool come IOX, csvde e nltest in contesti anomali può segnalare ricognizione post-compromissione. La protezione delle API React Server Components e l’applicazione del patch per CVE-2025-55182 è urgente per chiunque gestisca applicazioni Next.js in produzione.

Sul piano geopolitico, la combinazione SHADOW-EARTH-053 + operazione ambasciata cubana dimostra la capacità dei servizi di intelligence cinesi di condurre operazioni simultanee e multi-obiettivo, adattando gli strumenti in funzione del target — dal backdoor militare ShadowPad per i governi alla compromissione silente dei server di posta diplomatici. Per i team di sicurezza delle organizzazioni governative, difesa e infrastrutture critiche in Europa e Asia, questa campagna rappresenta un segnale d’allerta difficile da ignorare.