Najlepsze praktyki w zakresie bezpieczeństwa aplikacji iOS

Myśląc o bezpieczeństwie aplikacji iPhone/iPad, mogę zauważyć, że jest:

  • powszechnie dostępne narzędzia hakerskie umożliwiają dostęp do systemu plików
  • przechwycenie sieci, atak mężczyzn w środku

= = > zagrożenie kradzieżą danych

A także:

    [3]}dostępność narzędzi hakerskich, które pozwalają na swobodne dzielenie się płatną aplikacją ze znajomymi/społecznością (widoczne w Cydii)
  • dostępność narzędzi hakerskich, które pozwalają na zakup aplikacji bez płacenia (widać w Cydii i słyszałem, że nie działa z żadną aplikacją)

= = > Zagrożenie stratą przychodów

Więc zastanawiam się #1 jakie są najlepsze praktyki, aby uzyskać lepsze bezpieczeństwo w aplikacji iOS? Ponadto, #2 jakie są najlepsze sposoby na zmniejszenie strat przychodów i zminimalizowanie narażenia hakerów?

Dla #1 Widziałem kilka slajdów WWDC o bezpieczeństwie 1 2 3 4 + Apple docs

I mogę powiedzieć, że między tezami najlepsze praktyki są:

  • używanie API oferujących ochronę danych (jak NSFileManager z atrybutem NSFileProtectionKey)
  • Używanie Pęku Kluczy
  • ochrona poufnych danych za pomocą protokołu SSL i przy użyciu certyfikatów

Dla # 2 Myślę, że korzystanie z modelu biznesowego opartego na darmowej aplikacji, a następnie w zakupie aplikacji z weryfikacją paragonów sklepowych może być modelem z minimalną stratą przychodów.

Jakie są Twoje najlepsze praktyki w zakresie bezpieczeństwa i najlepszy sposób na zminimalizowanie aplikacji szanse na włamanie?

Author: AmineG, 2012-02-26

4 answers

# 1 Jakie są najlepsze praktyki, aby uzyskać lepsze bezpieczeństwo w aplikacji iOS?

Odpowiednie bezpieczeństwo danych w dużym stopniu zależy od charakteru informacji. Długo czy krótko? Czy jest to ogólne poświadczenie, które można wykorzystać do otwierania innych rzeczy, czy pojedynczy fragment danych? Czy potencjalna strata to prywatność, finanse, czy bezpieczeństwo? Określenie odpowiednich zabezpieczeń wymaga konkretnego przypadku i nie ma ogólnej odpowiedzi. Ale prosisz o najlepsze praktyki i tam jest ich kilka. Żaden z nich nie jest doskonały ani nie do złamania. Ale to najlepsza praktyka. Oto kilka:

  • przechowuj poufne informacje w Pęku Kluczy
  • Ustaw ochronę danych na NSFileProtectionComplete w miarę możliwości.
  • nie przechowuj poufnych danych, których w rzeczywistości nie potrzebujesz lub dłużej niż potrzebujesz.
  • przechowuj tokeny uwierzytelniania specyficzne dla aplikacji, a nie hasła.
  • Użyj HTTPS, aby zweryfikować serwer, z którym się kontaktujesz. Nigdy nie Akceptuj nieprawidłowego lub niezaufanego certyfikat.
  • podczas łączenia się z własnym serwerem sprawdź, czy usługa prezentuje certyfikat, który podpisałeś , a nie tylko "zaufany certyfikat."

To tylko odrobina podejść, ale one wyznaczają podstawowy ton:

  • Użyj wbudowanych interfejsów API do przechowywania rzeczy. Ponieważ Apple poprawia bezpieczeństwo, zyskujesz korzyści za darmo.
  • unikaj przechowywania poufnych informacji i minimalizuj wrażliwość tego, co przechowujesz.
  • zweryfikuj usługi, z którymi się komunikujesz.

# 2 Jakie są najlepsze sposoby na ograniczenie utraty przychodów i zminimalizowanie narażenia na hakowanie?

To było wielokrotnie omawiane na ten temat. Ta odpowiedź zawiera linki do kilku innych dyskusji:

Bezpieczne szyfrowanie https dla iPhone app to webpage

Krótka odpowiedź brzmi: martw się o swoich klientów, A Nie Nie-klientów. Wielu piratów nigdy, przenigdy nie zapłaci Ci pieniędzy, więc twój czas i pieniądze są lepsze spędzone pomagając rzeczywistym klientom chcą Ci płacić, i ułatwiając im to zrobić. Skoncentruj się na zarabianiu więcej pieniędzy, zamiast chronić się przed pieniędzmi, których nigdy nie mógłbyś mieć. Nigdy, przenigdy, nie odczep się od płacącego klienta w swoich wysiłkach, aby ukarać niepłacącego klienta. Zemsta to frajerska gra i marnowanie zasobów.

