it-swarm-eu.dev

Soubory cookie zabezpečené relace

Při vyhledávání metod vytváření bezpečných relačních souborů cookie jsem narazil na tuto publikaci: A Secure Cookie Protocol . Pro relační soubor cookie navrhuje následující vzorec:

cookie = user | expiration | data_k | mac

kde

  • | Označuje zřetězení.
  • user je uživatelské jméno klienta.
  • expiration je doba vypršení platnosti souboru cookie.
  • data_k Jsou šifrovaná data, která jsou přidružena k klientovi (například ID relace nebo informace o nákupním košíku), šifrovaná pomocí klíče k.
    • k je odvozeno od klíče privátního serveru sk; k = HMAC(user | expiration, sk).
    • data_k Mohl být šifrován pomocí AES pomocí klíče k.
  • mac je HMAC cookie k ověření autentičnosti cookie; mac = HMAC(user | expiration | data | session-key, k).
    • data jsou nešifrovaná data spojená s klientem.
    • session-key Je klíč relace SSL.
  • HMAC je HMAC-MD5 nebo HMAC-SHA1.

Podle příspěvku poskytuje důvěrnost souborů cookie a zabraňuje útokům na přehrání a svazky. Pro mě (jako amatér v zabezpečení/kryptografii) to vypadá docela dobře. Jak dobrá je tato metoda pro relační soubory cookie nebo soubory cookie obecně?

35
user369450

Ano, vypadá to jako docela dobrý systém ochrany souborů cookie.

Další novější schéma v této oblasti je SCS: Secure Cookie Sessions for HTTP , což je solidní schéma, velmi dobře promyšlené. Doporučuji, abyste si přečetli diskusi o bezpečnosti tohoto dokumentu, abyste získali dobrý přehled o tom, jaké bezpečnostní hrozby mohou být.

Abychom vám pomohli pochopit účel a roli schématu souborů cookie, které zmiňujete, dovolte mi zálohovat se a poskytnout některé souvislosti. Je běžné, že webové aplikace musí udržovat stav relace: tj. Nějaký stav, jehož životnost je omezena na aktuální relaci a která je vázána na aktuální relaci. Stav relace lze udržovat dvěma způsoby:

  1. Uložení stavu relace na serveru. Webový server napájí prohlížeč souborem cookie relace: soubor cookie, jehož jediným účelem je držet velký, nevyčíslitelný bitový řetězec. který slouží jako identifikátor relace. Server udržuje vyhledávací tabulku s jednou položkou na otevřenou relaci, která mapuje z identifikátoru relace na všechny stavy relace spojené s touto relací. To usnadňuje kódu webové aplikace načítání a aktualizaci stavu relace spojené s konkrétním požadavkem HTTP/HTTPS. Většina rámců webových aplikací poskytuje vestavěnou podporu pro ukládání stavu relace na straně serveru.

    Toto je nejbezpečnější způsob uložení stavu relace. Protože je stav relace uložen na serveru, klient k němu nemá přímý přístup. Proto útočníci nemohou číst nebo manipulovat se stavem relace (nebo přehrát staré hodnoty). Vyžaduje synchronizaci stavu relace na všech serverech, pokud je vaše webová aplikace distribuována do více výpočetních uzlů typu back-end.

  2. Uložení stavu relace do klienta. Druhým přístupem je vložení stavu relace do souboru cookie a odeslání souboru cookie do prohlížeče. Nyní bude každá následující žádost prohlížeče zahrnovat stav relace. Pokud webová aplikace chce změnit stav relace, může do prohlížeče odeslat aktualizovaný soubor cookie.

    Pokud je provedeno naivně, jedná se o obrovskou bezpečnostní díru, protože umožňuje škodlivému klientovi prohlížet a upravovat stav relace. První je problém, pokud jsou ve stavu relace obsažena důvěrná data. To je problém, pokud server jakýmkoli způsobem důvěřuje nebo spoléhá na stav relace (například zvažte, zda stav relace obsahuje uživatelské jméno přihlášeného uživatele a bit, který označuje, zda je tento uživatel správcem nebo ne; pak by škodlivý klient mohl obejít mechanismus ověřování webové aplikace).

    Záměrem návrhu, který zmiňujete, a systému SCS je co nejvíce bránit těmto rizikům. Mohou tak učinit způsobem, který je většinou úspěšný. Nemohou však zabránit škodlivému klientovi v vymazání souboru cookie (a tedy vymazání stavu relace). Rovněž nemohou zabránit škodlivému klientovi v nahrazení starší hodnoty souboru cookie (a tedy obnovení stavu relace na starší hodnotu), pokud starší verze pochází ze stejné relace. Proto musí vývojář webové aplikace znát tato rizika a starat se o to, jaké hodnoty jsou uloženy ve stavu relace.

