Jak chronić "publiczną" część usługi REST przed spamem?

Question

Mam usługę REST, która jest w miarę kompletna i będzie używana w aplikacji na iOS. Jest zbudowany przy użyciu Ruby/Sinatra, ale nie sądzę, że to ma naprawdę znaczenie.

Używam podstawowego uwierzytelniania HTTP przez SSL dla różnych punktów końcowych i ta część działa bardzo dobrze.

Pytanie brzmi: Pytanie: Jak powstrzymać spamerów itp. Przed wywołaniem części usługi REST, które nie są chronione za pomocą podstawowego uwierzytelniania HTTP?

Przykład: Rejestracja użytkownika

Przyjmijmy wezwanie reszta jest (POST).../register_account przekazując obiekt JSON w organizmie.

Z oczywistych powodów, to połączenie nie może oczekiwać nazwy użytkownika/hasła powiązanego z kontem użytkownika.

Idee są:

1) Aplikacja posiada własną nazwę użytkownika ''/hasło, a niektóre połączenia byłoby sprawdzić app-mandatów. Problem: Rootowanie urządzenia itp. Może wydobyć te poświadczenia.

2) Aplikacja przekazuje tajny token za pośrednictwem nagłówka HTTP do usługi REST dla tych połączeń. Problem: Tak samo jak (1)

Czy są jakieś powszechnie stosowane metody zapobiegania takim wywołaniom spamu? Myślę, że może wprowadzić identyfikator urządzenia iPhone'a w miksie, ale nie zidentyfikowałem jeszcze jednoznacznego podejścia.

Dzięki

Answer 1

Kod aplikacji jest dobrym pomysłem na pierwszą linię obrony przed spamem, ale mimo to należy wdrożyć pewne ograniczenia stawek dla usług, których dotyczy problem.

Na przykład, jeśli korzystasz z sesji w usługach REST, możesz z łatwością ograniczyć liczbę połączeń przetwarzanych z pojedynczej sesji. Sesja nie musi być w ogóle uwierzytelniana i służy wyłącznie do identyfikacji pojedynczego klienta podczas składania żądania. Proste przekierowanie z powrotem do żądanej usługi, jeśli próbują połączyć się bez otwartej sesji, to wszystko, czego potrzeba, i praktycznie wszystkie struktury sieciowe lub stosy mają to wbudowane.

Można również ograniczyć stawki w przypadku innych właściwości, takich jak Odcisk palca IP lub użytkownika-agenta, ale są one mniej niezawodne niż metoda sesyjna.

Answer 2

Ty mógł utwór adresy IP za pomocą request.ip i napisać logiki wokół tego.

Answer 3

Ogólnie rzecz biorąc, powszechnym podejściem jest klucz API, który jest identyczny z tajnym tokenem opisanym powyżej. Możesz to zakodować na stałe w aplikacji i utrudnić komuś odtwarzanie kodu źródłowego (ukryć, zbudować z różnych części przechowywanych w różnych miejscach aplikacji itp.). Masz rację, że zdeterminowany napastnik będzie w stanie odzyskać klucz (jeśli twoja aplikacja może to zrobić, może również ktoś inny z dostępem do twojej aplikacji) ... ale możesz utrudnić to miejsce, gdzie, mam nadzieję, nie będzie nie warto poświęcać czasu i wysiłku, aby to zrobić.

Można również rozważyć wdrożenie wzajemnie uwierzytelnionego protokołu SSL, aby serwer akceptował tylko połączenia przychodzące z aplikacji, a aplikacja będzie komunikować się tylko z serwerem.

Oto podejście wysokiego poziomu. Utwórz samopodpisany certyfikat SSL serwera i zainstaluj go na swoim serwerze sieciowym. Następnie utwórz klienta z podpisem własnym i wdrożyć go w aplikacji jako zasób. Skonfiguruj serwer tak, aby wymagał uwierzytelniania SSL po stronie klienta i akceptuj tylko wygenerowany certyfikat klienta. Skonfiguruj klienta tak, aby korzystał z tego certyfikatu po stronie klienta w celu identyfikacji i zaakceptuj tylko jeden certyfikat po stronie serwera zainstalowany na serwerze dla tej części.

Jeśli ktoś/coś inne niż twoja aplikacja próbuje połączyć się z serwerem, połączenie SSL nie zostanie utworzone, ponieważ serwer odrzuci przychodzące połączenia SSL, które nie zawierają certyfikatu klienta, który został dołączony do aplikacji.