HTTPS protokol prolomen?!
Možná jste někteří z vás zaznamenali před několika lety útok Breach, který využívá vedlejších efektů komprimace souborů přenášených po síti k odhalení chráněných informací v nich. Loni v létě všemu nasadila nová útočná technika zvaná Heist, která Breach útok umožňuje provést pomocí JavaScriptu umístěného klidně mimo doménu, na kterou se útočí. HTTPS protokol není schopen sám o sobě citlivý údaj v současné době ochránit, pokud proto vy sami něco neuděláte.
Vzhledem k tomu, že v českých luzích a hájích o tomto typu útoku není zatím mnoho informací, troufl jsem si sepsat nástin této útočné techniky v článku.
Jakmile ctu o sifrovani XORem zaviram okno prohlizece :(
No ještě, že si stihl napsat ten komentář! 8-)
Š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 ;)
Řešením by mohly být SameSite cookie, které teda měly přijít už mnohem dřív, teď je pozdě. https://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/
Souhlasím, v závěru článku to také zmiňuji. Chrome a Opera to již podporují, i když je to podle mě pořád W3C proposal pouze: http://caniuse.com/#feat=same-site-cookie-attribute
Nicméně my už to do našich webů dávat začneme. Tady nemá smysl na cokoliv čekat :)
Pokud chápu správně, tak CSRF token je složen z tokenu, který je pro session stejný, tak že:
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.
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ší?!
Už ano díky, za vysvětlení.