Zabezpieczanie REST API (niezależnie od technologii).

Question

Aplikacje w postaci połączenia REST API na backendzie i front-end zrobiony w którymś z JS-owych frameworków to nic nowego. W zasadzie teraz chyba robi się tak większość aplikacji (??).

Jednak czytałem ostatnio wpis na jednym portalu, że takie nowoczesne aplikacje znacznie trudniej zabezpieczyć, w stosunku do starych (gdzie front jest renderowany po stronie serwera).

Hakerzy / przestępcy mogą w łatwy sposób przejąć hasła, tokeny i klucze oraz endpointy API. Ponoć najłatwiej wyciągnąć te rzeczy z appek mobilnych, które łączą się z API (w sumie nie wiem dlaczego), ale appki webowe, niezależnie czy w Angularze, Reactcie, Vue czy innej technologii też są ponoć łatwe do hackowania.

Jak są zwykle zabezpieczane REST API, w typowych zastosowaniach? Co można zrobić więcej, żeby lepiej zabezpieczyć takie API?

Natrafiłem na stronę która ma rozwiązanie (płatne), które nieco utrudnia hackerom robotę:

https://www.approov.io/

Comments

Doprecyzujesz co masz na myśli, może daj linka do tego wpisu? Jakie to ataki, jakie łatwe sposoby, na czym polegają? Bo wydaje mi się, że trochę przesadzasz z tym, że to akurat aplikacje z rozdzielonym frontendem i API są tak strasznie niebezpieczne.

---

Jeśli appka mobilna przechowuje klucz do API to można go dość łatwo wyciągnąć, prawda? Tak samo endpointy API.

Jeśli chodzi o rodzaje ataków, to masz wszystko w linku firmy APPROOV:

W części: "Don't Let API Abuse Compromise Your Business!"

 

Natknąłem się na podobne informacje w kilku miejscach, ale najszybciej znalazłem tekst który czytałem ostatnio:

https://elixirforum.com/t/thinking-of-building-e-commerce-please-give-me-advices/33309/10

Użytkownik:  Exadra37  / Ostatni wpis

 

 

---

I co z tego, że ktoś wyciągnie endpointy API? Jeśli to jest publiczna witryna, to nie widzę w tym żadnej różnicy. Gdy to byłaby standardowa aplikacja, bez rozdziału na frontend i backend osobno, to również ktoś normalnie zna endpointy - bo to są te, które się po prostu odwiedza, wchodzi na te adresy w przeglądarce. Również ma na nich dostępne te same dane, które dostanie z API - tylko na API są często jako JSON (więc może sobie z nimi łatwiej coś zrobić), a na stronie już gdzieś wmieszane w HTML. Z kolei jeśli witryna ma ograniczony dostęp, to prawdopodobnie trzeba się zalogować, aby uzyskać dostęp do określonych zasobów. A więc bez znajomości danych dostępowych i tak niczego nie zrobi.

Na stronie podanej firmy wypisana jest masa rzeczy, w tym ochrona przed atakiem DoS, zabezpieczenia przed spamem i innymi rzeczami, które mogą się tyczyć dowolnej aplikacji, nie tylko tej, która ma akurat osobne API. Osobiście nie znam tej firmy, nie korzystałem z jej usług, więc się nie wypowiem - być może jest to ok, ale to samo można próbować osiągać różnymi innymi sposobami i bronić się innymi siłami. Jednak nadal założenie, że to akurat apki które posiadają osobne API są z definicji niebezpieczne wydaje mi się błędne.

Answer 1

Są zabezpieczenia wspólne dla wszystkich typów aplikacji.

1. Podstawą jest korzystanie z https.
2. Kolejna kwestia to korzystanie z najnowszych wersji najpopularniejszych frameworków oraz bibliotek: nie daje to żadnej gwarancji, ale kompleksowo dostarcza gotowe rozwiązania sprawdzone przez wiele osób. Ponadto wychodzą cały czas security fixy.
3. Walidacja wszystkich danych przychodzących od usera.
4. Dla wszystkich danych przychodzących z frontu stosujemy prepared statements i parameterized queries.
5. Ciastka sesyjne z flagą httpOnly. 
6. Ustawienie odpowiednich nagłówków bezpieczeństwa: CSP, HSTS, CORS itp.
7. Są też zasady pisania kodu po stronie backendu. Zapobiega to takim podatnościom jak na przykład RCE.

Jest jeszcze wiele innych dobrych praktyk, ale to warto znać i z powodzeniem stosować.

Comments

Dziękuję za tą listę, na pewno nie tylko mnie się przyda!

Tu jeszcze znalazłem kilka pozycji (mogą się powtarzać):

https://apifriends.com/api-security/rest-api-security/

---

@Ehlert, z tym punktem drugim to może być różnie.Nowa wersja to i nowe błędy, które wyjdą dopiero za jakiś czas:)