Hacking af CSRF-tokens ved hjælp af CSS History Hack

Opdatering: Sikkerhedsforskere Sirdarckcat og Gareth var venlige nok til at dele koden til en ren CSS-baseret CSRF-token finder her. Dette er stealthier end min PoC nedenfor, der brugte en kombination af både JS og CSS. Så det fungerer stadig, selvom du deaktiverer javascript, og du ikke er mere sikker :(:( . For at gøre denne PoC mere lydhør over for klienten skal du bruge flere CSS-stilark ved hjælp af importkommandoen. Det eneste problem, jeg ser med denne rene CSS-baserede tilgang, er, at der vil være netværksforsinkelse involveret i store nøglepladser, fordi dit store CSS-stilark skal downloades af din browser.


Jeg tænkte på problemet med forfalskning på tværs af anmodninger og aktuelle begrænsningsstrategier, der blev brugt i branchen. I mange af de virkelige verden-applikationer, jeg hidtil har testet, ser jeg brugen af ​​tilfældige tokens som en del af url. Hvis anmodningen ikke leverer et token eller giver et token med forkert værdi, afvises anmodningen. Dette forhindrer udførelse af CSRF eller nogen uautoriseret funktion på tværs af domæner.

Opdateret nu blev det betragtet som umuligt for en angriber at opdage dit CSRF-token ved hjælp af Brute Force Attacks på serveren.

Årsagerne er:

  1. Det genererer meget støj på netværket og er langsomt. Så sandsynligvis vil en IDS eller Web App Firewall afhente den ondsindede opførsel og blokere din ip. For eksempel genererer et Base16 CSRF-token med længde 5 tegn (startende med et tegn) ca. 393.216 anmodninger.
  2. Mange applikationer er programmeret til ugyldiggør din session efter at det registrerer mere end et vist antal anmodninger med ugyldige tokenværdier. F.eks. 30.

Jeg vil ændre denne tro ved at vise dig en teknik til hurtigt at finde csrf-symboler uden at generere advarsler. Denne teknik er en klient side angreb, så der er næsten ingen genereret netværkstrafik, og derfor vandt din server og IDS / Web App Firewalls’t bemærker det overhovedet. Dette angreb er baseret på den populære CSS History Hack fundet af Jeremiah Grossman for 3 år siden.

I denne udnyttelse opdager vi csrf-tokenet ved brute at tvinge de forskellige sæt urls i browserhistorikken. Vi vil prøve at integrere forskellige csrf-tokenværdier som en del af url og kontrollere, om brugeren har besøgt den url. Hvis ja, er der en god chance for, at brugeren enten bruger det samme CSRF-token i den aktuelle aktive session eller muligvis har brugt det token i en tidligere session. Når vi først har en liste over alle sådanne tokens, kan vi bare prøve vores csrf-angreb på serveren ved hjælp af den lille liste. I øjeblikket er dette angreb muligt for tokens med en længde på 5 tegn eller kortere. Jeg prøvede det på en base16 streng med længde 5 og var i stand til at brute tvinge hele nøglerummet på mindre end 2 minutter.

Nogle af forudsætningerne for at dette angreb kan fungere er enten

  1. CSRF-token forbliver den samme for en bestemt brugersession. f.eks. csrf token = hash (session_id) ELLER
  2. CSRF-token indsendt i ældre formularer til den samme session accepteres. Mange gange er dette tilfældet, da det forbedrer brugeroplevelsen og gør det muligt at bruge browserknapper frem og tilbage.

Bevis for koncept er tilgængelig her.
Før du kører PoC, skal du ændre url- og csrftoken-paramaterværdier.

For test med brug af standardindstillingerne skal du først besøge en af ​​følgende webadresser, f.eks.

  1. https://securethoughts.com/?param1=val1&csrftoken = b59fe [skift b59fe til en 5-cifret base 16-streng, der starter med et tegn, dvs. større end a0000]
  2. http://tinyurl.com/l2lwgd [som er 301 omdirigeret til forrige url].

Bemærk: http://www.securethoughts.com og https://securethoughts.com behandles forskelligt, mens de gemmes i browserhistorikken.

En prøvekørsel vil se sådan ud -

hacking csrf tokens ved hjælp af css historie hackhacking csrf tokens ved hjælp af css historie hack

For at gøre dette angreb umuligt,

Server-side-løsning (for udviklere):

  • Lav dine CSRF-symboler længe nok (8 eller flere tegn) til at være uigennemførelige til et KLIENTSIDE-angreb. Den stadigt stigende processorkraft vil også gøre dette angreb muligt for længere symboler.
  • Gem dit CSRF-token som en del af skjult formfelt i stedet for at indsætte url.
  • Brug et andet tilfældigt token til hver formularindgivelse og accepter ikke noget forældet token, selv ikke for den samme session.

Klient-side-løsning (for dine kunder / brugere):

  • Brug et browserplugin som SafeHistory, der forsvarer mod besøgte link-baserede sporingsteknikker.
  • Brug den private browsertilstand i din browser.

Og sidst, men ikke mindst, udsletter XSS alle mulige CSRF-beskyttelser. Så slippe af med XSS først.

Jeg vil gerne takke Jeremiah for at have leveret hans indsigtsfulde feedback på dette indlæg.

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