Spcnet.it

2026-04-22 09:19:56

Creare addon nativi per Node.js con .NET Native AOT: addio a Python e node-gyp

Da sempre, creare addon nativi per Node.js significava entrare nel mondo di C++ e node-gyp, con la necessità di installare Python, Visual Studio Build Tools e una serie di dipendenze che trasformavano il setup dell’ambiente in un’impresa. Il team di C# Dev Kit di Microsoft ha trovato una soluzione elegante: usare .NET Native AOT per produrre librerie condivise compatibili con l’interfaccia N-API di Node.js, scritte interamente in C#.

In questo articolo vediamo come funziona questa tecnica, analizzando la struttura del progetto, il meccanismo di interop e i punti critici da tenere d’occhio in produzione.

Perché Node.js supporta addon scritti in qualsiasi linguaggio

Un addon nativo per Node.js è semplicemente una libreria condivisa (.dll su Windows, .so su Linux, .dylib su macOS) che esporta un punto di ingresso preciso: la funzione napi_register_module_v1. Node.js carica la libreria, chiama questa funzione e da quel momento il modulo è disponibile per JavaScript.

L’interfaccia che rende tutto questo possibile è N-API (Node-API), una API C stabile e ABI-compatibile tra le versioni di Node.js. Questo significa che qualsiasi linguaggio in grado di produrre una shared library ed esportare una funzione C può diventare un addon Node.js — incluso C# compilato con Native AOT.

Configurazione del progetto .NET

Il file di progetto è sorprendentemente minimale:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <PublishAot>true</PublishAot>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
  </PropertyGroup>
</Project>

Due impostazioni chiave:

• PublishAot: abilita la compilazione Ahead-of-Time, producendo una shared library nativa invece di un assembly IL.
• AllowUnsafeBlocks: necessario per l’interop con N-API tramite function pointer e tipi non gestiti.

Il punto di ingresso del modulo

L’entry point usa l’attributo [UnmanagedCallersOnly], che istruisce il compilatore a generare una funzione C-callable con la firma esatta attesa da Node.js:

[UnmanagedCallersOnly(
    EntryPoint = "napi_register_module_v1",
    CallConvs = [typeof(CallConvCdecl)])]
public static nint Init(nint env, nint exports)
{
    // Registrazione delle funzioni esposte
    return exports;
}

Il tipo nint (native-sized integer) rappresenta gli handle opachi che N-API usa per riferirsi agli oggetti JavaScript. Non si tratta di puntatori diretti a memoria, ma di token gestiti dall’engine V8 tramite N-API.

Risoluzione delle funzioni N-API a runtime

Le funzioni N-API (come napi_create_string_utf8 o napi_get_cb_info) sono esportate direttamente da node.exe, non da una DLL separata. Per fare in modo che P/Invoke le risolva correttamente, si registra un custom resolver:

private static void Initialize()
{
    NativeLibrary.SetDllImportResolver(
        System.Reflection.Assembly.GetExecutingAssembly(),
        ResolveDllImport);
}

