Norme per gli sviluppatori e linee guida per la sicurezza

Simon Hangl

Demián Renzulli

Le app web isolate (IWA) forniscono un modello di sicurezza che consente alle applicazioni web di accedere a funzionalità avanzate, come Direct Sockets e Controlled Frame, che in genere sono limitate nel web "drive-by" standard. Poiché gli IWA operano in un ambiente di elevata fiducia, devono rispettare rigorose norme sulla sicurezza e sulla privacy. Queste linee guida sono progettate per garantire che, man mano che la piattaforma web acquisisce maggiore potenza, gli utenti rimangano al sicuro e l'integrità dell'ambiente del browser venga mantenuta.

Il modello di attendibilità IWA

Il fulcro della piattaforma IWA è costituito da norme tecniche rigorose che obbligano gli sviluppatori a mantenere un elevato livello di sicurezza. Mentre le app web standard si basano su un modello di autorizzazioni flessibile, le IWA vengono firmate crittograficamente e distribuite utilizzando i bundle web, il che consente di verificarne l'origine e l'integrità.

In cambio di questa identità verificata, gli IWA ottengono l'accesso alle API privilegiate. Per mantenere questa fiducia, gli sviluppatori devono adottare un approccio incentrato sulla sicurezza rispettando norme più rigorose, tra cui CSP (Content Security Policy) e Trusted Types, che garantiscono la sicurezza degli utenti anche quando utilizzano funzionalità avanzate. Ciò significa che:

• Trasparenza:gli utenti non devono mai essere sorpresi dall'utilizzo di API privilegiate da parte di un'applicazione.
• Privilegio minimo: le app devono richiedere e utilizzare solo le funzionalità specifiche necessarie per lo scopo dichiarato.
• Integrità statica:tutta la logica eseguibile deve essere autonoma all'interno del pacchetto dell'app per consentire l'audit di sicurezza e impedire il caricamento laterale di codice dannoso.

Sebbene le app web installabili includano protezioni integrate efficaci, come un Criterio di sicurezza del contenuto (CSP) rigoroso che impedisce l'esecuzione di script esterni, i soli vincoli tecnici non possono mitigare ogni rischio. Anche in un ambiente di elevata fiducia, determinati pattern di implementazione o scelte degli sviluppatori possono compromettere involontariamente la sicurezza o la privacy degli utenti. Questa guida descrive questi scenari con limitazioni e le norme che regolano l'utilizzo delle API con privilegi.

Perché queste linee guida sono importanti

Il rispetto di queste norme non riguarda solo la conformità, ma anche la creazione di un ecosistema sostenibile per le applicazioni web avanzate. Se segui queste linee guida, ti assicuri che la tua applicazione:

• Evita regressioni della sicurezza:impedisce vulnerabilità come il cross-site scripting (XSS) e l'esecuzione di codice remoto mantenendo la logica autonoma.
• Protegge la privacy degli utenti:garantisce che i dati sensibili e l'accesso all'hardware vengano gestiti solo con l'intento e la trasparenza espliciti dell'utente.
• Garantisce la longevità della piattaforma: contribuisce a mantenere gli elevati standard di sicurezza richiesti per la piattaforma IWA per continuare a espandere il proprio set di funzionalità.

Principi fondamentali

Trasparenza e intenzione dell'utente

La regola più fondamentale è: non sorprendere l'utente. Il comportamento della tua applicazione deve essere in linea con lo scopo dichiarato e le aspettative degli utenti.

• Rimani nell'ambito: non implementare funzionalità che vadano oltre lo scopo chiaro della tua applicazione.
• Ingombro minimo dell'API:richiedi e utilizza solo il set specifico di API IWA necessario per ottenere la funzione principale della tua app.

Nessun caricamento laterale del codice dinamico

Il modello di sicurezza IWA dipende dalla capacità degli amministratori o del fornitore del browser di verificare tutta la logica eseguibile. Di conseguenza, il pacchetto IWA deve essere autonomo. La piattaforma applica questa policy tramite una Content Security Policy (CSP) rigorosa che blocca l'esecuzione basata su stringhe come eval() e new Function():

