Epekto
Ang Cross-Site Request Forgery (CSRF) ay nagbibigay-daan sa isang umaatake na linlangin ang browser ng isang biktima upang magsagawa ng mga hindi gustong aksyon sa ibang website kung saan kasalukuyang napatotohanan ang biktima. Dahil ang mga browser ay awtomatikong nagsasama ng mga nakapaligid na kredensyal tulad ng cookies sa mga kahilingan, ang isang umaatake ay maaaring gumawa ng mga pagpapatakbong nagbabago ng estado—gaya ng pagpapalit ng mga password, pagtanggal ng data, o pagsisimula ng mga transaksyon—nang hindi nalalaman ng user.
Root Cause
Ang pangunahing dahilan ng CSRF ay ang default na gawi ng web browser sa pagpapadala ng cookies na nauugnay sa isang domain sa tuwing may hiling na ginawa sa domain na iyon, anuman ang pinagmulan ng kahilingan [S1]. Kung walang tiyak na pagpapatunay na ang isang kahilingan ay sadyang na-trigger mula sa sariling user interface ng application, hindi matukoy ng server ang pagkakaiba sa pagitan ng isang lehitimong aksyon ng user at isang pekeng aksyon.
Mga Mekanismo ng Proteksyon ng Django CSRF
Nagbibigay ang Django ng built-in na defense system para mabawasan ang mga panganib na ito sa pamamagitan ng middleware at template integration [S2].
Pag-activate ng Middleware
Ang django.middleware.csrf.CsrfViewMiddleware ay responsable para sa proteksyon ng CSRF at karaniwang pinapagana bilang default na [S2]. Dapat itong iposisyon bago ang anumang view middleware na ipinapalagay na ang mga pag-atake ng CSRF ay nahawakan na [S2].
Pagpapatupad ng Template
Para sa anumang panloob na mga form ng POST, dapat isama ng mga developer ang {% csrf_token %} tag sa loob ng <form> element na [S2]. Tinitiyak nito na ang isang natatangi, lihim na token ay kasama sa kahilingan, na pagkatapos ay patunayan ng server laban sa session ng user.
Mga Panganib sa Pag-leakage ng Token
Ang isang kritikal na detalye ng pagpapatupad ay ang {% csrf_token %} ay hindi dapat isama sa mga form na nagta-target ng mga panlabas na URL [S2]. Ang paggawa nito ay maglalabas ng sikretong CSRF token sa isang third party, na posibleng makompromiso ang seguridad ng session ng user na [S2].
Browser-Level Defense: SameSite Cookies
Ipinakilala ng mga modernong browser ang SameSite attribute para sa Set-Cookie header upang magbigay ng layer ng defense-in-depth na [S1].
- Mahigpit: Ang cookie ay ipinadala lamang sa isang first-party na konteksto, ibig sabihin, ang site sa URL bar ay tumutugma sa domain ng cookie na [S1].
- Lax: Ang cookie ay hindi ipinadala sa mga cross-site na subrequest (tulad ng mga larawan o mga frame) ngunit ipinapadala kapag ang isang user ay nag-navigate sa pinagmulang site, gaya ng pagsunod sa isang karaniwang link na [S1].
Paano sinusuri ito ng FixVibe
Kasama na ngayon sa FixVibe ang proteksyon ng CSRF bilang isang gated active check. Pagkatapos ng pag-verify ng domain, sinisiyasat ng active.csrf-protection ang mga natuklasang form na nagbabago ng estado, sinusuri ang mga input na may hugis na CSRF-token at mga signal ng cookie ng SameSite, pagkatapos ay susubukan ang isang mababang-impact na pagsumite ng forged-origin at nag-uulat lamang kapag tinanggap ito ng server. Ang mga pagsusuri sa cookie ay nagba-flag din ng mga mahihinang katangian ng SameSite na nagpapababa ng lalim ng pagtatanggol sa CSRF.