it-swarm-eu.dev

Zabezpečení API pro mobilní přístup

Postavil jsem API Nice REST/JSON, které používají jiné společnosti (naši klienti) jako službu B2B. Každý z našich klientů má pár uživatelských jmen a hesel a také děláme HTTPS a ověřujeme zdrojovou IP požadavků na službu. Využití služby stojí peníze a klientovi se za používání služby účtuje měsíčně.

Nyní někteří klienti vytvářejí mobilní aplikace, které rozdávají svým uživatelům (koncoví uživatelé B2C). Ne všichni tito koncoví uživatelé naší služby mají servery a chtějí používat službu přímo ze smartphonu (což technicky není ono JSON/REST).

Problém je, že si nejsem jistý, jak chránit službu před podvody. Co zabrání vývojáři třetí strany rozebrat jednu z mobilních aplikací klienta a zkopírovat jeho uživatelské jméno/heslo/jakékoli bezpečnostní údaje a použít je ve své aplikaci? To by mu umožnilo spotřebovat službu a účtovat poplatky za používání některému z našich oprávněných klientů!

Jsem si zcela jistý, že neexistuje dokonalé kryptografické řešení tohoto problému, pokud koncoví uživatelé nejsou pověřeni k ověření na některém serveru. To však není vždy pravda.

Myslím, že jako poslední možnost mohu distribuovat zatemněnou knihovnu pro Android/IPhone, která by přinášela alespoň iluzi bezpečnosti ...

ÚPRAVA (objasnění):

Pokusím se scénář zjednodušit.

  1. Mám nenapadnutelný webový server, který poskytuje rozhraní JSON REST API).
  2. Mobilní klienti přistupují přímo k mému rozhraní API. Jejich IP nelze ověřit. Používají standardní operační systém (Android/IOS).
  3. Nejsou zahrnuty žádné další servery.
  4. Nemohu přistupovat k IMEI telefonů (považuje se to za soukromé), ani by mi to nepomohlo, protože neznám konečné uživatele.
  5. Existuje několik takových legálních mobilních aplikací vyvinutých různými společnostmi, které přistupují k našemu API.
  6. Aktuální zabezpečení (uživatelské jméno/heslo) je snadno hackovatelné rogue společností. Uvedená nepoctivá společnost rozebírá legitimní mobilní aplikaci a zkopíruje uživatelské jméno/heslo do své nelegální aplikace. Distribuují tuto aplikaci a zisk (použití API je účtováno společnosti, od které ukradli přihlašovací údaje).

Lze to zastavit?

16
Tal Weiss

Vaše otázka zní: „Lze to zastavit?“, Ale mám pocit, že se nic podstatného o systému nemůže/nebude opravdu měnit.

Pokud tomu rozumím správně, ptáte se (zjednodušeno):

Mám mnoho klientů, kteří sdílejí stejné uživatelské jméno a heslo. Mohu přestat zneužívat?

Odpověď na to je ne. Musíte se rozhodnout, zda si můžete dovolit problém ignorovat, nebo implementovat správná řešení.

Pokud to opravdu chcete udělat správně, podívejte se na implementaci něčeho, jako je OAuth, takže můžete správně distribuovat samostatné autorizační tokeny pro koncové uživatele, propojit je se svými klienty za účelem fakturace, zrušit přístup atd.

-

Nejméně, co byste měli udělat, je umožnit vašim klientům (společnostem), aby se rozhodli používat lepší režim autorizace. Například pro ně vytvoříte API, které bude požadovat (a odvolávat) samostatné přístupové tokeny pro jejich koncové uživatele.

  • Společnost A požaduje token ze svých serverů (je to iniciováno aplikací, která jim říká „dej mi token“)
  • Vrátíte token N, zaznamenejte, ke které společnosti je připojen
  • Pokud se společnost A-s připojí k vaší službě, odešle token N, nikoli uživatelské jméno/heslo
  • Společnost A může vaší službě sdělit, že „odvolá token N“, a další požadavky s tímto tokenem nebudou vaší službou doručeny. Pokud je však token odvolán, nezpůsobí to, že budou všechny klientské aplikace nepoužitelné.

