Il grande bug DoS della fattura elettronica

Di recente abbiamo parlato della fattura elettronica, e di molti dei suoi punti di forza tali per cui sia da considerare sicuramente una evoluzione utile e importante.  Avendo realizzato l’integrazione con lo SdI del nostro gestionale Alberta, però, possiamo riscontrare una carenza architetturale potenzialmente molto dannosa. Vediamo di capirla.

Premessa: per trasmettere e ricevere le fatture elettroniche è necessario comunicare via Web Services con il sistema SdI fornito dall’Agenzia delle Entrate. Ci sono altri modi (PEC o FTP), ma consideriamoli per ora soluzioni “di compatibilità” e concentriamoci sul canale più importante che sono i WS. L’attivazione di un canale WS viene concessa ad uno specifico soggetto ben identificato, e tutte le comunicazioni si basano su certificati di firma digitale che identificano con certezza il titolare di quel canale.

Quindi, nel momento in cui una società attiva un canale con lo SdI, ha in sostanza la possibilità di effettuare e ricevere chiamate con il sistema SdI.

Seconda premessa: tutti i soggetti IVA possono registrare all’interno del sistema dell’Aged il canale dove vogliono ricevere le fatture elettroniche, sia esso un canale del tipo di cui sopra oppure una PEC. Lo SdI automaticamente consegna lì le comunicazioni (fatture passive), a prescindere da cosa indica il trasmittente. Questa scelta è facoltativa, se l’azienda non la compie, fa testo quanto indicato dal trasmittente.

Terza premessa: le fatture elettroniche ricevute NON si possono rifiutare. Se sono sbagliate, per qualsiasi motivo, bisogna contattare il mittente con canale “esterni allo SdI” e mettersi d’accordo per una soluzione.

A questo punto subentra il problema. Probabilmente per permettere a chi vende software e piattaforme gestionali, ma anche alle aziende che con la stessa struttura amministrativa operano per conto di diversi soggetti, di procedere con semplicità, il canale SdI accetta fatture emesse da chiunque. Vale a dire che quando io immetto nello SdI una fattura, autentico il mio canale e quindi mi faccio riconoscere, però quello che poi immetto sul canale (ancorchè ovviamente tracciato) non ha vincoli.

Facendo due più due, io posso immettere nello SdI fatture emesse da CHIUNQUE e ovviamente destinate a chiunque. E chi le riceve NON ha modo di rifiutarle ma deve contabilizzarle.

Immaginiamo ora un bug nel mio sistema, un errore di un operatore, o peggio ancora una violazione mirata appositamente a sfruttare il mio client di lavoro. In questa situazione posso iniziare ad immettere nello SdI fatture “a caso”, mettendo in grossa difficoltà chi le riceve. Che deve registrarle, e poi contattare un mittente sconosciuto che non le ha emesse e non ne sa niente, e cercare una soluzione. Immaginate se sono tante quale danno si va a generare.

Certo, il canale è autenticato quindi può essere identificato chi sta facendo “lo spam delle fatture“, lo si può bloccare, rintracciare, ecc. Ma viene tutto dopo. Ad oggi non risulta ci siano procedure di “revoca” di fatture ricevute anche in queste situazioni, o canali di contatto con lo SdI da attivare.

In sostanza la mia azienda sceglie quale è il canale su cui vuole ricevere, ma non quello da cui vuole trasmettere. Un po’ come se fosse stato implementato l’MX e non l’SPF, per fare una analogia con la posta elettronica.

Capisco la necessità di non porre barriere bloccanti in fase di startup, ma sarebbe stato molto meglio imporre a tutte le aziende di scegliere il canale di ricezione ed anche di trasmissione, vincolando le fatture in transito a tale canale solamente. Tra l’altro avrebbe evitato la necessità del frenetico scambo di dati che è in corso tra tutte le aziende italiane, in quanto non sarebbe stato necessario indicare il canale destinatario nella trasmissione fatture (bastava la PIVA ad identificarlo implicitamente).

Vedremo una nuova epoca di attacchi DoS a processi amministrativi delle aziende?

Disclaimer: ovviamente quanto sopra si basa sulla conoscenza del protocollo SdI maturata lavorandoci dall’esterno, e sullo scambio di idee con altri sviluppatori di gestionali integrati con SdI. Potrebbero esserci situazioni non note all’esterno o errori di valutazione, nel qual caso sarebbe interessante integrare il discorso con gli approfondimenti del caso.

Post Author: Bruno