script-src 'self' 'wasm-unsafe-eval';
require-trusted-types-for 'script';

Sebbene la CSP consenta a 'wasm-unsafe-eval' di supportare WebAssembly, non devi aggirare lo spirito di questo limite di sicurezza.

Pratiche severamente vietate

• Invio di interpreti per codice remoto:non puoi includere un interprete di codice (ad esempio Python o Lua compilato in WASM) per scaricare ed eseguire script esterni utilizzando l'accesso di rete privilegiato come Direct Sockets.
• Logica caricata da remoto:non utilizzare i service worker per incorporare codice caricato da remoto nell'origine dell'IWA.
• Codice e dati:sebbene sia consentito scaricare dati (ad esempio JSON), scaricare qualsiasi codice destinato a essere interpretato o eseguito costituisce una violazione diretta delle norme.

Il principio del privilegio minimo

Utilizza sempre l'API meno potente in grado di svolgere un'attività. Le API specifiche di IWA con privilegi non devono mai essere utilizzate come scorciatoia per aggirare i vincoli di sicurezza o le richieste agli utenti delle API web standard. La seguente tabella descrive i casi d'uso comuni per aiutarti a decidere quando utilizzare le API web tradizionali rispetto alle funzionalità specifiche delle app web installabili:

Linee guida specifiche per le API

Le API IWA forniscono funzionalità avanzate che in genere sono limitate nel browser. La linea guida generale è di non utilizzare mai queste funzionalità privilegiate in modo da sorprendere gli utenti o compromettere la loro fiducia e i loro dati.

API Direct Sockets

L'API Direct Sockets concede l'accesso TCP e UDP non elaborato, incluso l'accesso multicast e alla rete locale.

Consentito

• Supporto di protocolli personalizzati:connessione a server remoti che utilizzano protocolli personalizzati per i quali al momento non esiste un'API web di livello superiore.
• Gestione dei servizi di backend:connessione a un server predefinito e hardcoded utilizzato specificamente per i servizi di backend della tua applicazione.
• Rilevamento di hardware essenziale:accesso alla rete locale o utilizzo del multicast per rilevare hardware specifico e correlato essenziale per la funzione dell'app (ad esempio, un'app di editing video che individua lo spazio di archiviazione collegato alla rete).

Non consentito

• Sorprendere l'utente: implementazione dell'accesso alla rete non chiaramente giustificato dalla funzionalità principale dell'app, ad esempio un editor di testo che comunica con i dispositivi di rete locali.
• Scansione arbitraria delle reti:esecuzione di scansioni generali della rete locale dell'utente (ad esempio, scansione delle porte 192.168.1.0/24) per profilare l'utente o scoprire dispositivi non correlati.
• Targeting di dispositivi locali: è severamente vietato tentare di analizzare, riconfigurare o attaccare altri dispositivi sulla rete locale.

API Controlled Frame

L'elemento <controlledframe> consente l'incorporamento e la modifica di contenuti cross-origin, inclusi l'inserimento di script e l'alterazione delle intestazioni.

Consentito

• Semplificazione delle interfacce utente:incorporamento di un servizio di terze parti e inserimento di CSS per nascondere elementi dell'interfaccia utente non pertinenti o fornire un'esperienza più coesa.
• Mediazione della comunicazione sicura:funge da gatekeeper ricevendo richieste dalla pagina incorporata con postMessage e restituendo solo i dati necessari e sanitizzati recuperati tramite API privilegiate.

Non consentito

• Sottrazione delle credenziali utente:inserimento di script per acquisire password, cookie di sessione o altri dati sensibili degli utenti dai contenuti incorporati.
• Violazione dei termini di servizio: alterazione delle piattaforme incorporate in modi che violano i relativi Termini di servizio, ad esempio clic sugli annunci programmatici o scraping non autorizzato.
• Proxying privileged access:creazione di un pass-through che consente a contenuti incorporati non attendibili di accedere direttamente o in modo incontrollato a un'API IWA privilegiata.
• Implementazione dell'AI incontrollata:esecuzione di azioni per conto di un utente che ha eseguito l'accesso tramite l'AI senza vincoli specifici e trasparenti per i casi d'uso.