Pokud to společnost nechce, může se i nadále připojovat pomocí svého uživatelského jména/hesla, ale za veškeré výsledné použití by plně odpovídá.

Jde o to, že opravdu nemůžete mít za to, že vaši klienti jsou zodpovědní za únik pověřovacích údajů (něco, co není možné provést ve scénáři mobilní aplikace), pokud nemají jiný způsob, jak službu využít.

7
Joel L

Doufám tedy, že to mám správně. Chcete bezpečný způsob, jak potvrdit totožnost klienta pomocí platného klíče API? Myslím si, že bezpečné uložení klíče API je z velké části odpovědné za společnost, která vyvinula aplikaci, a nikoli za vaši společnost.

Budete muset zašifrovat a zatemnit klíč, abyste jej ochránili před náhodným hackerem, ale nemyslím si, že budete někdy schopni určitému hackerovi zabránit. Dalo by se udělat trochu hackerství, aby se binární těžší ladit, což může snížit šance vaší aplikace plovoucí po internetu. Nejedná se však o absolutní zabezpečení a pokud vaše společnost nevyvíjí vlastní aplikace, jak můžete vynutit taková opatření?

Takže jako odpověď na váš scénář ne, nemyslím si, že může být účinně zastaven, aniž by to nepříznivě ovlivnilo dojem uživatelů. Společnosti můžete vzdělávat pomocí svého rozhraní API - zahodit pro ně malou příručku a ujistit se, že je jasné, že je jejich zodpovědnost udržovat jejich klíč Api v bezpečí.

Nakonec můžete také implementovat některé funkce zmírňování. Například:

  1. Umožněte společnostem definovat své vlastní pevné limity. Řekněte společnosti A, že ví, že minulý měsíc měli N aplikací ke stažení, a proto chtějí omezit svůj přístup k vašemu API na X požadavků za den nebo hodinu.
  2. Sledujte případné nárůsty žádostí na společnost za časové období.
  3. Definujte krok postupů, které by se vyskytly při potenciálních podvodných činnostech.
  4. Znovu klíč, znovu klíč a znovu klíč.

Cílem neúspěchu (to se stane nejlepším) je minimalizovat poškození.

Hodně štěstí.

6
Kurt

Máte právo být skeptičtí ohledně toho, že vaši klienti vkládají své uživatelské jméno/heslo do mobilní aplikace, kterou rozdávají všem svým uživatelům. Jak jste správně identifikovali, pro útočníka by bylo snadné tuto mobilní aplikaci rozebrat, vytáhnout uživatelské jméno/heslo z mobilní aplikace a použít je ve své vlastní aplikaci. Váš klient je bohužel ten, kdo se rozhodne, zda tak učinit, ale náklady jsou uvaleny na vás. Jedná se tedy o externalitu a budete potřebovat nějaký způsob, jak lépe sladit náklady, rizika a pobídky. Níže uvádíme několik návrhů, jak to udělat.