private static nint ResolveDllImport(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
{
    if (libraryName == "node")
        return NativeLibrary.GetMainProgramHandle();
    return IntPtr.Zero;
}

Questo permette di dichiarare le importazioni P/Invoke con [LibraryImport("node")] e averle risolte contro il processo host a runtime.

Marshalling delle stringhe UTF-8

Uno dei punti più delicati è la conversione tra stringhe JavaScript (UTF-16 internamente in V8, UTF-8 via N-API) e stringhe .NET. La strategia ottimale prevede:

• Uso dello stack per stringhe piccole (≤512 byte) tramite stackalloc
• Uso di ArrayPool<byte> per stringhe più grandi, evitando allocazioni sull’heap

private static string GetStringArg(nint env, nint info, int argIndex)
{
    // Recupera l'handle dell'argomento
    nint value = GetArgument(env, info, argIndex);
    
    // Prima chiamata: ottieni la dimensione necessaria
    nuint byteCount;
    napi_get_value_string_utf8(env, value, null, 0, out byteCount);
    
    // Allocazione efficiente in base alla dimensione
    if (byteCount <= 512)
    {
        Span<byte> buffer = stackalloc byte[(int)byteCount + 1];
        napi_get_value_string_utf8(env, value, buffer, (nuint)buffer.Length, out _);
        return Encoding.UTF8.GetString(buffer[..^1]);
    }
    else
    {
        byte[] buffer = ArrayPool<byte>.Shared.Rent((int)byteCount + 1);
        try
        {
            napi_get_value_string_utf8(env, value, buffer, (nuint)buffer.Length, out _);
            return Encoding.UTF8.GetString(buffer, 0, (int)byteCount);
        }
        finally
        {
            ArrayPool<byte>.Shared.Return(buffer);
        }
    }
}

Implementazione di una funzione reale: lettura dal Registry

L’esempio concreto mostrato dal team di Microsoft è un lettore del Windows Registry, che sostituisce il precedente addon C++:

private static nint ReadStringValue(nint env, nint info)
{
    try
    {
        var keyPath = GetStringArg(env, info, 0);
        var valueName = GetStringArg(env, info, 1);
        
        using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);
        
        return key?.GetValue(valueName) is string value
            ? CreateString(env, value)
            : GetUndefined(env);
    }
    catch (Exception ex)
    {
        // CRITICO: le eccezioni non gestite in [UnmanagedCallersOnly] crashano il processo
        ThrowError(env, $"Registry read failed: {ex.Message}");
        return 0;
    }
}

Attenzione: in un metodo [UnmanagedCallersOnly], le eccezioni non gestite provocano il crash dell’intero processo Node.js. Il pattern try/catch con ThrowError trasforma l’eccezione .NET in un errore JavaScript, mantenendo stabile il runtime.

Integrazione con TypeScript

Dopo dotnet publish, il file prodotto viene rinominato con estensione .node (convenzione Node.js) e caricato normalmente da TypeScript:

interface RegistryAddon {
    readStringValue(keyPath: string, valueName: string): string | undefined;
}

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;

const sdkPath = registry.readStringValue(
    'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
    'InstallLocation'
);
console.log(`SDK installato in: ${sdkPath}`);

Limiti e considerazioni

Questa tecnica ha un limite importante: Native AOT non supporta la cross-compilazione. Per ogni piattaforma target (Windows x64, Linux x64, macOS ARM64…) è necessario un ambiente di build separato. In pratica, questo si risolve con pipeline CI che eseguono la build su runner del sistema operativo corrispondente.

Esiste anche un’alternativa di più alto livello, node-api-dotnet, che astrae molti dei dettagli mostrati qui e supporta scenari più complessi come l’esposizione di interi namespace .NET a JavaScript. L’approccio “thin wrapper” descritto in questo articolo è preferibile quando si vuole controllo totale e dipendenze minime.

Conclusioni

L’integrazione tra .NET Native AOT e N-API apre uno scenario interessante per i team che già lavorano con C# e devono interfacciarsi con l’ecosistema Node.js. Eliminare Python e node-gyp dal setup semplifica notevolmente l’ambiente di sviluppo e unifica le competenze necessarie intorno a un unico SDK.

Il risultato è codice nativo con prestazioni paragonabili al C++, scritto con la produttività e la type safety di C# moderno, deployabile su Windows, Linux e macOS.

---

Fonte: Writing Node.js addons with .NET Native AOT — Microsoft .NET Blog, Drew Noakes

Writing Node.js addons with .NET Native AOT - .NET Blog

The C# Dev Kit team replaced C++ Node.js addons with C# and Native AOT, removing a dependency on Python. This post walks through building a Node.js native addon entirely in C# using N-API, LibraryImport, and UnmanagedCallersOnly.

^{Drew Noakes (.NET Blog)}

(in)sicurezza digitale

2026-04-22 09:33:07

Violazione ANTS: un banale difetto IDOR espone 19 milioni di identità francesi in vendita sul dark web

Si parla di:
Toggle

