Mam aplikację mobilną (obecnie IOS i wkrótce Android), która rozmawia z usługą internetową. Brak logowania, a dane nie są prywatne. Zasadniczo aplikacja POSTA znacznik (lon, lat) i POBIERA najbliższe 25 znaczników do wyświetlenia na mapie.

To bardzo trywialna aplikacja i nie wyobrażam sobie nikogo, kto wkładałby wiele wysiłku w nadużywanie usługi internetowej. Widzę jednak, że komuś w POSTOWANIU wielu znaczników jest zabawa. Najbardziej niepokoi mnie ktoś, kto uruchamia skrypt, który wypycha wiele żądań (wykorzystując kosztowne pasmo i robiąc nonsens z moich danych aplikacji).

Powoli dochodzę do wniosku, że to nie może być bezpieczne. Najlepszą odpowiedzią jest „nie rób tego”. Nie udostępniaj usługi internetowej bez uwierzytelnienia. Niewiele usług jest tak otwartych. Google You Tube API jest otwarte, ale większość nie. Niestety nie mam wyboru. Więc po kilku dniach patrzenia na to myślę. Bądź świadomy, że jestem bardzo daleko od eksperta ds. Bezpieczeństwa i jestem przekonany, że moje podejście można poprawić. Ale może skierować cię we właściwym kierunku. Miejmy nadzieję, że ktoś bardziej doświadczony może zadzwonić i poprawić / poprawić to. znalazłemTen artykuł i komentarze szczególnie pomocne.

Bezpieczeństwo na poziomie wiadomości

Zabezpieczę wiadomości z szyfrowaniem hash. Wszyscy klienci i usługa internetowa zachowują kopię wspólnego hasła, który jest używany jako sól do tworzenia skrótu z adresu URL i wszystkich argumentów POST. Hash jest przekazywany jako dodatkowy argument, a skrót jest odbudowywany i porównywany na drugim końcu (przy użyciu klucza współdzielonego jako soli). Jest to całkiem dobre, dopóki nie zrozumiesz, że każdy kod klienta mobilnego można poddać inżynierii wstecznej w ciągu kilku minut. W tym momencie ta linia obrony jest całkowicie bezużyteczna.

Środki klienta

Klient zawiera ograniczenie liczby wiadomości jako środek ograniczający liczbę wiadomości wysyłanych przez uczciwych użytkowników. Po raz kolejny jest to bezużyteczne wobec napastnika, który jailbreakuje urządzenie mobilne.

Zabezpieczenia po stronie serwera

Więc strona serwera musi mieć jak najwięcej dodatkowych środków bezpieczeństwa, aby stać samodzielnie, przy założeniu, że twój klient (i wspólny sekret) jest zagrożony. Oto co mam:

Jeden msg arg jest czasem UTC, który służy do ograniczenia ataków powtórek. Powinno to uniemożliwić atakującemu wielokrotne wywoływanie tego samego komunikatu na serwerze.

Serwer przeprowadza ograniczenie szybkości przez IP. Tak, adresy IP można łatwo sfałszować, a przełączanie proxy jest dziecinnie proste, ale wszystko pomaga, gdy masz tak mało.

Oczywiście serwer ściśle sprawdza wszystkie argumenty, używa zapytań sparametryzowanych i nie zwraca wyjątków.

Transport Level Security

Niestety, jestem dość przekonany, że wydawanie indywidualnych certyfikatów SSL klienta nie jest możliwe bez procesu rejestracji. A ponieważ używam sprawdzania skrótu msg (a moje dane nie są prywatne), nie jestem całkowicie pewien, co SSL przynosi do tabeli. Prawdopodobnie jednak będę korzystał z SSL (z jednym certyfikatem w całej aplikacji), ponieważ dodaje kolejny poziom bezpieczeństwa, który jest łatwo i tanio wdrażany (choć kosztem dodatkowego czasu połączenia dla każdego msg).

The Gaping Great Big Hole In My Approach

Ostrzegam, że jeśli aplikacja stanie się popularna, ktoś naruszy współdzielony sekret na kliencie. Tylko dlatego, że mogą i prawdopodobnie opublikują je w Internecie. Tak naprawdę wszystko sprowadza się do strony serwera. Niestety,Nie mam możliwości zidentyfikowania i zablokowania napastnika. To bardzo bym kochał.

Ostateczna prośba

Po dniach badań to wszystko, co mam. Ale chce więcej. Byłbym szczególnie wdzięczny za wszelkie pomysły na wzmocnienie strony serwera. Więc podniosłem wszystkie moje punkty SO jako nagrodę. Tak, proszę pana, wszystkie 97 punktów!