4 komentáře “Prolomení šifrovaného protokolu HTTPS

  1. Asi jsem nepochopil, jak chcete pracovat s tím CSRF zamaskovaným XORem. Když mám konstantní CSRF=abc, salt=def a abc XOR def dává 753, pak také def XOR 753 dává abc. Útočník zná def i 753, může tedy vypočítat abc – a pak si může vymyslet vlastní salt a vypočítat požadovanou hodnotu. Abych tomu zabránil, musel bych si pamatovat, ke které stránce patří který salt, ale to už to můžu rovnou použít jako CSRF.

    • To už je třetí reakce v podobném duchu (na různých portálech) – tak jsem to asi nevysvětlil dostatečně srozumitelně. XOR v tomto případě neslouží jako šifra – to by byl samozřejmě VELKÝ nesmysl. XOR zde slouží jen k tomu, aby se hodnota CSRF v response zamaskovala.

      Celý útok spočívá v tom, že útočník sleduje side channel, kterým si odvozuje, jak daleko se trefil do nějakého řetězce, který je ve výstupu stránky.

      Útočník nemůže přímo přečíst obsah CSRF kvůli Cross-origin politice browseru, nemůže ani použít ani MITM útok, protože je použito HTTPS. Nicméně díky kompresi může zjistit, nakolik trefil shodný řetězec z toho, jak rychle se mu vrátí odezva serveru (tzn. jestli se vešel nebo nevešel do X TCP packetů).

      Tj. když bude zkoušet hádat CSRF token, který je obalen v:

      <input type=“hidden“ name=“_csrf“ value=“ABC“/>

      Tak si nejdřív zjistí, kolik musí poslat znaků, aby zarovnal odezvu na hranici X TCP packetů a potom bude zkoušet:

      <input type=“hidden“ name=“_csrf“ value=“A … trefa, vešel se do X packetů
      <input type=“hidden“ name=“_csrf“ value=“AA … netrefa, nevešel se do X packetů
      <input type=“hidden“ name=“_csrf“ value=“AB … trefa, vešel se do X packetů
      <input type=“hidden“ name=“_csrf“ value=“ABA … netrefa, nevešel se do X packetů
      <input type=“hidden“ name=“_csrf“ value=“ABB … netrefa, nevešel se do X packetů
      <input type=“hidden“ name=“_csrf“ value=“ABC … trefa, vešel se do X packetů

      A to tak dlouho, až získá celý CSRF token.

      Pokud ale na serveru zamaskujeme CSRF token náhodným saltem přes XOR, tak výstup bude při shodném CSRF tokenu v každém výstupu vždy odlišný, takže útočník bude mít smůlu.

      Tento přístup nám navíc nijak nezkomplikuje práci na serveru – i když díky partial update obnově obsahu stránek dostaneme v rámci requestu nějaký starší zašifrovaný token, dokážeme původní CSRF snadno rekontruovat, protože v tokenu jde i původní varianta saltu.

      Je to takto už srozumitelnější?!

      • Jasně, XOR je tam proto, aby byl výstup pokaždé jiný, čímž se prakticky znemožní útok přes kompresi. Už to chápu, díky!

      • Super, to jsem rád. Poučení pro mě, že na srozumitelnosti článků musím dále pracovat.

Napsat komentář