Bezpieczna aplikacja iPhone ↔ komunikacja z serwerem

Jakie byłoby najlepsze podejście do osiągnięcia prywatnej komunikacji między moją aplikacją iOS a jej składnikiem serwera? Czy wystarczy mieć jeden niezmienny „tajny klucz” zapisany w źródle aplikacji, czy też muszę w jakiś sposób dynamicznie konfigurować generacje takich „kluczy uzgadniania”?

Sam serwer nie ma dostępu do żadnych wrażliwych danych, więc nawet jeśli użytkownik trafi na prywatne punkty końcowe, nigdzie ich nie dostanie, ale chcę tylko, aby były one ukryte przed publicznością. Zasadniczo chcę zignorować wszystkie żądania trafiające na określone trasy, chyba że pochodzą one z mojej aplikacji na iOS.

Składnik serwera działa na RoR, jeśli to ważne.

Nie możesz skutecznie odrzucać połączeń, chyba że dostarczysz każdemu klientowi klucz prywatny, który możesz indywidualnie unieważnić. Ale to prawdopodobnie przesada. Nie potrzebujesz kuloodpornego rozwiązania, jeśli większość ludzi nie będzie kłopotać się wystrzeleniem kuli.

To pytanie bezpieczeństwa, więc opiszmy model zagrożenia i strategie łagodzenia.

Załóżmy, że masz trafienie URL-em, które może ponieść znaczne koszty (np. Koszty przetwarzania), i chcesz chronić go zarówno przed prostym atakiem DoS, jak i przed aplikacjami kopiującymi.

Użyj protokołu SSL, aby ukryć połączenie przed łatwą analizą. Użyj nieobliczalnego numeru portu, sekwencji przekierowań, wymiany plików cookie, aby nieco skomplikować połączenie przed wykonaniem kosztownej części żądania. Użyj tajnego kodu zapisanego w swojej aplikacji, aby poinformować serwer, że musi zaakceptować połączenie.

Teraz ktoś nie może nauczyć się kosztownego adresu URL po prostu uruchamiając sniffer pakietów lub patrząc na ciągi podobne do adresu URL w kodzie. Potencjalny atakujący musi zdekompilować Twoją aplikację.

Naprawdę nie możesz chronić swojego kodu przed dekompilacją i / lub działaniem pod kontrolą debugera. Atakujący w końcu uczy się tajnego klucza i sekwencji połączeń.

Zauważysz, że zaczynasz otrzymywać prośby o rouge pod swoim kosztownym adresem URL: w formie ataku lub w formie aplikacji naśladowczej, która musi uzyskać dostęp do Twojej usługi, aby mogła zostać uruchomiona, lub może kod exploita jest opublikowany publicznie. Nie można jednak odróżnić fałszywej prośby od uzasadnionej prośby.

Utwórz bezpłatną niewielką aktualizację aplikacji, używając innego tajnego klucza. Powinien trafić inny kosztowny adres URL, który obsługuje te same dane, co skompromitowany kosztowny adres URL. Przez pewien czas udostępniaj oba adresy URL.

Zobacz, jak baza użytkowników przełącza się na zaktualizowaną wersję. Ogranicz przepustowość kosztownego adresu URL i ostatecznie 404. Właśnie ograniczyłeś naruszenie bezpieczeństwa, miejmy nadzieję, nie tracąc zbyt wiele. Z powrotem do kwadratu.

Oświadczenie: Nie jestem ekspertem od bezpieczeństwa.

Masz klasyczny problem, którego naprawdę nie da się rozwiązać.

Aby zapewnić prostą prywatność (tj. Upewnić się, że twoich danych nie można przechwycić ani zmienić podczas transportu), możesz zrobić wszystko przez SSL i dać swojemu serwerowi prawidłowo wydany certyfikat przez CA, który rozpoznaje iPhone.

Jednak w przypadku autoryzacji nie ma dobrego rozwiązania, które w 100% gwarantuje, że nikt inny jak Twoja aplikacja nie będzie mieć dostępu do interfejsu API. Proponowane rozwiązanie będzie działać, z wyjątkiem:

• każdy, kto pobrał twoją aplikację, musi koniecznie posiadać klucz prywatny
• jeśli uda im się w jakiś sposób rozpakować aplikację i ją skompilować, będą mieli klucz prywatny w postaci zwykłego tekstu
• po uzyskaniu klucza prywatnego w postaci zwykłego tekstu mogą go używać do podpisywania własnych złośliwych żądań.

Nie da się tego obejść. Nie oznacza to, że nie można przyjąć takiego podejścia, ale należy zrozumieć, że nie jest on niezawodny. To właśnie ten problem sprawia, że DRM jest całkowicie nieskuteczny .

Po to są TLS i SSL . Można utworzyć bezpieczne połączenie bez konieczności posiadania stałego tajnego klucza. Przeczytaj sekcję Opis na połączonej stronie, aby dowiedzieć się, jak to zrobić.

Skutecznym sposobem na uzyskanie korzyści z TLS / SSL bez konieczności wykonywania dużej (jakiejkolwiek) pracy jest umożliwienie serwerowi wdrożenia usługi sieciowej, do której klient uzyskuje dostęp za pomocą protokołu HTTPS. HTTPS to po prostu HTTP przez bezpieczne połączenie, a system ładowania adresów URL w iOS implementuje go za Ciebie.