Zasady dla deweloperów i wskazówki dotyczące bezpieczeństwa

Simon Hangl

Demián Renzulli

Izolowane aplikacje internetowe zapewniają model zabezpieczeń, który umożliwia aplikacjom internetowym dostęp do zaawansowanych funkcji, takich jak Direct Sockets i Controlled Frame, które są zwykle ograniczone w standardowej sieci „drive-by”. Ponieważ IWAs działają w środowisku o wysokim poziomie zaufania, muszą przestrzegać rygorystycznych zasad bezpieczeństwa i prywatności. Te wytyczne mają na celu zapewnienie, że w miarę jak platforma internetowa zyskuje coraz większe możliwości, użytkownicy pozostają bezpieczni, a integralność środowiska przeglądarki jest zachowana.

Model zaufania IWA

Podstawą platformy IWA są ścisłe zasady techniczne, które zmuszają deweloperów do utrzymywania wysokiego poziomu bezpieczeństwa. Standardowe aplikacje internetowe korzystają z elastycznego modelu uprawnień, a izolowane aplikacje internetowe są podpisane kryptograficznie i dostarczane za pomocą pakietów internetowych, co umożliwia weryfikację ich pochodzenia i integralności.

W zamian za potwierdzoną tożsamość IWA zyskują dostęp do interfejsów API z uprawnieniami. Aby utrzymać to zaufanie, deweloperzy muszą stosować podejście oparte na bezpieczeństwie i przestrzegać bardziej rygorystycznych zasad, w tym solidnej polityki bezpieczeństwa treści (CSP) i zaufanych typów, które zapewniają bezpieczeństwo użytkowników nawet podczas korzystania z zaawansowanych funkcji. Oznacza to, że:

• Przejrzystość: użytkownicy nie powinni być zaskoczeni sposobem, w jaki aplikacja korzysta z interfejsów API z uprawnieniami.
• Minimalny zakres uprawnień: aplikacje powinny prosić tylko o konkretne funkcje wymagane do realizacji ich deklarowanego celu i z nich korzystać.
• Statyczna integralność: cała logika wykonywalna musi być zawarta w pakiecie aplikacji, aby umożliwić audyt bezpieczeństwa i zapobiec instalowaniu z pominięciem sklepu złośliwego kodu.

Chociaż IWA zawierają solidne wbudowane zabezpieczenia, takie jak ścisłe przestrzeganie standardu Content Security Policy (CSP), który zapobiega wykonywaniu skryptów zewnętrznych, same ograniczenia techniczne nie mogą wyeliminować każdego ryzyka. Nawet w środowisku o wysokim poziomie zaufania niektóre wzorce implementacji lub wybory deweloperów mogą nieumyślnie naruszać bezpieczeństwo lub prywatność użytkowników. W tym przewodniku opisujemy te ograniczone scenariusze i zasady regulujące korzystanie z interfejsów API z uprawnieniami.

Dlaczego te wytyczne są ważne

Przestrzeganie tych zasad to nie tylko kwestia zgodności z przepisami, ale też budowanie zrównoważonego ekosystemu zaawansowanych aplikacji internetowych. Postępując zgodnie z tymi wytycznymi, masz pewność, że Twoja aplikacja:

• Zapobiega regresji zabezpieczeń: chroni przed lukami w zabezpieczeniach, takimi jak ataki typu cross-site scripting (XSS) i zdalne wykonywanie kodu, dzięki temu, że logika jest samodzielna.
• Ochrona prywatności użytkownika: zapewnia, że dane wrażliwe i dostęp do sprzętu są obsługiwane tylko wtedy, gdy użytkownik wyraźnie tego chce i gdy jest to przejrzyste.
• Zapewnia długotrwałe działanie platformy: pomaga utrzymać wysokie standardy bezpieczeństwa wymagane, aby platforma IWA mogła dalej rozwijać swoje możliwości.

Podstawowe zasady

Przejrzystość i zamiary użytkowników

Najważniejsza zasada to: nie zaskakuj użytkownika. Działanie aplikacji musi być zgodne z jej deklarowanym przeznaczeniem i oczekiwaniami użytkowników.

• Nie wykraczaj poza zakres: nie wdrażaj funkcji, które wykraczają poza wyraźne przeznaczenie aplikacji.
• Minimalny rozmiar interfejsu API: proś tylko o konkretny zestaw interfejsów IWA API niezbędnych do realizacji podstawowej funkcji aplikacji i używaj tylko tych interfejsów.

Brak wczytywania kodu dynamicznego z boku

Model zabezpieczeń IWA zależy od możliwości weryfikacji całej logiki wykonywalnej przez administratorów lub dostawcę przeglądarki. W związku z tym pakiet izolowanej aplikacji internetowej musi być samodzielny. Platforma egzekwuje to za pomocą ścisłych zasad bezpieczeństwa treści (CSP), które blokują wykonywanie oparte na ciągach znaków, np. eval() i new Function():

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

