8 komentářů k článku HTTPS protokol prolomen?!:

    1. Jan NovotnýAutor příspěvku

      Re: XOR
      Škoda – při lepším přečtení byste se dozvěděl, že XOR není použit na šifrování, ale maskování CSRF tokenu tak, aby byl v každé odpovědi unikátní a tudíž se nedalo opakovanými pokusy docílit jeho rekonstrukci. Navíc toto řešení je plánováno i do knihovny Spring Security (https://github.com/spring-projects/spring-security/issues/4001), což je defakto „industry standard“ pro Java aplikace postavné na Spring frameworku.

      Každopádně budu rád za konstruktivní kritiku ;)

  1. Janek Ledecký

    CSRF
    Pokud chápu správně, tak CSRF token je složen z tokenu, který je pro session stejný, tak že:

    • pro každý request vygenerujeme náhodnou Salt
    • token pro každý request tedy bude = XOR(‚neměnný token‘, ‚salt‘) . ‚salt‘

    Z toho mi vychází že, když znám tento algoritmus, stačí mi ukradený csrf token, rozdělit na polovinu, 2. polovina je salt, pak stačí XOR(‚1. polovina‘, ‚2. polovina‘) a výsledkem je TOKEN, který je pro session neměnný.

    Tomu stačí vygenerovat ‚mojí náhodnou Salt‘, vypočítat XOR a spojit a mám v ruce TOKEN který projde vždy, takže už asi neni moc CSRF, ne?

    Opravte mě prosím jestli se v něčem pletu.

    1. Jan NovotnýAutor příspěvku

      Re: CSRF
      Doprčic WordPress mi odmazal tagy :) … může nějaký admin odmazat předchozí komentář?! Níže je oprava:

      XOR v tomto případě neslouží jako šifra pro CSRF token – 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 rekonstruovat podle logiky jakou jsi popsal, protože v tokenu jde i původní varianta saltu.

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

Napsat komentář

Zdroj: https://www.zdrojak.cz/?p=19484