Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Przechowywanie klucza API w aplikacji mobilnej to nie jest najlepszy pomysł…
Przekonali się o tym deweloperzy jednej z kontrowersyjnych appek o dość nietypowym zadaniu – wskazywanie amerykańskich restauracji, gdzie bezpiecznie jest nosić czapkę z logo 'Make America Great Again’. Ale zostawmy politykę na boku.
Appka napisana w React Native, zaszyty w niej klucz do API oraz adresy URI backendu:
API key
Oczywiście można było tutaj bez żadnego uwierzytelnienia wołać te metody. Dobrze czytacie, z informacji opublikowanych przez tajemniczego hackera Ellita Aldersona ;) wynika, że przynajmniej część metod nie potrzebowała nawet klucza API.
Swoją drogą same statyczne klucze API to często w ogóle nie jest dobry pomysł. Polecamy tutaj rozważyć choćby OAuth2 czy JWT.
–ms
Nie no straszne, można poznać maile czterech tysięcy osób.
Nie rozumiem o czym tu pisać, praktyka z kluczem też wcale nie jest jakaś szokująca.
„praktyka z kluczem [api zahardkodowanym w appce] też wcale nie jest jakaś szokująca.”
O cholera :) Znaczy, że bezpiecznicy będą mieli pracę do końca świata i jeden dzień dłużej ;-)
A nie będą? ;)
I dlatego porzucilem pełnoetatową pracę programisty na rzecz bezpiecznika ?
Problem z API key w tym przypadku to jego niefortunna nazwa. W przypadku Google App Engine – tutaj domena appspot.com, API key to bardziej identyfikator instancji bazy danych i wręcz musi być publiczny, aby aplikacja mogła działać poprawnie. Inna sprawa, że baza nie powinna zwracać wszystkich danych, ale tutaj już problem tkwi w samej konfiguracji App Engine i jego polityk dostępu niżeli samego „API Key”.
Tutaj jest jedna z części poradnika React, Redux i Firebase omawiająca jak wygląda konfiguracja aplikacji napisanej w React’cie z bazą Firebase i jest opisane jak powinno się zabezpieczyć aplikację – czy programiści robią to poprawnie, to inna kwestia.
Link: https://youtu.be/z0QpTl5-0Bk?t=185