Registrazione dello schermo senza limiti

Consente l'acquisizione dello schermo senza le richieste ripetute di autorizzazione dell'utente presenti nel web standard.

Consentito

• Fornire funzionalità di base:utilizzare l'acquisizione dello schermo come parte ovvia del servizio dell'app, ad esempio nelle funzionalità di registrazione di riunioni virtuali o tutorial.
• Garantire la consapevolezza degli utenti: informare chiaramente gli utenti che la registrazione potrebbe avvenire prima che interagiscano con l'applicazione.

Non consentito

• Registrazione furtiva:acquisizione dello schermo dell'utente senza il suo consenso e senza che ne sia esplicitamente a conoscenza.
• Violazione delle norme sulla privacy: adozione di pratiche di registrazione che violano le leggi sulla privacy locali o internazionali.

WebUSB senza limitazioni

WebUSB senza restrizioni ignora la lista bloccata WebUSB standard per consentire l'interazione di basso livello con i dispositivi.

Consentito

• Supporto di hardware proprietario:interazione con hardware specializzato o legacy per il quale non esiste un'API web di alto livello, ad esempio controller industriali.

Ora consentito

• Ignorare le API dedicate:utilizzare WebUSB per i dispositivi che hanno un'API più specifica e vincolata, come le smart card (utilizzare l'API Smart Card) o l'archiviazione esterna (utilizzare l'API File System Access).

Gestione delle finestre (window.open e window.focus)

Le IWA possono creare popup e finestre di messa a fuoco senza il gesto dell'utente richiesto dal web standard.

Consentito

• Notifica del completamento dell'attività: messa in primo piano della finestra dell'app al termine di un'attività in background critica avviata dall'utente, ad esempio il rendering di un video.

Non consentito

• Spamming: bombardare l'utente con più finestre non richieste.
• Phishing:apertura di finestre progettate per imitare le finestre di dialogo di sistema o ingannare l'utente.
• Sottrazione del focus:interruzione dell'attività dell'utente sottraendo il focus da altre applicazioni per eventi non critici.

Conclusione

L'architettura di sicurezza delle app web isolate è progettata per consentire agli sviluppatori di lavorare in un ambiente di massima fiducia per gli utenti. Se rispetti queste linee guida, ti assicuri che la tua applicazione rimanga un membro responsabile dell'ecosistema IWA. I concetti più importanti da ricordare di questa guida includono:

• Dai la priorità alla trasparenza:il comportamento della tua applicazione deve sempre essere in linea con lo scopo dichiarato; non implementare mai funzionalità che potrebbero sorprendere o ingannare l'utente.
• Applica l'integrità del pacchetto:tutta la logica eseguibile deve essere autonoma all'interno del bundle IWA per consentire la verifica statica. È severamente vietato aggirare il modello di sicurezza tramite il sideloading di codice dinamico o interpreti remoti.
• Rispetta il principio del privilegio minimo:seleziona sempre l'API più vincolata disponibile per una determinata attività. Le API IWA privilegiate devono essere utilizzate solo quando le API web standard non sono sufficienti per la funzionalità di base dell'applicazione.
• Fungere da gatekeeper:quando utilizzi strumenti potenti come <controlledframe>, il tuo IWA deve fungere da intermediario sicuro anziché da proxy trasparente per contenuti non attendibili.

Prima di pubblicare la tua IWA, esegui un audit finale della tua implementazione ponendoti le seguenti domande:

1. Sto utilizzando l'API più semplice e con il maggior numero di vincoli possibile per questa attività?
2. Un utente rimarrebbe sorpreso o si sentirebbe tradito da ciò che fa la mia app?

Se la risposta alla prima domanda è "No" o alla seconda è "Sì", è probabile che la tua applicazione violi le norme di sicurezza IWA e potrebbe essere rimossa.