Istnieją dwa świetne sposoby na uniknięcie piractwa:]}
    Nie publikuj.
  • Publikuj śmieci, których nikt nie chce.

Jest kilka podstawowych rzeczy można to zrobić, warto po prostu, jak mówią, aby uczciwi ludzie byli uczciwi (niektóre są omawiane w różnych powiązanych dyskusjach). Ale nie leżeć nie śpiąc martwiąc się o to, jak udaremnić piratów. Leżeć na jawie martwiąc się o to, jak zadziwić swoich klientów.

I zawsze pamiętaj: Apple wydaje więcej pieniędzy, niż większość z nas kiedykolwiek widział w naszym życiu, próbując zabezpieczyć iPhone. Ale to jailbreak. Pomyśl o tym, co osiągnie Twój budżet.

 65
Author: Rob Napier,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:34:17

Gdy atakujący uzyska fizyczny dostęp do urządzenia( np. kradzież), może zrobić prawie wszystko. Zauważ, że jest bardzo łatwy do odczytania plików aplikacji. Skradzione urządzenie można łatwo jailbroken i atakujący zyskuje dostęp nawet do chronionych plików.

Moja rada dotycząca przechowywania poufnych danych do urządzenia:

  1. nie rób tego, jeśli mogą być przechowywane na bezpiecznym serwerze
  2. użyj własnego szyfrowania, odszyfruj, gdy użytkownik jest zalogowany, Usuń odszyfrowany plik, gdy się wyloguje lub po jakiś czas aplikacja jest w tle.
  3. każde hasło i klucz szyfrowania muszą być przechowywane w pęku kluczy.
 7
Author: Sulthan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-02-25 22:54:57

Rob Napier wspomniał o dobrych punktach. Ale żeby było bezpieczniej,

1 Jakie są najlepsze praktyki, aby uzyskać lepsze bezpieczeństwo w aplikacji iOS?

  1. przechowuj poufne informacje w zaszyfrowanym formacie w Pęku Kluczy.
    • po fizycznym dostępie do pęku kluczy Urządzenia dane mogą być łatwo zrzucane.
  2. ustawić odpowiednią klasę ochrony danych (nsfileprotectioncomplete preferowane).
  3. Zawsze używaj niestandardowego szyfrowania wraz z wbudowanym API do przechowywania data.
    • nawet jeśli hakerzy znajdą luki w wbudowanym API, Twoja aplikacja jest Bezpieczna.
  4. przez zapisanie tymczasowych przechowywanych danych przed usunięciem.
    • techniki kryminalistyczne mogą być wykorzystane do odzyskania usuniętych danych.
  5. Użyj HTTPS i przypinania certyfikatów. Nigdy nie przyjmuj niezaufanych certyfikatów.
  6. przechowywać ważne plist, sqlite, itp... pliki w folderze Biblioteka / pamięć podręczna.
    • Pliki zapisane w folderze caches nie są archiwizowane za pomocą iTunes.
  7. zawsze buduj aplikację z najnowszym XCode.
    • dodaje obsługę tylko najnowszych szyfrów SSL

2 Jakie są najlepsze sposoby na ograniczenie utraty przychodów i zminimalizowanie narażenia na hakowanie?

Może nie uda się powstrzymać piractwa, ale możemy to utrudnić.

  1. zapobiec uruchomieniu aplikacji na urządzeniach Jailbroken (pomyśl dwa razy, możesz stracić ważnych klientów)
    • Dodaj kod, który wykrywa istnienie Jailbreak
  2. uniemożliwia dołączanie aplikacji do debugerów
      Aplikacje pobrane z AppStore są szyfrowane. Debuggery służą do odszyfrowywania i analizowania aplikacji. Dodaj kod, który wykrywa Debugery.
 5
Author: satishb3,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-01-04 11:08:58

Różni się naprawdę w zależności od tego, co robisz. Jeśli chodzi o dostęp do API, wszystko, co naprawdę musisz zrobić, to hash i / lub sól informacje o użytkowniku, a następnie zapisać informacje (jeśli to konieczne) w pęku kluczy (możesz dodać dodatkowe bezpieczeństwo, szyfrując hasła przed wciśnięciem ich do pęku kluczy. Najlepiej, aby nie używać NSUserDefaults, ponieważ wprowadzone do niego dane są przechowywane w .plik txt na systemie plików iPhone, który, jak powiedziałeś, może być dostępny przez hakerów.

 2
Author: max_,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-02-25 22:28:50