CSRF-tokenien hakkerointi CSS History Hack -sovelluksella

Päivitys: Turvallisuustutkijat Sirdarckcat ja Gareth olivat tarpeeksi ystävällisiä jakamaan koodin puhdasta CSS-pohjaista CSRF-tunnushakua varten. Tämä on piilevämpi kuin alla oleva PoC, jossa käytettiin sekä JS: n että CSS: n yhdistelmää. Joten se toimii edelleen, vaikka poistat JavaScriptin käytöstä etkä ole enää turvassa :(:( . Jotta tämä PoC reagoisi paremmin asiakkaaseen, sinun on käytettävä useita CSS-tyylitaulukoita tuontakomennon avulla. Ainoa ongelma, jonka näen tässä puhtaassa CSS-pohjaisessa lähestymistavassa, on, että suuriin avaintiloihin liittyy verkon viive, koska selaimesi on ladattava iso CSS-tyylitaulukko.


Ajattelin sivustojen välisen väärentämisen ongelmaa ja teollisuudessa nykyisiä lieventämisstrategioita. Näen monissa toistaiseksi kokeilluissa reaalimaailman sovelluksissa, että satunnaisten tunnusten käyttö on liitetty osana URL-osoitetta. Jos pyynnössä ei anneta mitään tunnusta tai annetaan vääriä arvoisia tunnuksia, pyyntö hylätään. Tämä estää CSRF: n tai minkä tahansa toimialueiden välisen luvattoman toiminnan suorittamisen.

Tähän päivään mennessä hyökkääjän piti mahdotonta löytää CSRF-tunnus palvelimen Brute Force Attacks -palvelun avulla..

Syyt ovat:

  1. Se tuottaa paljon melua verkossa ja on hidasta. Joten todennäköisesti IDS- tai Web App -palomuuri poimii haitalliset toiminnot ja estää IP: n. Esimerkiksi Base16 CSRF -merkki, jonka pituus on 5 merkkiä (alkaa merkillä), tuottaa noin 393 216 pyyntöä.
  2. Monet sovellukset on ohjelmoitu mitätöi istunnosi sen jälkeen kun se on havainnut enemmän kuin tietyn määrän pyyntöjä, joilla on virheelliset tunnusarvot. Esim. 30.

Aion muuttaa tätä uskomusta näyttämällä sinulle tekniikan, jolla voit nopeasti löytää csrf-tokeneja generoimatta hälytyksiä. Tämä tekniikka on asiakaspuolen hyökkäys, joten verkkoliikennettä ei juuri ole luotu ja palvelin ja IDS / Web App -palomuurit voittivat’t huomaa sitä ollenkaan. Tämä hyökkäys perustuu suosittuun CSS History Hackiin, jonka Jeremiah Grossman löysi 3 vuotta sitten.

Tässä hyödynnettäessä löydämme csrf-tokenin raa'alla pakottamalla erilaiset URL-osoitteet selaimen historiaan. Yritämme upottaa eri csrf-tunnusarvot osana URL-osoitetta ja tarkistaa, onko käyttäjä käynyt kyseisessä URL-osoitteessa. Jos kyllä, on suuri mahdollisuus, että käyttäjä joko käyttää samaa CSRF-tunnusta nykyisessä aktiivisessa istunnossa tai on ehkä käyttänyt sitä aiemmassa istunnossa. Kun meillä on luettelo kaikista tällaisista tokeneista, voimme vain kokeilla csrf-hyökkäystä palvelimelle käyttämällä tätä pientä luetteloa. Tällä hetkellä tämä hyökkäys on mahdollinen rahakkeille, joiden pituus on 5 merkkiä tai lyhyempi. Yritin sitä base16-merkkijonolla, jonka pituus oli 5, ja pystyin raa'asti pakottamaan koko avaintalon alle 2 minuutissa.

Jotkut tämän hyökkäyksen toimivuuden edellytykset ovat joko

  1. CSRF-tunnus pysyy samana tietyllä käyttäjäistunnolla. esim. csrf token = tiiviste (session_id) TAI
  2. Samassa istunnossa vanhemmissa muodoissa toimitettu CSRF-tunnus hyväksytään. Tämä on monta kertaa, koska se parantaa käyttökokemusta ja sallii eteen- ja taaksepäin -selainpainikkeiden käytön.

Todistus käsitteestä on saatavilla täältä.
Ennen kuin käynnistät PoC: n, sinun on muutettava url- ja csrftoken-parametriarvot.

Testaaksesi oletusasetuksia, sinun täytyy ensin käydä jollain seuraavista URL-osoitteista, esim.

  1. https://securethoughts.com/?param1=val1&csrftoken = b59fe [vaihda b59fe mihin tahansa 5-numeroiseen kantajonoon 16, joka alkaa merkillä, ts. suurempi kuin a0000]
  2. http://tinyurl.com/l2lwgd [joka on 301 uudelleenohjaus edelliseen URL-osoitteeseen].

Huomautus: http://www.securethoughts.com ja https://securethoughts.com kohdellaan eri tavalla tallennettaessa selaimen historiaan.

Näytejuoksu näyttää tältä -

hakkerointi csrf-tokenien avulla css-historian hakkerointihakkerointi csrf-tokenien avulla css-historian hakkerointi

Jotta tämä hyökkäys oli mahdoton,

Palvelinpuolen ratkaisu (kehittäjille):

  • Tee CSRF-tunnuksistasi riittävän kauan (8 tai enemmän merkkejä), jotta niitä ei voida käyttää CLIENT SIDE -hyökkäykseen. Yhä kasvava prosessointiteho tekee tästä hyökkäyksestä toteutettavissa myös pidempien merkkien ajan.
  • Tallenna CSRF-tunnus osana piilotettua lomakekenttää sen sijaan, että kirjoittaisi URL-osoitetta.
  • Käytä erilaista satunnaista tunnusta jokaisessa lomakkeen lähettämisessä ja älä hyväksy mitään vanhentunutta tunnusta, edes samasta istunnosta.

Asiakaspuolen ratkaisu (asiakkaillesi / käyttäjillesi):

  • Käytä selainlaajennusta, kuten SafeHistory, joka puolustaa vierailtuihin linkkipohjaisiin seurantatekniikoihin.
  • Käytä yksityistä selaustilaa selaimessasi.

Viimeisenä, mutta ei vähäisimpänä, XSS hävittää kaikki mahdolliset CSRF-suojaukset. Joten päästä eroon XSS: stä ensin.

Haluan kiittää Jeremiaa siitä, että hän antoi oivaltavaa palautetta tästä viestistä.

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me