CSRF: ano ito, kung paano ito gumagana, mga halimbawa at depensa

Kung nagtatrabaho ka sa web development o seguridad, gugustuhin mong maging napakalinaw tungkol sa kung ano ang cross-site na pamemeke ng kahilingan. CSRF (Cross-Site Request Forgery) Ito ay isang uri ng palihim na pag-atake na sinasamantala ang nasimulang session ng isang user upang gawin ang kanilang browser ng mga aksyon nang walang pahintulot nila.

Ang hindi pangkaraniwang bagay na ito ay hindi bago, ngunit ito ay nananatiling may kaugnayan dahil ang mga browser ay awtomatikong nag-a-attach ng mga kredensyal gaya ng cookies o mga header sa ilang partikular na kahilingan. Ang server ay "nagtitiwala" sa gumagamit at pinoproseso ang kahilingan, kahit na pinasimulan ito ng isang nakakahamak na pahina, isang iframe, o isang nakatagong link.

Ano ang CSRF at bakit nagdudulot pa rin ito ng kaguluhan?

Sa madaling salita, ang CSRF ay kapag hinikayat ng site A ang browser ng isang napatotohanang user na magpadala ng kahilingan sa site B kung saan naka-log in na ang user na iyon, upang maproseso ng B ang operasyon bilang wasto. Ang susi ay ang tiwala ng site sa user.hindi tiwala ng user sa site.

Hindi tulad ng XSS, na sinasamantala ang tiwala ng user sa isang page para mag-inject at magsagawa ng code sa loob ng konteksto nito, inaabuso ng CSRF ang katotohanang tinatanggap ng server ang anumang kahilingang dumating na sinamahan ng mga wastong kredensyal (hal., cookies ng session)Ang parehong mga problema ay maaaring pagsamahin at lumala ang epekto.

Isang kaunting kasaysayan at kahirapan sa forensic

Ang mga kahinaan ng ganitong uri ay kilala mula noong huling bahagi ng 90s, at ang terminong CSRF/XSRF ay nilikha ni Peter Watkins noong 2001. Ang bakas ng pag-atake ay karaniwang tumuturo sa lehitimong IP address. mula sa user, na nagpapalubha sa pag-uugnay ng mga responsibilidad at nangangailangan ng espesyal na pagsusuri sa forensic.

Sa loob ng maraming taon, kakaunti ang mga pampublikong pagsasamantala, ngunit ang problema ay paulit-ulit at lumitaw sa maraming pagkakataon sa Nangungunang 10 ng OWASP dahil sa epekto at dalas nito.

Paano gumagana ang pag-atake (kondisyon at daloy)

Maraming kundisyon ang dapat matugunan para magtagumpay ang CSRF. Ang gumagamit ay nagpapanatili ng isang naka-log-in na session kasama ang target na application; awtomatikong nakakabit ang browser cookies, basic/digest na mga kredensyal, o konteksto ng pagpapatunay sa mga kahilingan; at ang aplikasyon ay tumatanggap ng mga pagbabago sa estado nang walang karagdagang mekanismo ng pag-verify.

Kinumbinsi ng umaatake ang biktima, sa pamamagitan ng social engineering (isang email, isang chat o isang kaakit-akit na website), na mag-load ng isang page na nagti-trigger ng malisyosong kahilingan sa bulnerable na site. Walang magagawa ang gumagamit. higit pa sa pagbisita sa page: sapat na ang isang self-submitted form, isang naka-embed na larawan, o isang iframe para ma-trigger ang kahilingan.

Mga karaniwang vector: GET, POST at kahit na "naka-imbak"

Sa kasamaang palad, ang ilang mga application ay nagbabago ng estado gamit ang GET. Sa kasong iyon, isang simple Sa isang third-party na pahina, ang aksyon ay isinasagawa kapag ang larawan ay na-load. Samakatuwid, bilang pangunahing prinsipyo, ang isang kahilingan sa GET ay hindi dapat magbago ng mga mapagkukunan.

Sa POST, ang karaniwang vector ay isang disguised HTML form na isinumite sa sarili gamit ang JavaScript, o na isinumite ng user na iniisip na iba ito. Ang browser ay nakakabit sa session cookie ng lehitimong domain at pinoproseso ng server ang pagbabago (maglipat ng pera, magtanggal ng tala, magpalit ng email, atbp.).