Obecně vzato vidím dvě přijatelná řešení:

  • Převod rizika. U každého klienta stanovte limit počtu žádostí, které od tohoto klienta přijmete. Řekněte klientům, že je jejich odpovědností udržovat své uživatelské jméno/heslo v bezpečí, že všechny žádosti, které dorazí pomocí tohoto uživatelského jména/hesla, budou započítány do jejich limitu, a pokud přijde příliš mnoho žádostí, může být jejich účet deaktivován. Řekněte jim, že pokud vloží své uživatelské jméno/heslo do mobilní aplikace, existuje riziko, že někdo nebezpečný může ukrást uživatelské jméno/heslo a použít jej k mnoha žádostem, což způsobí, že jeho účet bude deaktivován a mobilní aplikace přestane fungovat. . Nechte je rozhodnout, zda chtějí riskovat nebo ne.

  • Smluvní požadavky. Řekněte svým klientům, že mají zakázáno sdílet své uživatelské jméno/heslo s ostatními, a není přípustné vkládat své uživatelské jméno/heslo do aplikací, které si mohou ostatní stáhnout. Řekněte jim, že pokud zjistíte jakékoli porušení těchto zásad, může být jejich účet zablokován a mohou jim být vyúčtovány veškeré náklady, které tím vzniknou vašim serverům.

    Pokud chcete, aby vaši klienti vytvořili mobilní aplikaci, sdělte svým klientům, že místo vkládání vlastního uživatelského jména/hesla do mobilní aplikace by měli takové požadavky proxy serverem proxy. Jinými slovy, klient by měl nastavit server, který zná uživatelské jméno/heslo klienta, ale toto uživatelské jméno/heslo by nemělo být vloženo do mobilní aplikace. Mobilní aplikace klienta by se měla autentizovat na klientském serveru, odeslat požadavek na server a poté by server měl požadavek předat vám a předat odpověď zpět mobilní aplikaci. Jejich server by měl ověřovat koncového uživatele (např. Vyžadovat, aby každý koncový uživatel mobilní aplikace vytvořil účet na svém serveru s vlastním uživatelským jménem/heslem). Jejich server by měl stanovit omezení šířky pásma na uživatele a zakázat účet všech koncových uživatelů, kteří tyto limity překročí.

Můžete také klientům umožnit, aby si vybrali mezi těmito dvěma možnostmi: např. Mezi účtem s omezenou šířkou pásma (s přenosem rizika) nebo účtem s neomezenou šířkou pásma (s požadavkem nevkládat uživatelské jméno/heslo do aplikací, které jsou dostupné ostatním) ).

Doufám, že to dává smysl. To může být trochu matoucí, protože existují tři strany - vy, váš klient a koncový uživatel vašeho klienta - každý se svými vlastními zájmy a obavy. Doufám, že jsem dostatečně rozlišil mezi všemi třemi.

3
D.W.

Zabezpečení dat při přenosu pomocí SSL již zahrnovalo útok typu man-in-middle. Hesla pevně zakódovaná ve zdrojovém kódu nejsou přesto bezpečnou praxí. Neměli byste se starat o IP adresu uživatelů nebo IMEI. Nemluvme o sledování a pokusme se opravit věci na prvním místě.

Jak jste řekl, používáte REST. Doufám, že vám pomůže jen pár věcí.

  1. Ověřte uživatele ze strany serveru. Udržujte přísné správy relací, aby nemohly být falšovány. Podívejte se na to OWASP.
  2. Proveďte fuzz test pro vaše API. ReST je známý pro několik slabých míst. Prozkoumejte je na internetu a seznamte se s většinou známých chyb v programu ReST. Oprava těchto problémů pro vaše API.
  3. Vaše SSL věc je dobrá, že chrání vaše data uprostřed.

S zdrojovým kódem si nemusíte dělat starosti. Může to být stejně vytrhnuto, ale to je v pořádku. Vaše hlavní funkce musí běžet na serveru a pouze předávat odpovědi klientům. Zachovejte všechny dobré věci na straně serveru.

1
mojo

Jedním z problémů, které si myslím, že na mobilní frontě budete čelit, je ověření IP adresy. Obvykle budou mobilní IP adresy přidělené telefonem započteny. Síťová IP způsobí, že mechanismus ověření IP přijatý na straně serveru nebude použit.

Chcete-li implementovat řešení na Android a Iphone's; myslím, že přístup by měl být:

  1. Nechte autentizaci klientského serveru v režimu SSL rozšířit i na ověření klientského certifikátu. Mám na mysli nechat klient i server používat certifikáty k vytvoření bezpečné relace SSL.
  2. Doručte PFX/P12 obsahující klientský certifikát (mobilní) tak, aby vyžadoval PIN a kombinaci čísel IMEI a IMSI. Pro útočníka bude tedy obtížné odmítnout stejné sezení.
  3. Nechte implementovat nějakou AI na serveru, která detekuje dvě nebo více souběžných relací zahájených pomocí stejného klientského certifikátu, který vám dá vědět, že došlo k určitému kompromisu, a server může okamžitě černou listinu nebo zrušit certifikát pro další použití.