Una vulnerabilità elementare di tipo IDOR (Insecure Direct Object Reference) sull’API del portale governativo francese ANTS ha consentito a un attore di minaccia di estrarre fino a 19 milioni di record contenenti dati anagrafici e di identità dei cittadini francesi. La vicenda, emersa pubblicamente il 21 aprile 2026, solleva interrogativi profondi sulla sicurezza delle infrastrutture digitali dello Stato francese e sulla protezione dei dati biometrici e documentali alla base del sistema di identità nazionale.

Cos’è ANTS e perché la violazione è così grave

L’Agence Nationale des Titres Sécurisés (ANTS), operativa sotto il Ministero dell’Interno francese, gestisce le domande e il ciclo di vita dei documenti d’identità ufficiali dei cittadini: carte d’identità nazionale, passaporti, patenti di guida e permessi di soggiorno. Il portale ants.gouv.fr costituisce il punto di accesso centralizzato attraverso cui milioni di francesi richiedono, rinnovano o tracciano i propri documenti d’identità. Una violazione di questa piattaforma non riguarda quindi dati di servizio generici: tocca direttamente le informazioni anagrafiche certificate dallo Stato, quelle stesse che alimentano i sistemi di identità digitale e i processi di verifica dell’identità.

La timeline: dall’intrusione alla divulgazione

La ricostruzione cronologica dell’incidente è la seguente:

• 15 aprile 2026: ANTS rileva internamente un incidente di sicurezza sul portale istituzionale e avvia le procedure di risposta agli incidenti.
• 16 aprile 2026: Un attore di minaccia che opera sotto lo pseudonimo breach3d pubblica su forum underground di hacking la rivendicazione dell’attacco, affermando di essere in possesso di un dataset di 18-19 milioni di record esfiltrati dalla piattaforma ANTS.
• 19-20 aprile 2026: Il dato viene segnalato da ricercatori di sicurezza e giornalisti specializzati che accedono ai forum underground e verificano i campioni forniti dall’attore.
• 21 aprile 2026: Il Ministero dell’Interno francese e ANTS confermano ufficialmente l’incidente, notificano il CNIL (Commission Nationale de l’Informatique et des Libertés), la Procura di Parigi e l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information).

Il vettore d’attacco: IDOR, una vulnerabilità imbarazzante

Secondo quanto riferito da fonti vicine all’indagine e dalle dichiarazioni dello stesso attaccante, il vettore di compromissione è stato un difetto di tipo IDOR (Insecure Direct Object Reference) sull’API del portale ANTS. Lo stesso breach3d ha descritto la vulnerabilità come “really stupid” — stupida nella sua semplicità — rivelando che era sufficiente modificare un identificatore numerico nelle richieste HTTP all’API per accedere ai record di qualsiasi altro utente registrato sulla piattaforma.

L’IDOR è una vulnerabilità classificata nel OWASP Top 10 da oltre vent’anni (A01:2021 – Broken Access Control). Si verifica quando un’applicazione espone riferimenti diretti a oggetti interni — come ID di database, file o record — senza verificare che l’utente richiedente abbia effettivamente l’autorizzazione ad accedere a quell’oggetto. In questo caso, l’API governativa francese non implementava controlli di autorizzazione adeguati: un utente autenticato poteva iterare sugli ID numerici degli account per raccogliere massivamente i dati di tutti gli utenti registrati. Il processo di esfiltrazione risulta quindi altamente automatizzabile con script elementari.

I dati esposti e le implicazioni per i cittadini

Il Ministero dell’Interno francese ha confermato che i dati potenzialmente esposti includono: nome e cognome, indirizzo email, data di nascita, identificativi di account univoci e credenziali di accesso (login ID). Per un sottoinsieme di utenti, potrebbero essere stati esposti anche l’indirizzo postale, il luogo di nascita e il numero di telefono. ANTS ha precisato che i documenti caricati sul portale (immagini di passaporti o patenti, ad esempio) non risultano compromessi e che i dati esfiltrati non consentono l’accesso diretto agli account.