Minsan ang attack code ay maaaring ipasok sa loob ng sariling site ng biktima (dahil sa karagdagang mga depekto), pagho-host nito sa mga IMG tag o iframe. Ang "naka-imbak na CSRF" na ito Binabawasan nito ang hinala dahil lumilitaw na ang pakikipag-ugnayan ay nananatili sa loob ng domain ng tiwala.

Tunay na epekto sa mga account at system

Ang mga kahihinatnan ay mula sa hindi awtorisadong mga transaksyon sa pananalapi hanggang sa mga pagbabago sa configuration, muling pagtatalaga ng mga pahintulot, o pagtanggal ng data. Kung ang biktima ay may tungkuling tagapangasiwaMaaaring baguhin ng attacker ang logic ng application o paganahin ang mga backdoor na makakaapekto sa mas maraming user.

Kahit na ang tila maliliit na aksyon, tulad ng pagpapalit ng email address ng profile, ay maaaring harangan ang pagbawi ng account o mapadali ang kasunod na panloloko. Ang malaking problema ay ang lahat ay nangyayari "sa pangalan ng gumagamit" at madalas na hindi niya napapansin.

Mga partikular na (at napakakaraniwan) na mga halimbawa

Isipin ang isang panel ng administrasyon na nagbibigay-daan sa iyong tanggalin ang isang user na may kahilingan sa GET gamit ang isang URL tulad ng /users/delete/63. Kung binisita ng isang napatotohanang administrator ang isang third-party na page na may kasamang a Ang browser ay gagawa ng kahilingan at ang account ay mawawala.

Isa pang klasiko: online banking. Kung ang paglilipat ay maaaring isagawa sa GET—halimbawa, /transfer?amount=500&account=XXXX—isang tila inosenteng link ang kailangan para sa isang naka-log-in na user upang ma-trigger ang paglilipat ng pera sa account ng umaatake.

Sa POST ang pattern ay magkatulad: ang isang nakatagong form na may "dami" at "account" na mga field ay awtomatikong isinumite kapag nag-load ang pahina. cookie ng session ng bangko mula sa lehitimong domain at pinoproseso ng server ang paglilipat.

Mga kadahilanan ng browser at protocol

Ang paggamit ng HTTPS ay hindi pinipigilan ang pag-atake nang mag-isa: madaling idirekta ng isang nakakahamak na site ang browser upang gumawa ng isang secure na kahilingan. Ang pangunahing pagpapatunay at Digest ay mahina dinKapag na-authenticate na ng user, awtomatikong ipapasa ng browser ang mga kredensyal hanggang sa matapos ang session.

Nakakatulong ang mga patakaran sa cookie ng SameSite, ngunit may mga nuances. Sa SameSite=Strict, hindi ipapadala ng browser ang cookie sa mga cross-site na konteksto at Ang isang malaking bahagi ng CSRF ay pinutol sa ugat.Sa SameSite=Wala (at Secure), gayunpaman, ang cookie ay naglalakbay sa pagitan ng mga site at pinapataas ang ibabaw ng pag-atake.

Magandang kagawian para sa mga gumagamit

Kahit na ang problema ay sa panimula sa aplikasyon, may mga gawi na nagpapababa ng panganib. Mag-log out kapag tapos naAng pagtanggal ng cookies sa pana-panahon, at pag-iwas sa opsyon na "panatilihin akong naka-log in" ay nagpapaliit sa mga window ng pagkakalantad.

Nakakatulong din itong paghiwalayin ang mga gawain: gumamit ng isang browser para sa mga sensitibong gawain at isa pa para sa pangkalahatang pagba-browse, o gamitin ang incognito mode upang maiwasan ang patuloy na mga kredensyalAng mga extension na humaharang sa mga script ay naglilimita sa automation (bagaman hindi sila kumpletong solusyon).

Mga hakbang sa pagtatanggol sa aplikasyon

Unang gintong panuntunan: huwag baguhin ang estado sa GETAng pagpapareserba ng POST/PUT/DELETE para sa mga pagpapatakbo na nagbabago ng mga mapagkukunan ay nakakabawas sa mga walang kabuluhang vector gaya ng mga larawan o mga tago na link.

Ang pinakalaganap na diskarte sa pagpapagaan ng CSRF ay ang synchronizer token pattern: ang server ay naglalabas ng kakaiba, random na token na naka-link sa pagkakakilanlan ng user, at ibinabalik ito ng kliyente sa susunod na kahilingan sa pagbabago ng estado. Kung hindi tumugma ang token Ang kahilingan ay tinanggihan batay sa pagkakakilanlan at impormasyon ng cookie.