Věřím, že jsme diskutovali o mobilním prostředí; kromě ověření IP jsou rizika přítomna také v prostředí PC. V budoucnu můžete také přijmout nebo migrovat na implementaci založenou na podpisech a klientských certifikátech v prostředí PC, pokud se u klientů vyskytnou nějaké problémy s fakturací.

1
Mohit Sethi

Podvod je obrovský a nelze jej řešit pouze technickou implementací, ale pokud jste implementovali eskalované ověření IP a zablokování, pak se nemusíte obávat. Rovněž nesmíte svým klientům (B2B) poskytovat skutečné přihlašovací údaje. Dovolte mi vysvětlit, proč a jak.

Z mého porozumění tomu, co jste napsali, byly základní a průměrné bezpečnostní koncepty a implementace již použity na straně B2B (YOURCOMPANY - YOURCLIENT). To je dobré. Ověření IP, SSL/TLS, Uživatel/Pass atd. Nyní se obáváte, že přihlašovací údaje API, které používají vaši klienti k poskytování mobilních aplikací koncovým uživatelům, mohou být chybné tak, že by koncový uživatel třetí strany mohl využít tato pověření, pokud byla nějakým způsobem zneužita mobilní aplikace vašeho klienta.

V podstatě se scvrkává na řadu bezpečnostních vrstev. Otázkou je, jak vaše společnost tyto vrstvy navrhla a implementovala?

  1. Váš SERVER JSON/REST API by měl obsahovat vaše skutečné přihlašovací údaje. Pokud poskytujete službu a potřebujete připojení k poskytovateli sítě/operátorovi, najdete zde také tyto přihlašovací údaje. Víš co myslím.

  2. Nepřidávejte přímý přístup k SERVERU JSON/REST API. Místo toho potřebujete skokový hostitel, který bude sloužit jako hostitel pro důvěryhodné prostředí, server API, ze kterého se nachází vaše aplikace JSON/REST, by se měl na tomto serveru ověřovat POUZE pomocí ověření IP adresy/uzamčení. Autentizace server-server pomocí IP nebo párů veřejného/soukromého klíče. Je na vašem uvážení, co použít.

Tento server by měl také fungovat jako webová služba obsahující sadu uživatelských jmen/hesel, která se poté mapuje do konfiguračního souboru a předává požadavek JER/REST API SERVER. Nyní by YOURCLIENTS měli mít přístup k tomuto serveru také na základě ověření IP/uzamčení a měli by být chráněni pomocí HTTPS. Koncept spočívá v tom, že zde nelze najít žádné pověření skutečného uživatele/průchodu, s výjimkou klíče/tajemství, které mapuje na SERVER API.

  1. YOURCLIENT může mít implementaci zabezpečení z jejich strany ke koncovým uživatelům. Může být ve formě páru veřejných a soukromých klíčů PKI pro vývojáře nebo 2FA pro běžné uživatele. MŮŽETE provádět tyto kroky, nikoli vaši společnost.

Nyní například vývojář třetí strany (koncový uživatel) využil chybu v mobilní aplikaci vytvořené jedním z YOURCLIENT a získal své přihlašovací údaje:

  1. Zbytečný. Pokud jde o to, že za účelem použití přihlašovacích údajů bude vaše IP ověřena.
  2. Neplatný. Pokud jde o to, že musíte být ověřeni prostřednictvím páru veřejných a soukromých klíčů.
  3. Technika eskalace oprávnění bude vyžadovat, aby využíval skutečný server, aby byl důvěryhodný.
  4. Využití skutečného serveru vyžaduje vytvořené techniky, které zpomalí motivaci útočníka.
  5. Neexistuje žádný úspěšný útok, jehož motivace skončila.

Zmatek je dobrý a zpomaluje útok, ale je to nejmenší forma zabezpečení. Měli byste se spolehnout lépe na krypto, které používá klíče.

Pamatujte, že neexistuje žádné absolutní bezpečnostní řešení kromě vašeho neustálého úsilí bojovat proti podvodům z hlediska technické a provozní bezpečnosti.

1
John Santos