Treść odwołująca się do skryptów w różnych bezpiecznych obszarach izolowanych

Adobe AIR 1.0 i starsze wersje

Model zabezpieczeń środowiska wykonawczego izoluje kod o różnym pochodzeniu. Dzięki treści odwołującej się do skryptów w różnych bezpiecznych obszarach izolowanych programista może zezwolić treści z jednego bezpiecznego obszaru izolowanego na dostęp do wybranych właściwości i metod z innego obszaru izolowanego.

Bezpieczne obszary izolowane środowiska AIR i kod JavaScript

Środowisko AIR wymusza regułę tego samego pochodzenia, która zapobiega interakcji kodu z jednej domeny z treścią innej domeny. Wszystkie pliki umieszczane są w obszarze izolowanym w oparciu o ich pochodzenie. Treść z obszaru izolowanego aplikacji nie może naruszyć zasady tego samego pochodzenia ani treść odwołująca się do skryptów załadowana spoza katalogu instalacyjnego aplikacji. Jednak środowisko AIR zapewnia kilka technik, które umożliwiają użycie nieaplikacyjnej treści odwołującej się do skryptów.

Jedna technika korzysta z ramek lub ramek pływających, aby odwzorować treść aplikacji na inny obszar izolowany zabezpieczeń. Wszystkie strony załadowane z obszaru izolowanego aplikacji działają tak, jakby zostały załadowane ze zdalnej domeny. Na przykład: dzięki odwzorowaniu treści aplikacji na domenę example.com treść może odwoływać się do skryptów ze stron załadowanych z domeny example.com.

Ponieważ ta technika umieszcza treść aplikacji w innym obszarze izolowanym, kod w tej treści również nie jest dłużej przedmiotem ograniczeń wykonania kodu w ciągach znaków, dla których wyznaczana jest wartość. Tej techniki odwzorowywania obszaru izolowanego można używać do złagodzenia ograniczeń nawet, jeśli nie jest wymagane odwoływanie się do skryptów zdalnej treści. Odwzorowanie treści w ten sposób możne być szczególnie użyteczne podczas pracy z jednym z wielu środowisk JavaScript lub istniejącym kodem, który opiera się na obliczaniu wartości dla ciągów. Należy jednak uwzględnić i zabezpieczyć się przed dodatkowym ryzykiem związanym z niezaufaną treścią, która może zostać wstrzyknięta i wykonana, gdy treść uruchamiana jest poza obszarem izolowanym aplikacji.

W tym samym czasie treść odwzorowana na inny obszar izolowany traci dostęp do interfejsu API środowiska AIR, dlatego technika odwzorowywania obszaru izolowanego nie może być używana do udostępniania funkcjonalności środowiska AIR dla kodu wykonywanego poza obszarem izolowanym aplikacji.

Inna technika odwoływania się do skryptu umożliwia tworzenie interfejsu nazywanego mostem obszaru izolowanego między treścią z nieaplikacyjnego obszaru izolowanego a jego dokumentem nadrzędnym w obszarze izolowanym aplikacji. Most umożliwia treści dokumentu podrzędnego na dostęp do właściwości i metod zdefiniowanych przez dokument nadrzędny, dostęp dokumentu nadrzędnego do właściwości i metod zdefiniowanych przez dokument podrzędny lub obie możliwości.

W końcu możliwe jest również wykonanie międzydomenowych żądań XMLHttpRequest z obszaru izolowanego aplikacji i (opcjonalnie) z innych obszarów izolowanych.

Więcej informacji zawiera sekcja Elementy ramek i ramek pływających HTML , Zabezpieczenia HTML w środowisku Adobe AIR i Obiekt XMLHttpRequest .

Wczytywanie zawartości aplikacji do obszaru izolowanego niezwiązanego z aplikacjami

Aby umożliwić treści aplikacji bezpieczne odwoływanie się do skryptów treści załadowanej spoza katalogu instalacyjnego aplikacji, można użyć elementów frame lub iframe w celu załadowania treści aplikacji do tego samego obszaru izolowanego zabezpieczeń co zewnętrzna treść. Jeśli odwoływanie się do skryptów zdalnej treści nie jest konieczne, ale nadal istnieje potrzeba ładowania strony aplikacji spoza obszaru izolowanego aplikacji, można użyć tej samej techniki, określając jako domenę początkową http://localhost/ lub inną bezpieczną wartość.

