Richtlijnen voor ontwikkelaarsbeleid en beveiliging

Simon Hangl
Simon Hangl
Demián Renzulli
Demián Renzulli

Geïsoleerde webapplicaties (IWA's) bieden een beveiligingsmodel waarmee webapplicaties toegang krijgen tot krachtige mogelijkheden – zoals Direct Sockets en Controlled Frame – die doorgaans beperkt zijn in het standaard "drive-by" web. Omdat IWA's opereren in een omgeving met een hoge mate van vertrouwen, moeten ze zich houden aan strikte beveiligings- en privacyrichtlijnen. Deze richtlijnen zijn ontworpen om ervoor te zorgen dat, naarmate het webplatform meer mogelijkheden krijgt, gebruikers veilig blijven en de integriteit van de browseromgeving behouden blijft.

Het IWA-trustmodel

De kern van het IWA-platform is gebouwd rond strikte technische richtlijnen die ontwikkelaars dwingen een hoog beveiligingsniveau te handhaven. Waar standaard webapplicaties gebruikmaken van een flexibel permissiemodel, zijn IWA's cryptografisch ondertekend en worden ze geleverd via Web Bundles , waardoor hun herkomst en integriteit kunnen worden geverifieerd.

In ruil voor deze geverifieerde identiteit krijgen IWA's toegang tot geprivilegieerde API's. Om dit vertrouwen te behouden, moeten ontwikkelaars een beveiligingsgerichte aanpak volgen door zich te houden aan strengere beleidsregels – waaronder een robuust Content Security Policy (CSP) en Trusted Types – die de veiligheid van gebruikers garanderen, zelfs bij gebruik van krachtige functionaliteiten. Dit betekent:

  • Transparantie: Gebruikers mogen nooit verrast worden door het gebruik van beveiligde API's door een applicatie.
  • Principe van minimale bevoegdheden: Apps mogen alleen de specifieke mogelijkheden aanvragen en gebruiken die nodig zijn voor hun beoogde doel.
  • Statische integriteit: Alle uitvoerbare logica moet volledig binnen het app-pakket zijn opgenomen om beveiligingsaudits mogelijk te maken en het sideloaden van kwaadwillende code te voorkomen.

Hoewel IWA's robuuste ingebouwde beveiligingen bevatten, zoals een strikt Content Security Policy (CSP) dat de uitvoering van externe scripts voorkomt, kunnen technische beperkingen alleen niet elk risico wegnemen. Zelfs in een omgeving met een hoge mate van vertrouwen kunnen bepaalde implementatiepatronen of keuzes van ontwikkelaars onbedoeld de veiligheid of privacy van gebruikers in gevaar brengen. Deze handleiding beschrijft deze beperkte scenario's en het beleid dat van toepassing is op het gebruik van geprivilegieerde API's.

Waarom deze richtlijnen belangrijk zijn

Het naleven van dit beleid gaat niet alleen over compliance, maar ook over het bouwen van een duurzaam ecosysteem voor geavanceerde webapplicaties. Door deze richtlijnen te volgen, zorgt u ervoor dat uw applicatie:

  • Voorkomt beveiligingslekken: voorkomt kwetsbaarheden zoals Cross-Site Scripting (XSS) en het uitvoeren van code op afstand door de logica op zichzelf te houden.
  • Beschermt de privacy van de gebruiker: zorgt ervoor dat toegang tot gevoelige gegevens en hardware alleen plaatsvindt met expliciete toestemming van de gebruiker en in volledige transparantie.
  • Garandeert de levensduur van het platform: Helpt de hoge beveiligingsnormen te handhaven die nodig zijn om het IWA-platform te blijven ontwikkelen en de functionaliteit ervan uit te breiden.

Kernprincipes

Transparantie en gebruikersintentie

De meest fundamentele regel is: verras de gebruiker niet. Het gedrag van je applicatie moet aansluiten bij het beoogde doel en de verwachtingen van de gebruiker.

  • Blijf binnen de scope : implementeer geen functionaliteit die verder gaat dan het duidelijke doel van uw applicatie.
  • Minimale API-voetafdruk: Vraag alleen de specifieke IWA API's aan en gebruik deze alleen als deze nodig zijn voor de kernfunctionaliteit van uw app.

Geen dynamische code-sideloading

Het IWA-beveiligingsmodel is afhankelijk van de mogelijkheid voor beheerders of de browserleverancier om alle uitvoerbare logica te verifiëren. Daarom moet uw IWA-pakket op zichzelf staan. Het platform dwingt dit af door middel van een strikt Content Security Policy (CSP) dat de uitvoering van stringgebaseerde functies zoals eval() en new Function() blokkeert.

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

Hoewel het CSP toestaat dat 'wasm-unsafe-eval' WebAssembly ondersteunt, mag u de geest van deze beveiligingsgrens niet omzeilen.

Strikt verboden praktijken

  • Het verzenden van interpreters voor externe code: U mag geen code-interpreter (bijvoorbeeld Python of Lua gecompileerd naar WASM) meeleveren om externe scripts te downloaden en uit te voeren met behulp van geprivilegieerde netwerktoegang zoals Direct Sockets .
  • Logica die op afstand wordt geladen: Gebruik geen service workers om code die op afstand wordt geladen in de IWA-origin in te sluiten.
  • Code versus data: Hoewel het downloaden van data (zoals JSON) is toegestaan, is het downloaden van code die bedoeld is om te worden geïnterpreteerd of uitgevoerd een directe schending van het beleid.

Het principe van de minste privileges

Gebruik altijd de minst krachtige API die een taak kan uitvoeren. Bevoorrechte IWA-specifieke API's mogen nooit worden gebruikt als een sluiproute om de beveiligingsbeperkingen of gebruikersprompts van standaard web-API's te omzeilen. De volgende tabel geeft een overzicht van veelvoorkomende gebruiksscenario's om u te helpen bepalen wanneer u traditionele web-API's en wanneer u IWA-specifieke mogelijkheden moet gebruiken:

Taak Gebruik de standaard web-API (aanbevolen) Vermijd de geprivilegieerde IWA API (Beperkt)
Toegang tot externe harde schijven Gebruik de File System Access API voor standaard bestands-I/O. Gebruik Unrestricted WebUSB niet om toegang te krijgen tot de opslag.
Interactie met smartcard Gebruik de Smart Card API . Gebruik Unrestricted WebUSB niet voor smartcards.
Seriële apparaatcommunicatie Gebruik de WebSerial API als die geschikt is voor uw apparaat. Vermijd onbeperkte WebUSB als WebSerial de taak kan uitvoeren.
Vertrouwde inhoud insluiten Gebruik een standaard <iframe> . Gebruik <controlledframe> niet voor eenvoudige embedding, tenzij isolatie vereist is.

API-specifieke richtlijnen

IWA API's bieden krachtige mogelijkheden die doorgaans beperkt zijn in de browser. Het algemene advies is om deze bevoorrechte functies nooit te gebruiken op een manier die gebruikers zou kunnen verrassen of hun vertrouwen en gegevens in gevaar zou kunnen brengen.

Direct Sockets API

De Direct Sockets API biedt directe TCP- en UDP-toegang, inclusief multicast en toegang tot het lokale netwerk.

Toegestaan

  • Ondersteuning voor aangepaste protocollen: Verbinding maken met externe servers die gebruikmaken van aangepaste protocollen waarvoor momenteel geen web-API op een hoger niveau bestaat.
  • Het onderhouden van backend-services: verbinding maken met een vooraf gedefinieerde, vastgelegde server die specifiek wordt gebruikt voor de backend-services van uw applicatie.
  • Essentiële hardware opsporen: Toegang krijgen tot het lokale netwerk of multicast gebruiken om specifieke, gerelateerde hardware te vinden die essentieel is voor de werking van de app (bijvoorbeeld een videobewerkingsapp die netwerkopslag lokaliseert).

Niet toegestaan

  • De gebruiker verrassen: Netwerktoegang implementeren die niet duidelijk gerechtvaardigd is door de primaire functionaliteit van de app, zoals een tekstverwerker die communiceert met lokale netwerkapparaten.
  • Willekeurig netwerken scannen: Het uitvoeren van brede scans van het lokale netwerk van de gebruiker (bijvoorbeeld poortscanning van 192.168.1.0/24) om een ​​profiel van de gebruiker op te stellen of ongerelateerde apparaten te ontdekken.
  • Aanvallen op lokale apparaten: Het is ten strengste verboden om andere apparaten op het lokale netwerk te onderzoeken, te herconfigureren of aan te vallen.

Controlled Frame API

Het <controlledframe> -element maakt het mogelijk om content van een andere oorsprong in te sluiten en te wijzigen, inclusief het injecteren van scripts en het aanpassen van headers.

Toegestaan

  • Stroomlijning van gebruikersinterfaces: het integreren van een externe service en het injecteren van CSS om irrelevante UI-elementen te verbergen of een meer samenhangende ervaring te bieden.
  • Bemiddelen in veilige communicatie: fungeren als poortwachter door verzoeken van de ingesloten pagina te ontvangen met postMessage en alleen gezuiverde, noodzakelijke gegevens terug te sturen die via bevoegde API's zijn opgehaald.

Niet toegestaan

  • Het stelen van gebruikersgegevens: het injecteren van scripts om wachtwoorden, sessiecookies of andere gevoelige gebruikersgegevens uit de ingesloten inhoud te bemachtigen.
  • Schending van de servicevoorwaarden: Het wijzigen van ingebedde platforms op manieren die in strijd zijn met hun servicevoorwaarden, zoals programmatisch klikken op advertenties of ongeautoriseerd scrapen.
  • Proxytoegang met bevoorrechte toegang: Het creëren van een doorgeefluik dat onbetrouwbare, ingebedde inhoud directe of ongecontroleerde toegang geeft tot een bevoorrechte IWA API.
  • Het implementeren van ongecontroleerde AI: het uitvoeren van acties namens een ingelogde gebruiker via AI zonder specifieke, transparante gebruiksbeperkingen.

Onbeperkte schermopname

Maakt schermopnamen mogelijk zonder de herhaalde toestemmingsverzoeken die je op standaardwebsites ziet.

Toegestaan

  • Het bieden van essentiële functionaliteit: het gebruik van schermopname als een duidelijk onderdeel van de app, bijvoorbeeld bij het opnemen van virtuele vergaderingen of tutorials.
  • Gebruikers informeren: Gebruikers duidelijk laten weten dat er mogelijk opnames worden gemaakt voordat ze de applicatie gebruiken.

Niet toegestaan

  • Heimelijk opnemen: Het vastleggen van het scherm van de gebruiker zonder diens uitdrukkelijke, voorafgaande kennis en toestemming.
  • Schending van privacyregelgeving: Het verrichten van opnamepraktijken die in strijd zijn met lokale of internationale privacywetten.

Onbeperkte WebUSB

Unrestricted WebUSB omzeilt de standaard WebUSB-blokkeerlijst, waardoor interactie op laag niveau met apparaten mogelijk is.

Toegestaan

  • Ondersteuning van eigen hardware: Interactie met gespecialiseerde of verouderde hardware waarvoor geen web-API op hoog niveau bestaat, zoals industriële controllers.

Nu toegestaan

Vensterbeheer ( window.open en window.focus )

IWA's kunnen pop-ups en focusvensters creëren zonder de gebruikershandeling die bij standaardwebapplicaties vereist is.

Toegestaan

  • Melding bij voltooiing van een taak: Het app-venster wordt gefocust wanneer een kritieke, door de gebruiker gestarte achtergrondtaak, zoals het renderen van een video, is voltooid.

Niet toegestaan

  • Spammen: De gebruiker overladen met meerdere ongevraagde vensters.
  • Phishing: Het openen van vensters die zijn ontworpen om systeemdialoogvensters na te bootsen of de gebruiker te misleiden.
  • Focus-stealing: De gebruiker storen door de focus van andere applicaties af te pakken voor niet-kritieke gebeurtenissen.

Conclusie

De beveiligingsarchitectuur van Isolated Web Apps is ontworpen om ontwikkelaars te ondersteunen en tegelijkertijd een betrouwbare omgeving voor gebruikers te garanderen. Door deze richtlijnen te volgen, zorgt u ervoor dat uw applicatie een verantwoordelijke deelnemer blijft aan het IWA-ecosysteem. De belangrijkste punten uit deze handleiding zijn:

  • Geef prioriteit aan transparantie: het gedrag van uw applicatie moet altijd overeenkomen met het beoogde doel; implementeer nooit functionaliteit die de gebruiker zou verrassen of misleiden.
  • Integriteit van het pakket afdwingen: Alle uitvoerbare logica moet zich binnen uw IWA-bundel bevinden om statische verificatie mogelijk te maken. Het omzeilen van het beveiligingsmodel door middel van dynamische code-sideloading of externe interpreters is ten strengste verboden.
  • Houd je aan het principe van minimale bevoegdheden: kies altijd de API met de minste beperkingen die beschikbaar is voor een bepaalde taak. Bevoorrechte IWA API's mogen alleen worden gebruikt wanneer standaard web-API's niet volstaan ​​voor de kernfunctionaliteit van de applicatie.
  • Fungeer als poortwachter: Bij gebruik van krachtige tools zoals <controlledframe> moet uw IWA fungeren als een veilige bemiddelaar in plaats van een transparante proxy voor onbetrouwbare inhoud.

Voordat u uw IWA publiceert, voert u een laatste controle van uw implementatie uit door de volgende vragen te stellen:

  1. Gebruik ik voor deze taak de eenvoudigste en meest beperkte API die mogelijk is?
  2. Zou een gebruiker verrast of zich verraden voelen door wat mijn app doet?

Als het antwoord op de eerste vraag "Nee" is of op de tweede "Ja", dan is uw aanvraag waarschijnlijk in strijd met het IWA-beveiligingsbeleid en kan deze worden verwijderd.