Możliwości dekompilacji w iOS i jak im zapobiegać

Jest to problem, który ludzie ścigają od lat, a każda odpowiednio zmotywowana osoba z umiejętnościami będzie w stanie znaleźć sposoby, aby dowiedzieć się wszelkich informacji, których nie chcesz, aby dowiedzieć się, jeśli informacje te są kiedykolwiek przechowywane na urządzeniu.

Bez jailbreakingu możliwe jest demontowanie aplikacji za pomocą zakupionego lub pobranego pliku binarnego. Jest to kontrola statyczna i jest ułatwiona za pomocą standardowych narzędzi do demontażu. Chociaż trzeba mieć narzędzie, które jest dobre wystarczy dodać symbole z linkera i zrozumieć wywołania metody wystarczająco, aby móc drażnić się z tym, co się dzieje. Jeśli chcesz dowiedzieć się, jak to działa, sprawdź hopper, to naprawdę dobre narzędzie do demontażu/inżynierii odwrotnej.

Szczególnie w przypadku twojego bezpiecznego logowania, masz większy problem, jeśli masz zmotywowanego napastnika: systemowe ataki typu man-in-the-middle. W takim przypadku atakujący może ujawnić kod sieciowy używany przez system i Zobacz wszystko, co jest wysyłane przez standardową sieć. Dlatego nie można polegać na tym, że można wysyłać dowolne niezaszyfrowane dane do "bezpiecznego" Potoku na poziomie systemu operacyjnego lub biblioteki i oczekiwać, że nie będą widoczne. Co najmniej musisz zaszyfrować dane przed wprowadzeniem ich do potoku (tzn. nie możesz polegać na wysyłaniu zwykłego tekstu do standardowych bibliotek SSL). Możesz skompilować własny zestaw bibliotek SSL i połączyć je bezpośrednio z aplikacją, co oznacza, że nie uzyskasz żadnej wydajności systemu i ulepszenia zabezpieczeń w miarę upływu czasu, ale w razie potrzeby można ręcznie uaktualnić biblioteki SSL. Możesz również utworzyć własne szyfrowanie, ale jest to obarczone potencjalnymi problemami, ponieważ zmotywowani hakerzy mogą łatwiej zaatakować twój protokół wire w tym momencie (publicznie Przetestowane protokoły, takie jak SSL, są zwykle bezpieczniejsze niż to, co możesz zrobić samodzielnie, chyba że jesteś szczególnie utalentowanym programistą z wieloletnim doświadczeniem w zakresie bezpieczeństwa/szyfrowania).

Jednak wszystkie zakłada to, że atakujący jest wystarczająco zmotywowany. Jeśli usuniesz nisko wiszące owoce, możesz uniemożliwić przypadkowym hakerom podjęcie prostej próby zrozumienia systemu. Niektóre rzeczy, których należy unikać:

• przechowywanie kluczy szyfrowania zwykÅ‚ego tekstu dla obu stron szyfrowania
W plikach przechowywanych w pliÅ›cie o nazwie zawierajÄ…cej key można przechowywać klucze w okreÅ›lonych zasobach (plik o nazwie serverkey.text lub klucz przechowywany w pliÅ›cie o nazwie zawierajÄ…cej key sÄ… klasykami)
• unikaj prostych hasÅ‚a w miarÄ™ możliwoÅ›ci

Ale najważniejsze jest tworzenie systemów, w których klucze (jeśli istnieją) przechowywane w samej aplikacji są bezużyteczne bez informacji, które użytkownik musi wprowadzić samodzielnie (bezpośrednio lub pośrednio poprzez systemy takie jak OAUTH). Serwer nie powinien ufać klientowi w żadnej ważnej operacji bez interakcji z użytkownikiem, któremu można zaufać.

Pęk kluczy firmy Apple zapewnia dobre miejsce do przechowywania tokenów uwierzytelniania, takich jak pobrane podczas sekwencji OAUTH. Interfejs API jest nieco trudny w obsłudze, ale system jest solidny.

W końcu problem polega na tym, że bez względu na to, co robisz, po prostu podbijasz stawkę na ilość pracy, jaką potrzeba, aby pokonać swoje środki. Atakujący kontroluje wszystkie ważne części równania, więc ostatecznie pokonuje wszystko na urządzeniu. Będziesz musiał zdecydować, ile wysiłku włożyć w zabezpieczenie klienta, a nie zabezpieczenie serwera i monitorowanie nadużyć. Ponieważ atakujący posiada wszystkie karty na urządzeniu, Twoje lepsze podejście będzie metody, które mogą być zaimplementowane na serwerze, aby zwiększyć swoje cele.