Ang isa pang kapaki-pakinabang na layer ay ang pagpapatunay ng mga pinagmulan: pagsuri sa mga header ng Origin/Referer kapag umiiral ang mga ito. Kung ang kahilingan ay hindi nagmula sa inaasahang domain, na-block ang pagprosesoTandaan: Itinago ng ilang kliyente ang Referrer dahil sa patakaran sa privacy, kaya dapat na maingat na ipatupad ang pag-verify na ito.

Nakakatulong din ang WAFs. Mga solusyon sa negosyo, tulad ng F5 BIG-IP ASM o mga serbisyo ng proteksyon na isinama sa mga platform ng pagho-host, magdagdag ng mga panuntunan upang tukuyin at ihinto ang mga kahina-hinalang pattern bago maabot ng mga ito ang iyong app.

Mga limitasyon at karaniwang error sa mga token

Ang mga token ay nagbibigay ng proteksyon kung ipinatupad nang tama. Kung na-bypass ng application ang proseso ng pag-verify kapag may nawawalang token, kailangan lang magpadala ng walang laman na token ang attacker. Ang paggamit ng magagamit muli na pool ay parehong mapanganib. Sa halip na isang token bawat user: magnakaw lang ng valid para gayahin ang mga session ng ibang tao.

Ang pag-iimbak ng token sa isang cookie na naa-access ng JavaScript ay isa ring masamang ideya kung walang mga pagsusuri at balanse: Mababasa ito ng isang XSS attack. at muling gamitin ito. Ang katatagan ay nagmumula sa pagsasama-sama ng session cookie + token sa isang hiwalay na anyo o header, at pag-validate sa pareho.

Relasyon sa SPA, mga token at XSS

Sa mga application na may token-based authentication (hal., JWT), ipadala ang token sa Authorization header bilang Bearer at hindi sa isang cookie Binabawasan nito ang panganib ng CSRF dahil hindi ito awtomatikong ikinakabit ng browser. Gayunpaman, kung mayroong pag-atake sa XSS, maaaring nakawin ito ng isang umaatake mula sa browser. imbakan lokal

Samakatuwid, bilang karagdagan sa CSRF, kinakailangan upang ma-secure ang exit point ng server at maiwasan i-render ang hindi nakatakas na HTML at ilapat ang CSP. Ang CSRF at XSS ay nagpapatibay sa isa't isa kung mag-iiwan ka ng mga puwang sa magkabilang panig.

CSRF sa ASP.NET Core: ang mga mahahalaga para sa mga developer

Kasama sa ASP.NET Core ang mga built-in na pagpapagaan. Ang mga form na may method="post" ay maaaring awtomatikong magsama ng mga anti-forgery token sa Razor view (Ang mga TagHelper at helper tulad ng BeginForm ay naglalagay sa kanila bilang default). Maaari mo ring iturok ang mga ito nang tahasan. at patunayan sa server na may mga filter.

Ang pagpapatunay ay isinaaktibo gamit ang mga katangian tulad ng ValidateAntiForgeryToken o, mas maginhawang, AutoValidateAntiforgeryToken, na nangangailangan ng isang token sa mga hindi ligtas na pamamaraan (POST/PUT/DELETE) at iniiwasang kailanganin ito sa GET/HEAD/OPTIONS/TRACE. Kung kailangan mo ng mga pagbubukod, kinakansela ng IgnoreAntiforgeryToken ang kinakailangan para sa mga kongkretong aksyon.

