Sprawdzone procedury zabezpieczeń przeznaczone dla programistów

Adobe AIR 1.0 i wersje późniejsze

Aplikacje AIR są tworzone przy wykorzystaniu technologii sieci Web, ale bardzo ważne jest, aby programiści pamiętali o tym, że nie pracują w obszarze izolowanym przeglądarki. Oznacza to, że możliwe jest tworzenie aplikacji AIR, które nie będą uszkadzały systemu lokalnego celowo lub przypadkowo. Środowisko AIR podejmuje próby zminimalizowania ryzyka, ale istnieją nadal sposoby osłabienia zabezpieczeń. W niniejszym temacie omówiono potencjalne słabe punkty zabezpieczeń.

Ryzyko w przypadku importowania plików do obszaru izolowanego aplikacji

Pliki, które istnieją w katalogu aplikacji, są przypisane do obszaru izolowanego aplikacji i mają pełne uprawnienia w środowisku wykonawczym. W przypadku aplikacji, które zapisują w lokalnym systemie plików, zalecany jest zapis zgodnie ze schematem app-storage:/. Katalog istnieje osobno od plików aplikacji na komputerze użytkownika — dlatego pliki nie są przypisane do obszaru izolowanego aplikacji i stanowią mniejsze zagrożenie. Programiści powinni rozważyć następujące zagadnienia:

  • Do pliku AIR (w zainstalowanej aplikacji) można dołączyć plik tylko w razie potrzeby.

  • Do pliku AIR (w zainstalowanej aplikacji) można dołączyć plik skryptowy tylko wówczas, gdy jego działanie jest w pełni zrozumiałe i jest to plik zaufany.

  • Nie należy zapisywać ani modyfikować treści w katalogu aplikacji. Środowisko wykonawcze uniemożliwia aplikacjom zapisywanie i modyfikowanie plików i katalogów za pomocą schematu URL app:/, ponieważ wywołuje wyjątek SecurityError.

  • Danych ze źródeł sieciowych nie należy używać w roli parametrów metod interfejsów API AIR, które mogą powodować wykonanie kodu. Obejmuje to użycie metody Loader.loadBytes() i funkcji eval() JavaScript.

Zagrożenia związane z korzystaniem ze źródeł zewnętrznych w celu określenia ścieżek

Działanie aplikacji AIR może zostać zakłócone podczas korzystania z danych lub treści zewnętrznej. Z tego powodu należy zachować szczególną ostrożność podczas korzystania z danych z sieci lub systemu plików. Określenie obiektu jako zaufanego zależy od programisty i połączeń sieciowych, jakie nawiązuje obiekt, ale ładowanie danych obcych jest ryzykowne i nie powinno być używane w przypadku wprowadzania danych do wrażliwych operacji. Programistom nie zaleca się:

  • Korzystania z danych pochodzących ze źródeł sieciowych w celu określania nazw plików

  • Korzystania z danych pochodzących ze źródeł sieciowych w celu konstruowania adresów URL, z których korzysta aplikacja w celu wysyłania informacji prywatnych

Ryzyko związane z użyciem, zapisywaniem i przesyłaniem niebezpiecznych poświadczeń

Zapisywanie poświadczeń użytkowników w lokalnym systemie plików wiąże się z zagrożeniem modyfikacji tych danych. Programiści powinni rozważyć następujące zagadnienia:

  • Jeśli konieczne jest lokalne zapisywanie poświadczeń, należy zaszyfrować te dane podczas zapisywania w lokalnym systemie plików. Środowisko wykonawcze udostępnia funkcję szyfrowania podczas zapisu unikalną dla każdej zainstalowanej aplikacji, za pośrednictwem klasy EncryptedLocalStore. Szczegółowe informacje zawiera sekcja Zaszyfrowany magazyn lokalny.

  • Nie należy przesyłać niezaszyfrowanych poświadczeń użytkownika do źródła sieciowego, chyba że jest to źródło zaufane.

  • Nigdy nie należy określać hasła domyślnego podczas tworzenia poświadczeń — użytkownicy powinni definiować własne hasła. Użytkownicy, którzy pozostawią niezmienione wartości domyślne, narażają swoje poświadczenia na wykorzystanie przez agresora, który mógł wcześniej poznać hasło domyślne.

Ryzyko ataku na skutek zamiany wersji na starszą

Podczas instalowania aplikacji środowisko wykonawcze sprawdza, czy konkretna wersja aplikacji nie jest już zainstalowana. Jeśli aplikacja jest już zainstalowana, środowisko wykonawcze porównuje ciąg znaków wersji z instalowaną wersją. Jeśli ciąg znaków jest inny, użytkownik może wybrać zaktualizowanie instalacji. Środowisko wykonawcze nie gwarantuje, że nowo zainstalowana wersja będzie nowsza od starszej wersji — jest to po prostu inna wersja. Agresor może dystrybuować starszą wersję w celu wykorzystania słabego punktu zabezpieczeń. Z tego powodu programista powinien sprawdzać wersje podczas uruchamiania aplikacji. Dobrym rozwiązaniem jest, gdy aplikacja sprawdza dostępność aktualizacji w sieci. Dzięki temu, gdy agresor spowoduje uruchomienie starej wersji, stara wersja rozpozna, że musi zostać zaktualizowana. Ponadto zastosowanie jasnego schematu wersji aplikacji utrudni oszukanie użytkowników w taki sposób, aby zainstalowali starszą wersję.