it-swarm-eu.dev

Zabezpečení aplikace pro jedinou stránku JavaScriptu pomocí RESTful backendu

V současné době připravuji JavaScript SPA a zkoumám, jak jej zabezpečit. V současné době existuje rozhraní RESTful API, se kterým je prostřednictvím AJAX zcela interagováno. Máme také mobilní klienty, kteří spolupracují s tímto rozhraním API, a v současné době podporuje pouze ověřování HTTP BASIC prostřednictvím protokolu SSL. Aplikace JavaScript bude také komunikovat výhradně přes SSL, ale BASIC Auth jej neřeže, protože by to vyžadovalo uložení hesla (nebo jeho derivátu) na klienta. A konečně, aplikace SPA bude čistý JavaScript a HTML, bude se zobrazovat na stejném serveru jako rozhraní RESTful API, ale bez jakéhokoli rámce na straně serveru.

Cíle :

  • Žádný rámec na straně serveru pro klienta javascript (je to jen další klient).
  • Udržujte bezdomovectví rozhraní RESTful API z typických důvodů (škálovatelnost, odolnost proti chybám, zjednodušené nasazení atd.)
  • Klient by měl udržovat jakýkoli stav. Pro účely této otázky to znamená přihlašovací údaje.
  • Stav přihlášení udržovaný klientem musí být bezpečný a odolný proti únosům relací a podobným útokům.

To, co jsem přišel, je na základě mého výzkumu OAuth a podobných schémat (Amazon atd.).

  1. Uživatel se přihlásí pomocí HTTP POST přes SSL).
  2. Server vypočítá hash následujícím způsobem:

    HMAC (klíč, userId + ":" + ipAddress + ":" + userAgent + ":" + todaysDateInMilliseconds)

  3. Tento token bude vrácen klientovi a bude dodán s každou další žádostí namísto uživatelského jména a hesla. Pravděpodobně bude uložena v localStorage nebo v cookie.

Je to bezpečné? Moje motivace pro volbu userId, ipAddress, todaysDateInMilleseconds je vytvořit token, který je platný pouze dnes, ale nevyžaduje vyhledávání databáze pro každý požadavek A je bezpečné, aby byly uloženy na klientovi. Nemůžu uvěřit, že klíč nebude komprimován, a proto zahrnutí IP adresy do pokusu zabránit únosu relace.

Dovolte mi, abych zahrnul následující odkaz z souvisejícího příspěvku na StackExchange, protože se domnívám, že řeší mnoho problémů, které se snažím vyřešit: REST a Stateless Session Ids

Po úvodní zpětné vazbě jsem se rozhodl použít pouze první dva oktakty IP adresy, abychom lépe zvládali klienty za servery proxy a mobilní klienty. Stále to není dokonalé, ale je to kompromis pro další zabezpečení.

68
Jon Wingfield

Služba nabízená tokenem je, že server nějakým způsobem rozezná token jako svůj vlastní. Jak může server ověřit token založený na HMAC? Jeho přepočítáním pomocí tajného klíče HAMC a dat, nad nimiž HMAC pracuje . Pokud chcete, aby byl váš token vypočítán pomocí ID uživatele, hesla, IP a data, musí server znát všechny tyto informace. Nechcete však, aby server ukládal heslo a klient jej neodešle zpět s každou žádostí. Jak tedy může váš systém fungovat?

Základní myšlenkou je však zvuk:

  • Uživatelé se přihlašují jakýmkoli způsobem, který považujete za vhodný.
  • Po takovém přihlášení server odešle hodnotu souboru cookie, která má být odeslána s každou další žádostí (to je to, co cookies dělají).
  • Soubor cookie obsahuje ID uživatele, datum vydání a hodnotu m = HMAC (K, ID uživatele || datum || IP) .
  • Když server obdrží požadavek, ověří cookie: userID a datum jsou ze samotného cookie, zdrojová IP je získána z vrstvy webového serveru a server může přepočítat hodnotu m a zkontrolujte, zda odpovídá souboru uloženému v souboru cookie.

