CSRF (Cross-Site Request Forgery): Difference between revisions
m moved CSRF to CSRF (Cross-Site Request Forgery) |
|||
| Line 11: | Line 11: | ||
== Ajalugu == | == Ajalugu == | ||
CSRF nõrkused ja esimesed rünnakud selles valdkonnas on teada alates 2001.aastast. Rünnakuid on avalikult registreeritud 2007.aastast. | CSRF nõrkused ja esimesed rünnakud selles valdkonnas on teada alates 2001.aastast. Rünnakuid on avalikult registreeritud 2007.aastast. Sama aasta alguses leiti CSRF auk Gmailist, mida ära kasutades sai ligipääsu kõikidele konto kontaktidele. Google'il oli URL, mille laadimisel sai tulemuseks JavaScripti koodi kõigi | ||
sisseloginud kasutaja kontaktidega. | sisseloginud kasutaja kontaktidega. | ||
2008.aastal varastati CSRF ründega 18 miljoni eBay kasutaja isikuandmed. Teine suurem rünnak toimus sellel aastal veel, kui Mehhiko panga kliendid suunati emailist saadud pildi lingi kaudu võltsitud veebilehele, mis teeskles panka. | 2008.aastal varastati CSRF ründega 18 miljoni eBay kasutaja isikuandmed. Teine suurem rünnak toimus sellel aastal veel, kui Mehhiko panga kliendid suunati emailist saadud pildi lingi kaudu võltsitud veebilehele, mis teeskles panka. | ||
== CSRF tüüpi ründed == | == CSRF tüüpi ründed == | ||
Revision as of 21:58, 19 May 2014
Autor
Nimi: Tiina Ollema
Rühm: A21 (2013/2014)
Sissejuhatus
OWASP (Open Web Application Security Project) on Cross-site request forgery ründed liigitanud 2013 Top10 seisuga kaheksandale kohale.
Cross-site request forgery, tuntud ka kui one-click rünne või sessioon ärandamine on rünne, mille käigus kasutatakse ära veebilehe usaldust kasutaja vastu ning petetakse laadima veebilehte, mis annab võimaluse ründajal tegutseda kasutaja nimel ja õigustega ning muutusi vastavas süsteemis.
Ajalugu
CSRF nõrkused ja esimesed rünnakud selles valdkonnas on teada alates 2001.aastast. Rünnakuid on avalikult registreeritud 2007.aastast. Sama aasta alguses leiti CSRF auk Gmailist, mida ära kasutades sai ligipääsu kõikidele konto kontaktidele. Google'il oli URL, mille laadimisel sai tulemuseks JavaScripti koodi kõigi sisseloginud kasutaja kontaktidega.
2008.aastal varastati CSRF ründega 18 miljoni eBay kasutaja isikuandmed. Teine suurem rünnak toimus sellel aastal veel, kui Mehhiko panga kliendid suunati emailist saadud pildi lingi kaudu võltsitud veebilehele, mis teeskles panka.
CSRF tüüpi ründed
Ründaja loob võltsitud HTTP päringuid ja petab ohvrit neid kasutama pildi tag'ide, XSS-i ja paljude teiste moodustega. Kui kasutaja on autenditud, siis rünnak õnnestub.
CSRF kasutab ära seda, et enamik veebirakendusi lubavad ründajatel ennustada kindlate tegevuste detaile. Kuna brauserid saadavad volitusi nagu sessiooni cookies'i automaatselt, siis ründajad saavad luua pahatahtlike veebilehekülgi, mis on eristamatud õigetest veebilehekülgedest.
CSRF nõrkuste avastamiseks saab kasutada koodi testimist ja analüüsi, kuid sealt vigade leidmine on raskem kui SQL injection ja XSS rünnete puhul, sest nende tuvastamiseks on erinevaid rakendusi ja tööriistu.
Näited CSRF rünnetest
Ohvri kontolt kantakse raha ründaja kontole
<img src="'''http://example.com/app/transferFunds? amount=1500&destinationAccount=attackersAcct#'''“ width="0" height="0" />
Kustutakse kasutaja andmeid
<img src="'''http://www.mysite.org/do?action=delete&itemID=344'''" />
Muudetakse kasutaja andmeid
<iframe src="'''http://www.georgesrecipes.com/edit.php'''" />
Kustutatakse kasutaja andmeid
<script src="'''http://www.mysite.org/do?action=delete&itemID=344'''"></script>
Kaitse Cross-site request forgery rünnete vastu
CSRF rünnete eest kaitsmiseks on tavaliselt vaja ettearvamatu sümboli lisamist igasse HTTP taotlusesse. Lisaks peaksid need sümbolid olema unikaalsed igal kasutajal sessiooni kohta.
1. Unikaalse sümboli lisamine peidetud väljale, mis takistab pahatahtlikke lisamisi URL-ile.
2. Unikaalse sümboli lisamine URL-i või URL-i parameetrile, aga see jätab siiski ohu, et URL paljastatakse ründajale.
3. Kasutaja peab peab uuesti autentima ennast või tõestame, et ta on kasutaja(nt CAPTCHA abil)
4. Andmeid muutvate päringute puhul on soovitatav kasutada POST meetodit – see välistab lihtsamaid rünnakud.
Kasutatud kirjandus
- http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf - OWASP TOP10 2013
