Jak zapobiec używaniu anonimowego API przez dowolne aplikacje klienckie?

Question

Jak zapobiec używaniu anonimowego API przez dowolne aplikacje klienckie?

Przepraszam, jeśli to już zostało zadane i odpowiedzi; rozejrzałem się kilka, ale nie znalazłem dokładnie to, o co pytam.

--

Załóżmy, że moja aplikacja internetowa na http://example.com/ używa prywatnego i nieudokumentowanego interfejsu API w http://api.example.com / do pobierania danych, np. przez XHR lub JSONP.
Załóżmy również, że ta aplikacja internetowa jest anonimowa-nie wymaga logowania użytkownika.
Ponieważ jest komunikacja pomiędzy Klientem a serwerem, każdy może otworzyć Fiddlera itp. aby zobaczyć dokładną prośbę i odpowiedź, nie wspominając o sprawdzeniu kodu JS po stronie klienta.

W takim przypadku, jak możesz uniemożliwić komuś korzystanie z twojego API w non-web Aplikacja kliencka? Np. aplikacja na iPhone ' a lub po stronie serwera.

Według mnie punkt # 2 usuwa opcję czegoś takiego jak OAuth, a punkt # 3 usuwa opcję np. kluczy API czy nawet SSL.

Myślałem o rzeczy takie jak tokeny czasowe lub tajne sole, które są wstrzykiwane do strony przy pierwszym załadowaniu, ale aplikacja na iPhone ' a może łatwo potajemnie załadować Twoją stronę internetową przed złożeniem wniosków API.

Czy jest jakiś sposób poza zwykłym zaciemnieniem-bezpieczeństwo przez zaciemnienie?

--

Jeśli wszystko jest zbyt abstrakcyjne, Oto prosty przykład:

Google.com pobiera automatycznie uzupełniane dane za pośrednictwem prywatnego i nieudokumentowanego interfejsu API-ale otwartego w sieci. Co mnie powstrzyma z używania go w aplikacji na iPhone ' a?

41

security web-applications api

Author: Aseem Kishore, 2011-03-17

Source

4 answers

Uwierzytelnianie nie zapobiega nadużyciom twojego API. Tak długo, jak klient może poprawnie uwierzytelnić się z Twoim systemem, może korzystać z dowolnego klienta, którego wybierze. Tylko w przypadku, gdy klient i serwer są bezpieczne, a połączenie jest bezpieczne, można uniknąć nadużyć.

Jeśli problemem jest nadużycie, to proste rozwiązanie dławienia może być odpowiednie.

4

Author: Kim E,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-09-06 06:43:18

Bez klucza API lub jakiejś formy autoryzacji, będziesz toczyć przegraną walkę, próbując utrzymać nieautoryzowanych klientów z dala od twojej usługi.

Można powąchać wiele rzeczy, ale trudną prawdą jest, że większość z nich jest łatwo sfałszowana. Czy kontrolujesz inne usługi internetowe? Ponadto, jeśli Twoja aplikacja internetowa (http://example.com/) uzyskuje dostęp do API (http://api.example.com/) za pośrednictwem XHR lub JSONP, możesz zastąpić dane na swoim serwerze za pomocą biblioteki, takiej jak cURL, aby uzyskać dane, a następnie udostępnić je na swojej stronie. Można wtedy kontroluj dostęp do niego w dowolny sposób.

2

Author: alex,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-03-17 00:29:09

Jeśli twój Klient ma kod, który jest ukryty przed szpiegami, możesz nie robić tak, jak sugerowałeś, używać soli, adresu ip i wartości opartych na czasie, szyfrować je, a następnie zrobić to samo na końcu serwera? To jest w zasadzie to, co robi mod_auth_tkt i działa dobrze. A może stanowiłoby to potwierdzenie autentyczności?

2

Author: Oskar Austegard,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-03-17 02:18:35

score 19 · Accepted Answer

Nie możesz uniemożliwiać ludziom kopiowania kodu klienta lub odtwarzania ruchu sieciowego.

Dzięki tej samej polityce origin inne aplikacje internetowe nie mają dostępu do twojego API z poziomu klienta. Będą musieli zastępować swoje żądania za pośrednictwem serwera, co oznacza, że żądania te będą pochodzić z kilku łatwo zidentyfikowanych adresów IP, które możesz tymczasowo umieścić na czarnej liście.

Jeśli chodzi o aplikacje stacjonarne i mobilne, niewiele można zrobić. Radzę nie martwić się o nich, dopóki nie będą problem.

To powiedziawszy, nie zaszkodzi być przygotowanym. Jeśli chcesz uniknąć kosztownych bitew prawnych, możesz od czasu do czasu zmieniać podpisy metod API. Aplikacje ługowania można naprawić, ale ich reputacja będzie stale spadać.