Środowisko AIR dodaje nowe atrybuty sandboxRoot i documentRoot do elementu ramki, które umożliwiają określanie, czy plik aplikacji załadowany do ramki powinien być odwzorowywany w nieaplikacyjnym obszarze izolowanym. Pliki, których ścieżka wskaże adres poniżej adresu URL sandboxRoot załadowane zostaną z katalogu określonego w atrybucie documentRoot . Ze względów bezpieczeństwa treść aplikacji załadowana w ten sposób traktowana jest tak, jakby rzeczywiście została załadowana z adresu URL określonego we właściwości sandboxRoot .

Właściwość sandboxRoot określa adres URL w celu użycia do określania obszaru izolowanego i domeny, w której umieszczana jest treść ramki. Należy użyć schematów URL: file: , http: lub https: . Jeśli określony zostanie względny adres URL, treść pozostanie w obszarze izolowanym aplikacji.

Właściwość documentRoot określa katalog, z którego ładowana jest treść ramki. Należy użyć schematów URL: file: , app: lub app-storage: .

Poniższy przykład odwzorowuje treść zainstalowaną w podkatalogu sandbox aplikacji w celu uruchomienia w zdalnym obszarze izolowanym oraz domenie www.example.com :

<iframe 
    src="http://www.example.com/local/ui.html"  
    sandboxRoot="http://www.example.com/local/"  
    documentRoot="app:/sandbox/"> 
</iframe>

Strona ui.html może załadować plik javascript z lokalnego folderu sandbox za pomocą następujących znaczników script:

<script src="http://www.example.com/local/ui.js"></script>

Może załadować także treść z katalogu na zdalnym serwerze za pomocą znacznika script, co ilustruje poniższy przykład:

<script src="http://www.example.com/remote/remote.js"></script>

Adres URL określony we właściwości sandboxRoot będzie maskował każdą treść dla tego samego adresu URL na zdalnym serwerze. W powyższym przykładzie nie jest możliwy dostęp do żadnej zdalnej treści na stronie www.example.com/local/ (ani do żadnego jej podkatalogu), ponieważ środowisko AIR ponownie odwzorowuje żądanie na lokalny katalog aplikacji. Żądania są ponownie odwzorowywane niezależnie od tego czy kierowane są z elementów nawigacji strony (XMLHttpRequest) czy zostały utworzone przez inne środki ładowania treści.

Konfigurowanie interfejsu mostu obszaru izolowanego

Mostu obszaru izolowanego można używać, gdy treść w obszarze izolowanym aplikacji musi mieć dostęp do właściwości lub metod zdefiniowanych przez treść w nieaplikacyjnym obszarze izolowanym lub gdy nieaplikacyjna treść musi mieć dostęp do właściwości i metod zdefiniowanych przez treść w obszarze izolowanym aplikacji. Most należy utworzyć z właściwościami childSandboxBridge i parentSandboxBridge obiektu window dla każdego dokumentu podrzędnego.

Tworzenie mostu obszaru izolowanego elementu podrzędnego

Właściwość childSandboxBridge umożliwia podrzędnemu dokumentowi udostępnianie interfejsu dla treści w dokumencie nadrzędnym. Aby udostępnić interfejs, należy ustawić właściwość childSandbox na funkcję lub obiekt w dokumencie podrzędnym. Programista może następnie uzyskać dostęp do obiektu lub funkcji z treści dokumentu nadrzędnego. Poniższy przykład przedstawia, w jaki sposób skrypt uruchomiony w dokumencie podrzędnym może udostępniać obiekt zawierający funkcję i właściwość swojemu dokumentowi nadrzędnemu:

var interface = {}; 
interface.calculatePrice = function(){ 
    return ".45 cents"; 
} 
interface.storeID = "abc" 
window.childSandboxBridge = interface;

Jeśli treść dokumentu podrzędnego załadowana została do ramki pływającej, do której przypisany został identyfikator „child”, dostęp do interfejsu można uzyskać z treści elementu nadrzędnego, odczytując właściwość childSandboxBridge ramki:

var childInterface = document.getElementById("child").contentWindow.childSandboxBridge; 
air.trace(childInterface.calculatePrice()); //traces ".45 cents" 
air.trace(childInterface.storeID)); //traces "abc"

Tworzenie mostu obszaru izolowanego elementu nadrzędnego

Właściwość parentSandboxBridge umożliwia nadrzędnemu dokumentowi udostępnianie interfejsu dla treści w dokumencie podrzędnym. Aby udostępnić interfejs, dokument nadrzędny ustawia właściwość parentSandbox dokumentu podrzędnego na funkcję lub obiekt zdefiniowany w dokumencie nadrzędnym. Programista może następnie uzyskać dostęp do obiektu lub funkcji z treści dokumentu podrzędnego. Poniższy przykład przedstawia, w jaki sposób skrypt uruchomiony w ramce nadrzędnej może udostępniać obiekt zawierający funkcję dokumentowi podrzędnemu:

