Jak uniknąć nieautoryzowanego użycia interfejsu API?

Muszę zaprojektować „widget”, skrypt, który partnerzy będą osadzać na swoich stronach internetowych, aby wyświetlać interfejs użytkownika i wykonywać połączenia z naszym interfejsem API.

Zasadniczo będzie wyświetlać nasze dane w tych witrynach na podstawie niektórych identyfikatorów podanych w naszych wywołaniach API. Chcielibyśmy uniknąć nadużywania interfejsu API i używania go do zeskrobywania całego naszego katalogu.

Każdy partner, który osadzi nasz skrypt, otrzyma klucz publiczny, który należy podać podczas wywoływania interfejsu API. Pomysłem byłoby poproszenie ich o dodanie tego klucza podczas ładowania skryptu, np .:

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

W ten sposób żądanie skryptu może zostać użyte do zarejestrowania pary klucz / źródłowy adres IP i odbierania kolejnych wywołań API tylko wtedy, gdy para klucz / adres IP pasuje do zarejestrowanej pary (z ograniczonym czasem życia i ograniczeniem liczby żądań dziennie).

Nie jestem pewien, czy to dobry pomysł, ponieważ to oczywiście bezpieczeństwo poprzez zaciemnianie (ktoś, kto przeładuje skrypt, całkowicie go ominie); ale nie widzę innego sposobu ograniczenia dostępu. Nie mogę dostarczyć unikalnego klucza każdemu użytkownikowi, tylko partnerom. Nie mogę użyć systemu klucza prywatnego, ponieważ cały kod będzie dostępny dla każdego. Zasadniczo ogranicza dostęp do publicznego API, tzn. Jest sprzeczny w swojej definicji.

Co sądzisz o tym rozwiązaniu i co zrobiłbyś z tymi ograniczeniami?

Potrzebujesz kilku rodzajów ochrony.

Po pierwsze , należy uniemożliwić korzystanie z klucza witryny A w witrynie B.

Teoretycznie, jeśli klawisz jest przypisany do domeny, nie może zależeć od referernagłówka, ale dlatego, że jesteś klientem jest umieszczenie skryptu bezpośrednio, to można zasadnie powoływać się na document.locationna stronie klienta. Bezpośrednie przesłanie tej lokalizacji (lub jej części) na serwer jest zawodne; ale możesz go użyć do wygenerowania klucza sesji:

1. Klient osadza się client_keyw żądaniu biblioteki API.
2. Serwer określa hosta, który ma dostęp do interfejsu API, jeśli taki istnieje.
3. Serwer wybiera „sól” dla klucza sesji i wysyła go do klienta z biblioteką [lub w ramach innej wymiany przed autoryzacją].
4. Klient oblicza session_keyużycie hash(document.location.host + session_salt).
5. Klient używa session_key+ client_keydo wywołania interfejsu API.
6. Serwer sprawdza połączenie sprawdzając client_keyhosta i „sól” w sesji, obliczając skrót i porównując z podanym client_key.

Po drugie , musisz utrudnić Hackerowi Hankowi otwarcie konsoli debugowania lub użycie zmodyfikowanego klienta w Witrynie A, aby zrobić, co zechce z interfejsem API.

Zauważ jednak, że bardzo trudne, jeśli nie niemożliwe, jest całkowite zapobiegnięcie nadużyciom API przez Hackera Hanka. Ale możesz to utrudnić. I najbardziej rozsądnym sposobem na powstrzymanie Hanka, o czym wiem, jest ograniczenie stawek.

• Ogranicz liczbę żądań / sekundę / sesję i żądań / godzinę / sesję. (Skoki aktywności są prawdopodobnie rozsądne, ale nie utrzymują ponadprzeciętnego ruchu z jednego klienta).
• Ogranicz liczbę sesji / IP / godzinę.
• Ogranicz liczbę żądań / IP / godzinę. Zezwalaj na skoki, ale nie utrzymuj dużego ruchu z jednego adresu IP.

Po trzecie , jak zapewne już robisz: szyfruj ruch. Jasne, NSA to zobaczy; ale Hacker Hank ma mniejsze szanse.

Wygląda na to, że tutaj robisz przekształcanie plików javascript w chronione zasoby. I łącząc go z rodzajem generowania tokenów w tym samym czasie. To interesujące.

Pracownicy ds. Bezpieczeństwa, z którymi współpracuję, zwykle odrzucają adresy IP, ponieważ adresy IP są sfałszowane. Ale jeśli używasz ograniczenia adresu IP w połączeniu z protokołem SSL, zwykle wystarczy.

Ale musisz „dodać do białej listy” adresy IP, w przeciwnym razie każdy haker może po prostu wejść do drzwi.

Byłem sceptyczny, ale myślę, że twój plan działa całkiem dobrze. Jeśli 1) plik .js i kolejne wywołania API są wykonywane za pomocą TLS (tj. SSL lub https), i 2) adresy IP są na białej liście. Potem odważnie oświadczę i powiem, że sądzę, że przejdziesz kontrolę bezpieczeństwa, nawet w przypadku interakcji PCI (karta kredytowa).

IMHO ... Ale jeśli próbujesz chronić informacje zastrzeżone dla firmy zamiast karty kredytowej (PCI) lub danych osobowych / prywatnych (PII), to prawdopodobnie jest to dobre nawet bez SSL, w zależności od tego, ile masz gotowi zaryzykować ujawnienie twojego katalogu.

Innymi słowy: dzięki SSL dedykowany haker nie mógł uzyskać Twojego katalogu. (Chyba że złamią SSL, ale potem też mogą złamać Amazon). Bez protokołu SSL dedykowany haker może wąchać połączenia, fałszować adresy IP i rozkładać katalog. To rodzaj oceny ryzyka.

Próbuję wymyślić sposób na zrezygnowanie z białej listy adresów IP, ponieważ zwykle jest to trudny do opanowania;) bez przechodzenia na pełną wersję OAuth. Zrobię to.