CSRF (Cross-Site Request Forgery): Difference between revisions

From ICO wiki
Jump to navigationJump to search
Tollema (talk | contribs)
Tollema (talk | contribs)
No edit summary
Line 15: Line 15:


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 ==
Line 22: Line 23:


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.
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.




Line 43: Line 42:


</source>
</source>


== Kaitse Cross-site request forgery rünnete vastu ==
== Kaitse Cross-site request forgery rünnete vastu ==
Line 55: Line 55:


4. Andmeid muutvate päringute puhul on soovitatav kasutada POST meetodit – see välistab lihtsamaid rünnakud.
4. Andmeid muutvate päringute puhul on soovitatav kasutada POST meetodit – see välistab lihtsamaid rünnakud.


== Kasutatud kirjandus ==
== Kasutatud kirjandus ==

Revision as of 21:56, 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.2007 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