Z tohoto důvodu je ukládání stavu relace do souborů cookie o něco riskantnější než ukládání na server, i když k ochraně souborů cookie používáte jedno z těchto kryptografických schémat. (Pokud však budete ukládat stav relace do souborů cookie, určitě doporučujeme použít jedno z těchto dvou schémat k ochraně hodnot v souborech cookie. )

Proč by někdo ukládal stav relace do souborů cookie, vzhledem k tomu, že může být stejně snadno uložen na straně serveru? Většinu času není důvod. V některých výjimečných případech - jako je například HTTP server, který je extrémně omezen na množství úložiště, které má, nebo ve webových aplikacích s vyváženým zatížením, které jsou distribuovány na více počítačích bez dobré podpory stavu synchronizované relace - může existovat důvodné důvody pro zvážení uložení stavu relace do souborů cookie a poté je vhodné použít jeden z těchto schémat.

P.S. Související téma: Pokud používáte ASP.NET View State , ujistěte se, že jste jej nakonfigurovali tak, aby bylo šifrováno a ověřeno: tj. nakonfigurujte ViewStateEncryptionModeAlways a EnableViewStateMactrue; pokud používáte více serverových uzlů, vygenerujte silný kryptografický klíč a nakonfigurujte machineKey každého serveru pro použití tohoto klíče . Nakonec se ujistěte, že máte aktuální verzi rámce ASP.NET; starší verze měl vážnou bezpečnostní chybv krypto ViewState .

30
D.W.

Jaký problém se snažíte vyřešit?

Mohu myslet na dvě věci:

  1. Chcete nastavit bezpečné uživatelské relace. V tomto případě pravděpodobně ani nebudete muset generovat své vlastní soubory cookie relací - mohou být generovány prostřednictvím SSL relace s vaším serverem a jsou obecně zabezpečené pro všechny potřeby webových stránek. Stačí se ujistit, že web implementuje SSL správně a používáte dobře známou metodu generování relací, jakou lze nalézt v běžných jazycích, jako PHP nebo ASP).
  2. Chcete uložit bezpečná data do cookie pro pozdější načtení. Zabezpečení je mnohem obtížnější kvůli mnoha problémům s cookies. Je lepší místo toho ukládat na straně serveru a přiřadit data k uživateli pomocí jiné metody. Pokud to musíte udělat, metoda, kterou popisujete, vypadá celkově celkem dobře, i když nejsem jasná, jak brání opakovaným útokům nebo jiným útokům, jako je člověk ve středu, jakým SSL dělá.

Neváhejte mě kontaktovat přímo, chcete-li diskutovat více.

4
Charlie B

Součástí metody, kterou navrhují, je použití klíče relace SSL jako součásti šifrovaného užitečného zatížení - ale to trvá pouze po dobu relace SSL - tj. Tuto metodu nelze použít pro soubory cookie určené k pokrytí více než jedné relace prohlížeče. Také to není úplně triviální; abyste se zmocnili klíče relace SSL, zejména ukončení protokolu SSL je někde jinde než na serveru http.

V praxi je mnohem jednodušší použít náhodnou hodnotu pro soubor cookie jako popisovač dat uložených na serveru. To může být vázáno na věci jako hash agenta prohlížeče a netname (ne IP adresa) klienta. A/nebo, pokud je to nutné, klíč relace SSL na serveru. Není třeba šifrovat všechna tato data a odesílat je klientovi.

2
symcbean

Toto je rozumná implementace, protože řeší problémy:

  • Nevyjádření (ověření hodnoty nebylo změněno)
  • Důvěrnost (šifrovaný obsah nelze přečíst)

Informace o uživateli jsou však trochu slabé a pokud nejsou začleněny do zašifrované informace pro pozdější srovnání, mohly by být ohroženy.

Největší problémy s cookies nebo jakýmikoli daty přístupnými klientovi je, že je klient (hacker) může modifikovat nebo kopírovat. Únos relace je snadno proveditelný navzdory SSL (jak bylo dříve komentováno jako dostatečné - což není). Různé formy malwaru, man-in-the-middle, man-in-the-browser a další útoky mohou zachytit soubor cookie relace, zkopírovat jej do jiného počítače a nyní mohou tuto relaci „vlastnit“. Pro systém souborů na kartě, jako je Amazon, to může být problematické.

Aby byla smyčka tohoto návrhu uzavřena, musí být identifikace klienta přiměřeně jedinečná a poté vázána na data v šifrované sekci, aby jinému počítači nemohl ukradnout cookie relace. Kromě toho se zdá, že komponenty návrhu jsou zdravé.

0
Darrell Teague