it-swarm-eu.dev

Jak by se měli vývojáři webových aplikací bránit proti únosu JSON?

Jaká je nejlepší obrana proti únos JSON ?

Může někdo vyjmenovat standardní obranu a vysvětlit své silné a slabé stránky? Zde jsou některé obrany, které jsem viděl navrhl:

  1. Pokud odpověď JSON obsahuje důvěrná/neveřejná data, odešlete odpověď pouze v případě, že je požadavek ověřen (např. Přichází se soubory cookie, které označují ověřenou relaci).
  2. Pokud data JSON obsahují cokoli důvěrného nebo neveřejného, ​​hostujte je na tajné nezvladatelné adrese URL (např. Adresa URL obsahující 128bitové náhodné číslo v krypto kvalitě) a sdílejte tuto tajnou adresu URL pouze s uživateli/klienty oprávněnými zobrazit data.
  3. Položte while(1); na začátek odpovědi JSON a před analýzou JSON nechte klienta, aby ji vypnul.
  4. Nechte klienta poslat žádosti o data JSON jako POST (nikoli GET)) a nechte server ignorovat žádosti GET pro data JSON.

Jsou všechny bezpečné? Existují důvody k výběru jednoho z nich před ostatními? Jsou nějaké další obrany, které mi chybí?

42
D.W.

První obranou je držet se specifikace pomocí platného JSON, který vyžaduje objekt jako entitu nejvyšší úrovně . Všechny známé útoky jsou založeny na skutečnosti, že pokud je objekt nejvyšší úrovně maticí, odpověď je platná Java kód skriptu, který lze analyzovat pomocí značky <script>).

Pokud odpověď JSON obsahuje důvěrná/neveřejná data, odešlete odpověď pouze v případě, že je požadavek ověřen (např. Přichází se soubory cookie, které označují ověřenou relaci).

To je předpoklad pro útok , ne zmírnění. Pokud prohlížeč má soubor cookie pro web A, bude jej zahrnout do všech požadavků na web A. To platí, i když byl požadavek spuštěn značkou <script> na webu B.

Pokud data JSON obsahují cokoli důvěrného nebo neveřejného, ​​hostujte je na tajné nezvladatelné adrese URL (např. Adresa URL obsahující 128bitové náhodné číslo v krypto kvalitě) a sdílejte tuto tajnou adresu URL pouze s uživateli/klienty oprávněnými zobrazit data.

URL se nepovažují za bezpečnostní prvek . Všechny běžné vyhledávače mají doplňky nebo panely prohlížečů, které hlásí jakoukoli navštívenou adresu URL zpět dodavateli vyhledávače. I když mohou hlásit pouze adresy URL, které jsou explicitně navštíveny, neriskuji to ani pro JSON URLS.

Nechte klienta poslat žádosti o data JSON jako POST (nikoli GET)) a nechte server ignorovat žádosti GET pro data JSON.

To zabrání zahrnutí <script>.

Vložte chvíli (1); na začátku odpovědi JSON a nechte ji klienta před analýzou JSON odstranit.

Navrhuji upravenou verzi tohoto přístupu: Přidejte na začátek </*. while(1) je problematický ze dvou důvodů: Nejprve je pravděpodobné, že spustí maleware scanner (na klientech, proxy serverech a vyhledávači). Za druhé, může být použit pro útoky DoS proti CPU webových surfařů. Tyto útoky zjevně pocházejí z vašeho serveru.

28

Google používá " nepřirozený cruft " k obraně proti tomuto typu útoku. Tato chyba zabezpečení byla opraveno v firefox . Chyba zabezpečení vyplývá z toho, jak prohlížeče implementují specifikaci JSON.

3
rook

1) Pokud odpověď JSON obsahuje důvěrná/neveřejná data, odpovězte pouze v případě, že je požadavek ověřen (např. Přichází s cookies, které označují ověřenou relaci). 2) Pokud data JSON obsahují cokoli důvěrného nebo neveřejného, ​​hostujte je na tajné nezvladatelné adrese URL (např. Adresa URL obsahující 128bitové náhodné číslo v krypto kvalitě) a sdílejte tuto tajnou adresu URL pouze s uživateli/klienty oprávněnými viz data.

Neexistuje žádný dobrý důvod k provedení obou (1) a (2).

První je ABAC a druhý je ZBAC. Pokus o získání hloubkové ochrany pomocí více schémat řízení přístupu je prostě komplikující.

3) Položte while(1); na začátek odpovědi JSON a před analýzou JSON nechte klienta, aby ji vypnul.

4) Nechejte klienta, aby poslal žádosti o data JSON jako POST (nikoli GET)) a nechal server ignorovat žádosti GET pro data JSON.

Zní to jako pěkné nápady a přidávají hloubku obrany, protože to pomáhá zajistit, aby pověření nemohla být zneužita.

Dodatečně,

5) Poskytujte JSON pouze citlivá data prostřednictvím SSL nebo jiného zabezpečeného kanálu.

aby se zabránilo úniku dat přes MITM.

2
Mike Samuel