Pokud má server nějaký (dočasný) úložný prostor, můžete celý soubor cookie nahradit náhodným ID relace. Server si mohl pamatovat mapování z náhodného ID relace na informace specifické pro uživatele (jako je jeho jméno a IP adresa); staré ID relace může být automaticky vypršelo, takže úložný prostor neroste donekonečna. Soubor cookie popsaný výše je pouze způsob, jak vyložit úložiště na samotném klientovi.

Poznámka: Použití adresy IP může znamenat některé praktické problémy. Někteří klienti jsou za servery proxy, dokonce s vyrovnanými zátěžovými servery proxy, takže nejen je IP adresa klienta možná „skrytá“ (ze serveru vidíte adresu proxy, nikoli adresu klienta), ale i IP adresa, kterou získáte na straně serveru, pohybovat se nepravidelně (pokud dvě po sobě jdoucí žádosti od klienta prošly zřetelnými proxy servery v proxy farmě).

30
Thomas Pornin

Existuje mnohem jednodušší řešení:

Používejte SSL na celém webu a poté použijte standardní sledování relací ve vašem rámci.

To je vše, co musíte udělat.

Podrobněji se uživatel nejprve přihlásí zadáním svého uživatelského jména a hesla; dostane POSTed na server, který může zkontrolovat jeho platnost. Pokud je ověření úspěšné, váš serverový kód nastaví ve stavu relace příznak, který si pamatuje, že uživatel úspěšně autentizoval a zapamatoval si uživatelské jméno uživatele. Všechny následující požadavky budou přes stejnou relaci, takže je můžete snadno ověřit a nechat je pokračovat.

(Ještě podrobnější informace: Pokaždé, když obdržíte požadavek, zkontrolujete stav relace, abyste zjistili, zda se uživatel úspěšně autentizoval a je oprávněn tuto akci provést. Pokud ano, povolíte požadavek a akci provedete; pokud ne, přesměrujete uživatel na přihlašovací stránku nebo zobrazí nějakou jinou chybovou zprávu.)

Všimněte si, že to splňuje všechny vaše požadavky. Nevyžaduje vyhledávání databáze při každém požadavku. Je kompatibilní s RESTful API. Je kompatibilní s jednostránkovou aplikací. Nemusíte kódovat nic fantastického: stačí použít existující podporu vaší relace pro relace (obvykle používá soubor cookie relace s jedinečným ID relace a nějaký mechanismus ukládání stavu na straně serveru spojený s tímto ID relace) .

V rámci používání SSL na celém webu byste měli nastavit příznak secure v souboru cookie ID relace, abyste jej ochránili před odposloucháváním (zajistíte tak, že nebude nikdy odesílán přes HTTP). Měli byste také povolit HSTS, aby prohlížeč řekl, aby na vašem webu vždy používal SSL. Vyhledejte na tomto webu další informace o tom, jak nasadit SSL na celém webu.

Neměli byste se spoléhat na to, že IP adresa klienta je statická. Může se změnit, např. Pokud je klient mobilní a přesouvá se z jedné bezdrátové sítě do druhé. Proto je nejlepší se vyhnout použití IP adresy klienta pro cokoli.

9
D.W.

Zkontrolujte tento příspěvek Používání OAuth2 v HTML5 webové aplikaci . @jandersen odpověď dává dobré vysvětlení použití pověření hesla vlastníka zdroje tok v jednostránkových aplikacích. V každém případě by upřednostňovaným tokem pro tyto aplikace měl být Implicitní grant . Ve skutečnosti @jandersenova odpověď na odkazovaný příspěvek je o vylepšení pověření vlastníka zdroje, aby fungovalo jako něco blízkého implicitnímu grantu.

3
Daniel Cerecedo