Tuttavia, la combinazione di dati anagrafici certificati dallo Stato con informazioni di contatto apre scenari di abuso estremamente preoccupanti per i difensori:

• Phishing e spear-phishing di alta precisione: con nome completo, email, data di nascita e luogo di nascita, gli attaccanti possono costruire comunicazioni altamente credibili che si spacciano per corrispondenza ufficiale del governo francese o di istituti finanziari.
• Furto di identità e creazione di identità sintetiche: la combinazione di dati anagrafici verificati dallo Stato costituisce una base ideale per aprire conti bancari fraudolenti, richiedere prestiti o commettere frodi fiscali.
• Sextortion e social engineering: messaggi personalizzati che dimostrano conoscenza di dati specifici (luogo di nascita, data esatta) aumentano drasticamente la credibilità degli schemi di estorsione.
• Credential stuffing: gli indirizzi email associati agli account ANTS vengono tipicamente testati su altri servizi, sfruttando il riutilizzo delle password.

Il profilo dell’attore: breach3d

L’attore breach3d non è nuovo alla scena underground. Prima di questa rivendicazione aveva già pubblicato dataset di altre organizzazioni su forum frequentati da broker di dati e operatori criminali. Non ci sono elementi pubblici che permettano di attribuire l’attività a un gruppo state-sponsored o a una gang ransomware strutturata: il profilo appare più coerente con quello di un opportunista focalizzato sulla monetizzazione dei dati piuttosto che su obiettivi di intelligence. Il dataset sarebbe stato messo in vendita a un prezzo non divulgato pubblicamente.

La risposta istituzionale e le notifiche

ANTS ha comunicato che non è richiesta alcuna azione immediata da parte degli utenti, invitandoli tuttavia a mantenere alta la vigilanza nei confronti di messaggi sospetti. L’agenzia ha notificato l’incidente alla CNIL, alla Procura di Parigi e all’ANSSI, che coordineranno le indagini e valuteranno la conformità al GDPR (Regolamento Generale sulla Protezione dei Dati). La violazione, se confermata nelle proporzioni dichiarate da breach3d, configurerebbe uno degli incidenti più gravi mai registrati nell’ambito dei sistemi di identità statale europei.

Pavel Durov, fondatore di Telegram, ha pubblicamente commentato l’incidente sottolineando i rischi sistemici legati alla centralizzazione dei dati d’identità governativi su piattaforme web esposte a Internet, alimentando il dibattito sulla progettazione sicura dei portali di e-government.

Cosa possono fare i difensori

Per le organizzazioni che gestiscono portali ad alta sensibilità e per i team di sicurezza che devono valutare il rischio residuo per i propri utenti alla luce di questo dataset circolante, si raccomanda di:

• Implementare sistematicamente controlli di autorizzazione lato server su ogni endpoint API che restituisce dati associati a un identificatore: verificare sempre che l’utente autenticato sia il proprietario del record richiesto.
• Adottare test di sicurezza specifici per IDOR e Broken Access Control nei cicli di sviluppo (SAST, DAST, penetration testing con focus su API).
• Per le organizzazioni che gestiscono dipendenti o clienti francesi: alzare il livello di allerta anti-phishing e considerare campagne di sensibilizzazione mirate sull’utilizzo di questo tipo di dataset per attacchi personalizzati.
• Monitorare i propri indirizzi email aziendali su servizi di threat intelligence e breach monitoring per rilevare tempestivamente la comparsa del dataset in nuovi marketplace underground.
• Valutare l’abilitazione di autenticazione multi-fattore su tutti i servizi esposti che accettano email come username, poiché la disponibilità degli indirizzi email alimenta attacchi di account takeover.

La violazione ANTS è l’ennesima dimostrazione che le vulnerabilità più banali — note, documentate e prevenibili — continuano ad affliggere sistemi governativi critici. Una API senza controlli di accesso adeguati, su un portale che gestisce l’identità di decine di milioni di cittadini, rappresenta un rischio sistemico di proporzioni difficilmente accettabili in un’era in cui il furto d’identità digitale alimenta ecosistemi criminali globali.