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ář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

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