CSRF (Cross Site Request Forgery)
Join HackenProof Discord server to communicate with experienced hackers and bug bounty hunters!
Hacking Insights Engage with content that delves into the thrill and challenges of hacking
Real-Time Hack News Keep up-to-date with fast-paced hacking world through real-time news and insights
Latest Announcements Stay informed with the newest bug bounties launching and crucial platform updates
Join us on Discord and start collaborating with top hackers today!
Cross-Site Request Forgery (CSRF) Explained
Cross-Site Request Forgery (CSRF) ni aina ya udhaifu wa usalama unaopatikana katika programu za wavuti. Inawawezesha washambuliaji kufanya vitendo kwa niaba ya watumiaji wasiojua kwa kutumia vikao vyao vilivyothibitishwa. Shambulio linafanyika wakati mtumiaji, ambaye amejiandikisha kwenye jukwaa la mwathirika, anatembelea tovuti mbaya. Tovuti hii kisha inasababisha maombi kwa akaunti ya mwathirika kupitia mbinu kama vile kutekeleza JavaScript, kuwasilisha fomu, au kupakua picha.
Prerequisites for a CSRF Attack
Ili kutumia udhaifu wa CSRF, masharti kadhaa yanapaswa kutimizwa:
Tafuta Kitendo Chenye Thamani: Mshambuliaji anahitaji kupata kitendo kinachostahili kutumiwa, kama kubadilisha nenosiri la mtumiaji, barua pepe, au kuongeza mamlaka.
Usimamizi wa Kikao: Kikao cha mtumiaji kinapaswa kusimamiwa pekee kupitia vidakuzi au kichwa cha HTTP Basic Authentication, kwani vichwa vingine haviwezi kubadilishwa kwa kusudi hili.
Ukosefu wa Vigezo Visivyoweza Kutabirika: Ombi halipaswi kuwa na vigezo visivyoweza kutabirika, kwani vinaweza kuzuia shambulio.
Quick Check
You could capture the request in Burp and check CSRF protections and to test from the bowser you can click on Copy as fetch and check the request:
Defending Against CSRF
Hatua kadhaa za kinga zinaweza kutekelezwa ili kulinda dhidi ya mashambulizi ya CSRF:
SameSite cookies: Sifa hii inazuia kivinjari kutuma vidakuzi pamoja na maombi ya tovuti tofauti. More about SameSite cookies.
Cross-origin resource sharing: Sera ya CORS ya tovuti ya mwathirika inaweza kuathiri uwezekano wa shambulio, hasa ikiwa shambulio linahitaji kusoma jibu kutoka kwa tovuti ya mwathirika. Learn about CORS bypass.
User Verification: Kuuliza nenosiri la mtumiaji au kutatua captcha kunaweza kuthibitisha nia ya mtumiaji.
Checking Referrer or Origin Headers: Kuthibitisha vichwa hivi kunaweza kusaidia kuhakikisha maombi yanatoka kwa vyanzo vinavyotegemewa. Hata hivyo, kuunda URL kwa uangalifu kunaweza kupita ukaguzi usiofaa, kama vile:
Using
http://mal.net?orig=http://example.com
(URL inamalizika na URL inayotegemewa)Using
http://example.com.mal.net
(URL inaanza na URL inayotegemewa)Modifying Parameter Names: Kubadilisha majina ya vigezo katika maombi ya POST au GET kunaweza kusaidia kuzuia mashambulizi ya kiotomatiki.
CSRF Tokens: Kuingiza tokeni ya kipekee ya CSRF katika kila kikao na kuhitaji tokeni hii katika maombi yanayofuata kunaweza kupunguza hatari ya CSRF kwa kiasi kikubwa. Ufanisi wa tokeni unaweza kuimarishwa kwa kutekeleza CORS.
Kuelewa na kutekeleza hizi kinga ni muhimu kwa kudumisha usalama na uadilifu wa programu za wavuti.
Defences Bypass
From POST to GET
Labda fomu unayotaka kutumia vibaya imeandaliwa kutuma POST request with a CSRF token but, unapaswa check ikiwa GET pia ni valid na ikiwa unapowasilisha GET request CSRF token bado inathibitishwa.
Lack of token
Programu zinaweza kutekeleza mekanismu ya validate tokens wakati zinapokuwepo. Hata hivyo, udhaifu unatokea ikiwa uthibitishaji unakosolewa kabisa wakati token inakosekana. Washambuliaji wanaweza kutumia hii kwa kuondoa parameter inayobeba token, si tu thamani yake. Hii inawawezesha kupita mchakato wa uthibitishaji na kufanya shambulio la Cross-Site Request Forgery (CSRF) kwa ufanisi.
CSRF token is not tied to the user session
Programu zisizofunga CSRF tokens kwa vikao vya mtumiaji zina hatari kubwa ya usalama. Mifumo hii inathibitisha tokeni dhidi ya global pool badala ya kuhakikisha kila token inafungwa na kikao kinachoanzisha.
Hapa kuna jinsi washambuliaji wanavyotumia hii:
Authenticate kwa kutumia akaunti yao wenyewe.
Obtain a valid CSRF token kutoka kwa global pool.
Use this token katika shambulio la CSRF dhidi ya mwathirika.
Udhaifu huu unawawezesha washambuliaji kufanya maombi yasiyoidhinishwa kwa niaba ya mwathirika, wakitumia mkanika wa uthibitishaji wa tokeni wa programu usiofaa.
Method bypass
Ikiwa ombi linatumia "weird" method, angalia ikiwa method override functionality inafanya kazi. Kwa mfano, ikiwa inatumia PUT method unaweza kujaribu kutumia POST method na send: https://example.com/my/dear/api/val/num?_method=PUT
Hii inaweza pia kufanya kazi kwa kutuma _method parameter ndani ya POST request au kutumia headers:
X-HTTP-Method
X-HTTP-Method-Override
X-Method-Override
Custom header token bypass
Ikiwa ombi linaongeza custom header yenye token kwa ombi kama CSRF protection method, basi:
Jaribu ombi bila Customized Token na pia header.
Jaribu ombi lenye same length lakini token tofauti.
CSRF token is verified by a cookie
Programu zinaweza kutekeleza ulinzi wa CSRF kwa kuiga tokeni katika vidakuzi na parameter ya ombi au kwa kuweka cookie ya CSRF na kuthibitisha ikiwa tokeni iliyotumwa kwenye backend inalingana na cookie. Programu inathibitisha maombi kwa kuangalia ikiwa tokeni katika parameter ya ombi inalingana na thamani katika cookie.
Hata hivyo, mbinu hii ina udhaifu kwa mashambulizi ya CSRF ikiwa tovuti ina kasoro zinazomruhusu mshambuliaji kuweka cookie ya CSRF kwenye kivinjari cha mwathirika, kama vile udhaifu wa CRLF. Mshambuliaji anaweza kutumia hii kwa kupakia picha ya udanganyifu inayoweka cookie, ikifuatiwa na kuanzisha shambulio la CSRF.
Below is an example of how an attack could be structured:
Kumbuka kwamba ikiwa csrf token inahusiana na cookie ya kikao, shambulio hili halitafanya kazi kwa sababu utahitaji kuweka kikao cha mwathirika, na kwa hivyo utakuwa unajishambulia mwenyewe.
Mabadiliko ya Aina ya Maudhui
Kulingana na hii, ili kuepuka maombi ya preflight kutumia njia ya POST, hizi ndizo thamani za Aina ya Maudhui zinazoruhusiwa:
application/x-www-form-urlencoded
multipart/form-data
text/plain
Hata hivyo, kumbuka kwamba mantiki ya seva inaweza kutofautiana kulingana na Aina ya Maudhui iliyotumika, hivyo unapaswa kujaribu thamani zilizotajwa na nyingine kama application/json
,text/xml
, application/xml
.
Mfano (kutoka hapa) wa kutuma data ya JSON kama text/plain:
Kupita Maombi ya Preflight kwa Data ya JSON
Wakati wa kujaribu kutuma data ya JSON kupitia ombi la POST, kutumia Content-Type: application/json
katika fomu ya HTML si rahisi moja kwa moja. Vivyo hivyo, kutumia XMLHttpRequest
kutuma aina hii ya maudhui huanzisha ombi la preflight. Hata hivyo, kuna mikakati ya kuweza kupita kikomo hiki na kuangalia ikiwa seva inashughulikia data ya JSON bila kujali Aina ya Maudhui:
Tumia Aina Mbadala za Maudhui: Tumia
Content-Type: text/plain
auContent-Type: application/x-www-form-urlencoded
kwa kuwekaenctype="text/plain"
katika fomu. Njia hii inajaribu kuangalia ikiwa backend inatumia data bila kujali Aina ya Maudhui.Badilisha Aina ya Maudhui: Ili kuepuka ombi la preflight huku ukihakikisha seva inatambua maudhui kama JSON, unaweza kutuma data na
Content-Type: text/plain; application/json
. Hii haisababishi ombi la preflight lakini inaweza kushughulikiwa ipasavyo na seva ikiwa imewekwa kukubaliapplication/json
.Matumizi ya Faili ya SWF Flash: Njia isiyo ya kawaida lakini inayowezekana inahusisha kutumia faili ya SWF flash kupita vizuizi kama hivi. Kwa ufahamu wa kina wa mbinu hii, rejelea hiki chapisho.
Kupita Ukaguzi wa Referrer / Origin
Epuka kichwa cha Referrer
Programu zinaweza kuthibitisha kichwa cha 'Referer' tu wakati kiko. Ili kuzuia kivinjari kutuma kichwa hiki, tag ya meta ya HTML ifuatayo inaweza kutumika:
Hii inahakikisha kuwa kichwa cha 'Referer' hakijajumuishwa, huenda ikapita mchakato wa uthibitishaji katika baadhi ya programu.
Regexp bypasses
URL Format BypassIli kuweka jina la kikoa la seva katika URL ambayo Referrer itatuma ndani ya vigezo unaweza kufanya:
HEAD method bypass
Sehemu ya kwanza ya hii CTF writeup inaelezea kwamba mwanzo wa Oak, router imewekwa kushughulikia maombi ya HEAD kama maombi ya GET bila mwili wa jibu - njia ya kawaida ambayo si ya kipekee kwa Oak. Badala ya mpangilio maalum unaoshughulikia maombi ya HEAD, yanapewa tu mpangilio wa GET lakini programu inatoa tu mwili wa jibu.
Hivyo, ikiwa ombi la GET linapunguzwa, unaweza tu kutuma ombi la HEAD ambalo litashughulikiwa kama ombi la GET.
Mifano ya Kutumia
Kutoa CSRF Token
Ikiwa CSRF token inatumika kama kinga unaweza kujaribu kutoa kwa kutumia udhaifu wa XSS au udhaifu wa Dangling Markup.
GET kwa kutumia lebo za HTML
Mengineyo ya vitambulisho vya HTML5 ambavyo vinaweza kutumika kutuma ombi la GET kiotomatiki ni:
Fomu ya ombi la GET
Ombi la POST la Fomu
Omba POST ya fomu kupitia iframe
Ombi la Ajax POST
multipart/form-data POST ombi
multipart/form-data POST request v2
Fomu ya POST ombi kutoka ndani ya iframe
K盗a CSRF Token na kutuma ombi la POST
Kununua CSRF Token na kutuma ombi la Post kwa kutumia iframe, fomu na Ajax
K盗 CSRF Token na kutuma ombi la POST kwa kutumia iframe na fomu
Iibi token na utume kwa kutumia iframes 2
POSTIibi CSRF token kwa Ajax na tuma posti na fomu
CSRF na Socket.IO
CSRF Login Brute Force
Msimbo unaweza kutumika kufanya Brut Force fomu ya kuingia kwa kutumia token ya CSRF (Pia inatumia kichwa X-Forwarded-For kujaribu kupita uwezekano wa kuorodheshwa kwa IP):
Tools
References
Jiunge na HackenProof Discord server kuwasiliana na hackers wenye uzoefu na wawindaji wa makosa!
Hacking Insights Shiriki na maudhui yanayochunguza msisimko na changamoto za hacking
Real-Time Hack News Baki na habari za hivi punde katika ulimwengu wa hacking kupitia habari na maarifa ya wakati halisi
Latest Announcements Baki na taarifa kuhusu makosa mapya yanayoanzishwa na masasisho muhimu ya jukwaa
Jiunge nasi kwenye Discord na uanze kushirikiana na hackers bora leo!
Last updated