Chociaż zasady CSP umożliwiają 'wasm-unsafe-eval' obsługę WebAssembly, nie wolno Ci naruszać ducha tego zabezpieczenia.

Praktyki ściśle zabronione

• Dostarczanie interpreterów do kodu zdalnego: nie możesz dołączać interpretera kodu (np. Pythona lub Lua skompilowanego do WASM) do pobierania i wykonywania skryptów zewnętrznych przy użyciu uprzywilejowanego dostępu do sieci, takiego jak bezpośrednie gniazda.
• Logika ładowana zdalnie: nie używaj service workerów do osadzania kodu ładowanego zdalnie w źródle IWA.
• Kod a dane: pobieranie danych (np. w formacie JSON) jest dozwolone, ale pobieranie kodu przeznaczonego do interpretacji lub uruchomienia jest bezpośrednim naruszeniem zasad.

Zasada jak najmniejszych uprawnień

Zawsze używaj najmniej zaawansowanego interfejsu API, który jest w stanie wykonać zadanie. Uprzywilejowanych interfejsów API specyficznych dla IWA nie należy nigdy używać jako skrótu do omijania ograniczeń bezpieczeństwa ani monitów dla użytkowników standardowych interfejsów API sieci. Poniższa tabela zawiera typowe przypadki użycia, które pomogą Ci zdecydować, kiedy używać tradycyjnych interfejsów Web API, a kiedy funkcji specyficznych dla IWA:

Wytyczne dotyczące interfejsu API

Interfejsy API aplikacji IWA oferują zaawansowane funkcje, które są zwykle ograniczone w przeglądarce. Ogólna zasada jest taka, aby nigdy nie używać tych funkcji w sposób, który zaskoczyłby użytkowników lub naruszył ich zaufanie i bezpieczeństwo danych.

Direct Sockets API

Interfejs Direct Sockets API zapewnia nieprzetworzony dostęp do protokołów TCP i UDP, w tym dostęp do multiemisji i sieci lokalnej.

Dozwolone

• Obsługa protokołów niestandardowych: łączenie się z serwerami zdalnymi, które używają protokołów niestandardowych, dla których nie ma obecnie interfejsu Web API wyższego poziomu.
• Utrzymywanie usług backendu: łączenie się z wstępnie zdefiniowanym, zakodowanym na stałe serwerem używanym specjalnie na potrzeby usług backendu aplikacji.
• Wykrywanie niezbędnego sprzętu: dostęp do sieci lokalnej lub korzystanie z multicastu w celu wykrywania konkretnego, powiązanego sprzętu niezbędnego do działania aplikacji (np. aplikacja do edycji wideo lokalizująca pamięć masową podłączoną do sieci).

Niedozwolone

• Zaskakiwanie użytkownika: wdrażanie dostępu do sieci, który nie jest wyraźnie uzasadniony podstawową funkcjonalnością aplikacji, np. edytor tekstu komunikujący się z urządzeniami w sieci lokalnej.
• Skanowanie sieci w sposób dowolny: przeprowadzanie szerokich skanów lokalnej sieci użytkownika (np. skanowanie portów 192.168.1.0/24) w celu utworzenia profilu użytkownika lub wykrycia niezwiązanych urządzeń.
• Kierowanie na urządzenia lokalne: próby sondowania, ponownej konfiguracji lub atakowania innych urządzeń w sieci lokalnej są surowo zabronione.

Controlled Frame API

Element <controlledframe> umożliwia osadzanie i modyfikowanie treści z innych domen, w tym wstawianie skryptów i modyfikowanie nagłówków.

Dozwolone

• Usprawnianie interfejsów: osadzanie usługi innej firmy i wstrzykiwanie kodu CSS w celu ukrycia nieistotnych elementów interfejsu lub zapewnienia bardziej spójnego działania.
• Pośredniczenie w bezpiecznej komunikacji: pełnienie roli strażnika poprzez odbieranie żądań ze strony osadzonej z postMessage i zwracanie tylko oczyszczonych, niezbędnych danych pobranych za pomocą uprzywilejowanych interfejsów API.

Niedozwolone

• Kradzież danych logowania użytkownika: wstrzykiwanie skryptów w celu przechwytywania haseł, plików cookie sesji lub innych poufnych danych użytkownika z osadzonych treści.
• Naruszenie warunków korzystania z usługi: modyfikowanie platform zintegrowanych w sposób, który narusza ich warunki korzystania z usługi, np. automatyczne klikanie reklam lub nieautoryzowane pobieranie danych.
• Przekazywanie dostępu uprzywilejowanego: tworzenie przekazywania, które zapewnia niezaufanym, osadzonym treściom bezpośredni lub niekontrolowany dostęp do uprzywilejowanego interfejsu API izolowanej aplikacji internetowej.
• Wdrażanie niekontrolowanej AI: wykonywanie działań w imieniu zalogowanego użytkownika za pomocą AI bez konkretnych, przejrzystych ograniczeń dotyczących przypadków użycia.