var interface = {}; 
interface.save = function(text){ 
    var saveFile = air.File("app-storage:/save.txt"); 
    //write text to file 
} 
document.getElementById("child").contentWindow.parentSandboxBridge = interface;

Za pomocą tego interfejsu treść w ramce podrzędnej może zapisać tekst do pliku o nazwie save.txt , ale nie będzie miała żadnego innego rodzaju dostępu do systemu plików. Treść elementu podrzędnego może wywołać funkcję save w następujący sposób:

var textToSave = "A string."; 
window.parentSandboxBridge.save(textToSave);

Treść aplikacji powinna udostępniać innym obszarom izolowanym najwęższy możliwy interfejs. Nieaplikacyjna treść powinna być rozważana jako niegodna zaufania, ponieważ może być narażona na wprowadzenie przypadkowego lub złośliwego kodu. Należy przydzielić odpowiednie zabezpieczenia, aby zapobiec niewłaściwemu użyciu interfejsu udostępnionego za pomocą mostu obszaru izolowanego.

Dostęp do mostu obszaru izolowanego elementu nadrzędnego podczas ładowania strony

Aby skrypt w dokumencie podrzędnym uzyskał dostęp do mostu obszaru izolowanego dokumentu nadrzędnego, most musi zostać skonfigurowany przed uruchomieniem skryptu. Obiekty okna, ramki i ramki pływającej wywołują zdarzenie dominitialize , gdy utworzony zostanie model DOM nowej strony, ale przez przetworzeniem skryptów lub dodaniem elementów DOM. Zdarzenia dominitialize można użyć do utworzenia mostu w sekwencji tworzenia strony dostatecznie wcześnie, aby wszystkie skrypty w dokumencie podrzędnym mogły uzyskać do niego dostęp.

Poniższy przykład ilustruje, w jaki sposób utworzyć most obszaru izolowanego dokumentu nadrzędnego w odpowiedzi na zdarzenie dominitialize wywołane z ramki podrzędnej:

<html> 
<head> 
<script> 
var bridgeInterface = {}; 
bridgeInterface.testProperty = "Bridge engaged"; 
function engageBridge(){ 
    document.getElementById("sandbox").contentWindow.parentSandboxBridge = bridgeInterface; 
} 
</script> 
</head> 
<body> 
<iframe id="sandbox" 
            src="http://www.example.com/air/child.html"  
            documentRoot="app:/" 
            sandboxRoot="http://www.example.com/air/" 
            ondominitialize="engageBridge()"/> 
</body> 
</html>

Poniższy dokument child.html ilustruje, jak zawartość dokumentu podrzędnego może uzyskać dostęp do mostu obszaru izolowanego dokumentu nadrzędnego.

<html> 
    <head> 
        <script> 
            document.write(window.parentSandboxBridge.testProperty); 
        </script>   
    </head>   
    <body></body> 
</html>

Aby wykryć zdarzenie dominitialize podrzędnego okna, a nie ramki, należy dodać detektor do nowego podrzędnego obiektu okna utworzonego za pomocą funkcji window.open() :

var childWindow = window.open(); 
childWindow.addEventListener("dominitialize", engageBridge()); 
childWindow.document.location = "http://www.example.com/air/child.html";

W tym przypadku nie ma możliwości odwzorowania treści aplikacji do nieaplikacyjnego obszaru izolowanego. Ta technika jest użyteczna tylko gdy dokument child.html ładowany jest spoza katalogu aplikacji. Treść aplikacji nadal można odwzorować w oknie na nieaplikacyjny obszar izolowany, ale najpierw należy załadować stronę pośrednią, która sama używa ramek, aby załadować dokument podrzędny i odwzorować go na pożądany obszar izolowany.

Jeśli do tworzenia okna używana jest funkcja createRootWindow() klasy HTMLLoader, nowe okno nie będzie dokumentem podrzędnym dokumentu, z którego wywoływana jest funkcja createRootWindow() . Dlatego nie można utworzyć mostu obszaru izolowanego z okna wywołującego do treści nieaplikacyjnej załadowanej do nowego okna. Zamiast tego należy użyć ładowania strony pośredniej w nowym oknie, które samo korzysta z ramek do ładowania dokumentu podrzędnego. Most można utworzyć z dokumentu nadrzędnego nowego okna do dokumentu podrzędnego załadowanego do ramki.