Najlepsza praktyka wykrywania dostępu do aplikacji internetowych tylko dla usług internetowych?

Question

Pracuję nad aplikacją na iPhone'a wraz z usługami sieciowymi. Aplikacja iPhone będzie używać GET lub POST do pobierania danych z serwisów internetowych, takich jak http://www.myserver.com/api/top10songs.json, aby na przykład uzyskać dane dla dziesięciu najlepszych piosenek.

Brak konta użytkownika i hasła do aplikacji na iPhone'a. Jaką najlepszą praktyką jest zapewnienie, że tylko moja aplikacja na iPhone'a ma dostęp do interfejsu API sieci Web http://www.myserver.com/api/top10songs.json? UIDevice uniksowego identyfikatora UDevice pakietu iPhone nie jest wystarczający, ponieważ każdy może podrobić identyfikator urządzenia jako parametr wywołujący wywołanie API za pomocą wget, curl lub przeglądarek internetowych.

Interfejs API usług internetowych nie zostanie opublikowany. Dane serwisów internetowych nie są tajne i prywatne, po prostu chcę zapobiec nadużyciom, ponieważ istnieją również API do zapisywania danych na serwerze, takich jak dziennik użytkowania.

Answer 1

Co możesz zrobić, to zdobyć tajny klucz, który tylko Ty znasz, Podaj, że w haszyszu md5, zazwyczaj możesz budować sygnatury jako parametry swoich parametrów i tajne dołączane na końcu, a następnie skrót md5 tego ... Zrób to zarówno po stronie klienta, jak i po stronie usługi i dopasuj ciąg znaków do podpisu, tylko jeśli podpisy są zgodne, masz dostęp ... Ponieważ sekret jest obecny tylko w podpisie, trudne do inżynierii wstecznej i pęknięcia ..

Answer 2

Użyj w formularzu jakiejś formy digital signatures. Chociaż trudno jest zrobić to całkowicie odporne na manipulacje (jak wszystko, co dotyczy bezpieczeństwa). Nie jest trudno uzyskać to "wystarczająco dobre", aby zapobiec większości nadużyć.

Oczywiście zależy to w dużym stopniu od wrażliwości danych, jeśli transakcje danych obejmują transakcje o wartości miliona dolarów, będziesz potrzebować dużo bezpieczniejszego niż proste rejestrowanie statystyk użytkowania (jeśli jest wystarczająco trudne do sfałszowania i zyskiwać mało do zyskania dla atakującego, oprócz wkurzania cię, bezpiecznie założyć, że ludzie nie będą się kłopotać ...)

Answer 3

Bardzo tanim sposobem na zrobienie tego może być pobranie oprogramowania iPhone'a w celu wysłania dodatkowych danych wraz z zapytaniem , na przykład długi ciąg hasła, aby ktoś nie mógł uzyskać dostępu do kanału.

Ktoś może wykonać inżynierię wsteczną, co zrobiłeś lub odsłuchać dane przesyłane przez sieć, aby wykryć hasło i jeśli powodem tego są ograniczenia przepustowości, proste hasło powinno być wystarczająco dobre.

Oczywiście ta metoda ma swoje problemy, a uwierzytelnianie na podstawie certyfikatu będzie rzeczywiście bezpieczne, chociaż będzie trudniej kodować.

Answer 4

Problem z większością, jeśli nie wszystkimi rozwiązaniami, polega na tym, że są podatni na zerwanie po dodaniu serwerów proxy w miksie. Jeśli proxy łączy się z twoją usługą internetową, czy to jest w porządku? W końcu prawdopodobnie robi to w imieniu iPhone'a - może w Chinach? A jeśli jest w porządku, aby proxy podszywało się pod iPhone'a, to w jaki sposób ustalasz, które podszywanie się jest OK?

Answer 5

Najbardziej bezpieczne rozwiązanie to prawdopodobnie cyfrowy podpis na żądanie. Możesz przechowywać tajny klucz w aplikacji na iPhone'a i używać go do podpisywania żądań, które następnie możesz zweryfikować po stronie serwera. Zapobiega to wysyłaniu klucza/hasła do serwera, który umożliwiłby komuś przechwycenie go za pomocą sniffera sieciowego.

Prostym rozwiązaniem może być po prostu użycie HTTPS - utrzymywanie zawartości wiadomości jest bezpieczne, pomimo obecności potencjalnych podsłuchiwaczy, to cały punkt HTTPS. Nie jestem pewien, czy możesz sam wystawiać certyfikaty za pomocą standardowych rzeczy NSURLConnection, ale jeśli masz certyfikat po stronie serwera, jesteś przynajmniej chroniony przed podsłuchem. I jest o wiele mniej kodu do napisania (właściwie żadnego).

Przypuszczam, że jeśli używasz HTTPS jako jedynego zabezpieczenia, możesz otworzyć się na kogoś, kto zgadnie, jaki jest adres URL. Jeśli jest to problemem, zadba o to, dodając do usługi sieciowej niemal każdy rodzaj walidacji parametrów.

Answer 6

Oto rozwinięcie sugestii Daniela.

Masz wspólny sekret, który znają serwer i klient. Powiedz jakiś długi losowy ciąg znaków.

Następnie, gdy klient łączy się, niech klient wygeneruje kolejny losowy ciąg, dopisz go na końcu udostępnionego ciągu, a następnie oblicz wartość skrótu MD5.

Wysyła zarówno losowo wygenerowany łańcuch, jak i skrót, jako parametry w żądaniu. Serwer zna tajny ciąg znaków, więc może wygenerować własny skrót i upewnić się, że jest zgodny z tym, który otrzymał od klienta.

To nie jest całkowicie bezpieczne, ponieważ ktoś może zdekompilować aplikację, aby określić tajny ciąg znaków, ale prawdopodobnie jest to najlepsze rozwiązanie bez dodatkowej pracy.

Answer 7

Zapytałem o to inżyniera bezpieczeństwa Apple na WWDC i on powiedział, że nie ma niemożliwego do opanowania sposobu, aby to osiągnąć. Najlepsze, co możesz zrobić, to sprawić, by nie było to warte wysiłku.

Zapytałem go również o możliwość użycia powiadomień push jako sposobu na zrobienie tego, a on pomyślał, że to bardzo dobry pomysł. Podstawową ideą jest to, że pierwszy dostęp wywoła powiadomienie push na serwerze, które zostanie wysłane do iPhone'a użytkownika. Ponieważ twoja aplikacja jest otwarta, wywołałaby metodę application:didReceiveRemoteNotification: i dostarczyła ładunek według własnego wyboru. Jeśli uczynisz ten ładunek dodatkiem, wtedy twoja aplikacja może wysłać numer przy następnym żądaniu i ukończyć krąg.

Można następnie przechowywać identyfikator UDID i odrzucić wszystkie żądania zawierające niezweryfikowane identyfikatory UDID. Jeśli chodzi o domniemane wymuszenie potrzebnych parametrów, powinieneś wdrożyć algorytm ograniczający szybkość, bez względu na wszystko.

Answer 8

Masz jakiś klucz, który zmienia się co 5 minut w oparciu o algorytm, który wykorzystuje aktualny czas (GMT). Zawsze zezwalaj na ostatnie dwa klucze. Oczywiście nie jest to doskonałe, ale utrzymuje cel w ruchu i można go łączyć z innymi strategiami i taktykami.

Zakładam, że chcesz odwieść korzystanie z usługi. Oczywiście nie skonfigurowałeś swojej aplikacji, by była bezpieczna.