Para sa mga API at SPA, binibigyang-daan ka ng serbisyo ng IAntiforgery na bumuo at mag-imbak ng mga token, at matanggap ang mga ito sa isang custom na header (halimbawa, X-XSRF-TOKENAng mga frameworks tulad ng Angular ay karaniwang nagbabasa ng cookie na "XSRF-TOKEN" at ipinapadala ang halaga nito sa header na iyon, na dapat patunayan ng server.

Ang pinakamaliit na API ay maaaring tahasang patunayan ang token (mula sa middleware o endpoint na mga filter), at ipinapayong patakbuhin ang anti-counterfeiting middleware. pagkatapos ng authentication at authorizationpag-iwas sa hindi kinakailangang pagbabasa ng katawan ng kahilingan kung ito ay hindi angkop.

Fine configuration: Binibigyang-daan ka ng AntiforgeryOptions na i-customize ang nakatagong pangalan ng field, ang inaasahang header, at kung ang header ng X-Frame-Options ay inilabas (SAMEORIGIN bilang default). Sa panahon ng pag-unlad, ang Secure brand minsan ay nagiging hindi gaanong kilala. ng cookie; sa mga real-world na kapaligiran, inirerekomendang pilitin ang HTTPS.

Tandaan na sa pattern ng token ng pag-synchronize, ang pagbubukas ng maraming tab at pag-navigate sa iba't ibang daloy ay maaaring magpawalang-bisa sa mga nakaraang token: tanging ang pinakabagong pahina Ito ay may posibilidad na magkaroon ng wastong token. Isaalang-alang ang mga alternatibo kung umaasa ang iyong UX sa maraming magkakasabay na tab.

Ang isa pang lugar na dapat bantayan ay ang shared hosting sa ilalim ng parehong domain o subdomain. Ibahagi ang *.domain.com Maaari nitong payagan ang isang app na makagambala sa cookies ng isa pa, kaya ang paghihiwalay ng mga app sa pamamagitan ng iba't ibang domain ay nagpapataas ng paghihiwalay.

Panghuli, ang pagpapatunay ng Windows (NTLM/Kerberos) ay hindi nagpapalibre sa iyo: ang browser ay tuwirang nagpapadala ng konteksto ng pagpapatunay at, nang walang mga token o mga pagsusuri sa pinagmulan, Maaaring naroroon din ang CSRF.

CDN, cross-loading, at kung bakit kailangan mong mag-ingat

Karaniwan para sa isang site na humiling ng nilalaman mula sa mga third party (mga video sa YouTube, CDN library, atbp.). Kung hindi maayos na kontrolado ang palitan na iyonMaaaring samantalahin ng isang attacker ang mga cross-site na ruta upang pilitin ang mga kahilingan na kukumpletuhin ng browser gamit ang mga nakalakip na kredensyal.

Bilang karagdagan sa mga mahigpit na patakaran ng cookie, suriin ang paggamit ng mga iframe at naka-embed na bagay, at ilapat ang SRI kapag gumagamit ng mga CDN. nililimitahan ang mga tinatanggap na pinanggalingan na may mahusay na tinukoy na CSP at CORS.

Mga karagdagang kasanayan para sa mga koponan

Magtatag ng mga pagsusuri sa seguridad para sa mga pagbabago sa form at mga endpoint na nagbabago ng estado. I-automate ang mga pagsubok na nagpapatunay sa presensya at tamang pagpapatunay ng token, at minarkahan bilang "pagharang" sa anumang regression na muling nagpapakilala sa GET na may mga side effect.

Gumagamit ito ng pag-log upang makita ang mga hindi pangkaraniwang pattern (hal., mga pagsusumite ng form na walang token, o may mga hindi inaasahang source na header) at Suporta sa isang WAF na binabawasan ang ingay at hinaharangan ang mga kilalang mapagsamantalang gawi.

Mahalagang paalala: kung ano ang hindi nalulutas ng CSRF lamang

Ang anti-counterfeiting token ay hindi nag-aayos ng script injection; at hindi rin nito pinapalitan ang mga kontrol sa awtorisasyon. Una, i-verify na magagawa ng user ang pagkilosPagkatapos ay i-validate ang token at, kung kinakailangan, suriin ang Origin/Referor. Depensa muna.

At huwag kalimutang ipaalam ang "bakit" sa pangkat ng produkto: ang pag-iwas sa mga kahilingan sa GET na nagbabago ng estado o nangangailangan ng karagdagang token sa ilang partikular na operasyon ay hindi isang teknikal na kapritso, Ito ay direktang proteksyon ng negosyo laban sa pandaraya at manipulasyon.

Ang dahilan kung bakit mapanganib ang CSRF ay ang palihim nito: ang mga kahilingan ay nagmula sa browser ng biktima, gamit ang kanilang mga kredensyal at lumalabas na lehitimo. Pinagsasama-sama mahusay na ipinatupad na mga tokenAng pag-validate ng pinagmulan, naaangkop na mga patakaran sa cookie, responsableng disenyo ng REST at, kung naaangkop, proteksyon ng WAF, ay lubhang binabawasan ang window ng pag-atake nang hindi sinasakripisyo ang karanasan ng user.