Nieograniczone nagrywanie ekranu

Umożliwia zrobienie zrzutu ekranu bez powtarzających się próśb o zezwolenie użytkownika, które występują w standardowej sieci.

Dozwolone

• Zapewnianie głównej funkcjonalności: używanie funkcji przechwytywania ekranu jako oczywistej części usługi aplikacji, np. w przypadku funkcji nagrywania spotkań wirtualnych lub samouczków.
• Zapewnienie świadomości użytkownika: przed rozpoczęciem korzystania z aplikacji należy wyraźnie poinformować użytkowników, że nagrywanie może mieć miejsce.

Niedozwolone

• Nagrywanie potajemne: rejestrowanie ekranu użytkownika bez jego wyraźnej, uprzedniej wiedzy i zgody.
• Naruszenie przepisów dotyczących prywatności: stosowanie praktyk nagrywania, które naruszają lokalne lub międzynarodowe przepisy dotyczące prywatności.

Nieograniczony WebUSB

Nieograniczony WebUSB pomija standardową listę zablokowanych WebUSB, aby umożliwić interakcję z urządzeniami na niskim poziomie.

Dozwolone

• Obsługa sprzętu własnościowego: interakcja ze specjalistycznym lub starszym sprzętem, dla którego nie ma interfejsu API wysokiego poziomu, np. ze sterownikami przemysłowymi.

Dozwolone

• Omijanie dedykowanych interfejsów API: używanie WebUSB w przypadku urządzeń, które mają bardziej szczegółowy, ograniczony interfejs API, np. kart inteligentnych (używaj interfejsu Smart Card API) lub pamięci zewnętrznej (używaj interfejsu File System Access API).

Zarządzanie oknami (window.open i window.focus)

IWAs mogą tworzyć wyskakujące okienka i okna z fokusem bez gestu użytkownika wymaganego przez standardową sieć.

Dozwolone

• Powiadamianie o zakończeniu zadania: skupianie okna aplikacji po zakończeniu ważnego zadania w tle zainicjowanego przez użytkownika, np. renderowania filmu.

Niedozwolone

• Spamowanie: zalewanie użytkownika wieloma niechcianymi oknami.
• Phishing: otwieranie okien zaprojektowanych tak, aby naśladowały okna dialogowe systemu lub wprowadzały użytkownika w błąd.
• Przejmowanie fokusu: zakłócanie pracy użytkownika przez przejmowanie fokusu z innych aplikacji w przypadku zdarzeń, które nie są krytyczne.

Podsumowanie

Architektura zabezpieczeń izolowanych aplikacji internetowych została zaprojektowana tak, aby zapewnić deweloperom większe możliwości, a użytkownikom – środowisko o wysokim poziomie zaufania. Przestrzegając tych wytycznych, masz pewność, że Twoja aplikacja będzie odpowiedzialnym elementem ekosystemu IWA. Najważniejsze informacje z tego przewodnika:

• Stawiaj na przejrzystość: działanie aplikacji powinno zawsze być zgodne z jej deklarowanym przeznaczeniem. Nie należy wdrażać funkcji, które mogłyby zaskoczyć lub zawieść użytkownika.
• Wymuszanie integralności pakietu: cała logika wykonywalna musi być zawarta w pakiecie IWA, aby umożliwić weryfikację statyczną. Omijanie modelu zabezpieczeń przez wczytywanie kodu dynamicznego lub zdalne interpretery jest surowo zabronione.
• Przestrzegaj zasady najmniejszych uprawnień: zawsze wybieraj najbardziej ograniczony interfejs API dostępny dla danego zadania. Uprzywilejowanych interfejsów API IWA należy używać tylko wtedy, gdy standardowe interfejsy Web API są niewystarczające do działania kluczowej funkcji aplikacji.
• Pełnienie roli strażnika: podczas korzystania z zaawansowanych narzędzi, takich jak <controlledframe>, Twoja IWA musi pełnić rolę bezpiecznego pośrednika, a nie przezroczystego serwera proxy w przypadku niezaufanych treści.

Przed opublikowaniem IWA przeprowadź ostateczny audyt implementacji, zadając sobie te pytania:

1. Czy do tego zadania używam najprostszego i najbardziej ograniczonego interfejsu API?
2. Czy użytkownik będzie zaskoczony lub poczuje się oszukany przez to, co robi moja aplikacja?

Jeśli odpowiedź na pierwsze pytanie brzmi „Nie”, a na drugie „Tak”, Twoja aplikacja prawdopodobnie narusza zasady bezpieczeństwa IWA i może zostać usunięta.