CSRF nedir?

Saytlararasi sorgu saxtakarligi - attacker-in vebsayt istifadecilerini gerceklesdirmek niyyetinde

olmadiqlari action-lari gerceklestirmeye sovq etmesine imkan veren web security vulnerability-
lerinden biridir. Bu hucum novunde, attacker "same origin policy"ni qismen bypass ede bilir. "Same
Origin Policy" de nedi, origini (yeni domain name-i, protokolu olsun) muxtelif olan vebsaytlarin bir-
birine mudaxilesinin qarsisini almaga yariyan bir konseptdi.

Qeyd: SOP CORS(cross-origin resource sharing), JSONP, iframe-based attack-lerle bypass oluna bilir.

Nece bypass edir? CSRF hucumunda email ve ya malicious bir website istifadecini artiq logged in
veziyyetde oldugu basqa bir saytda zererli emaliyyatlar yerine yetirmeye tempt edir. Meselen, onlayn
bank hesabinda logged in state-dedi ve malicious bir website-i visit edir. Istifadecinin brauzerinde
artiq hemin target vebsayt ucun lazim olan cookie ve authentication token-ler oldugundan malicious
website targete hidden bir form vasitesile unathorized requestler gondere bilir ve bununla da SOP-u
bypass etmis olur. Sorğu istifadəçinin brauzerindən initiate olundugu üçün bank vebsaytı istifadəçinin
köçürməni həyata keçirmək niyyətində olduğunu düşünür və emeliyyati əlavə authentication-a
ehtiyac duymadan həyata keçirir.

Istifadecinin unintentional sekilde yerine yetirdiyi bu emeliyyat account-unda email adresini,

passwordunu deyismek ve ya her hansi diger action da ola biler. Yaxud application daxilinde privilege-
i yuksek bir user account ele kecirilibse, netice etibarile full control-a da malik olmus olacaq.

Attack-in gerceklesmesi ucun:

1. Attacker-in induce eliye bileceyi aidiyyati (relevant) bir emeliyyat olmalidi --> privileged
userler ucun basqa userlerin permissionlarini deyismek kimi, ve ya userin oz paswordunu
deyismesi kimi.
2. Cookie-based session handling --> Target app requesti edenin kim oldugunu mueyyen etmek
ucun yalniz session cookie-lerine esaslanmalidi, yeni user requestlerin validate olunmasi ve
ya session-larin track olunmasi ucun hec bir basqa mexanizm olmamalidi.
 3. No predictable request parameters --> Emeliyyati yerine yetirmek ucun edilen requestler
atakerin mueyyen/texmin ede bilmeyeceyi parametrleri ozunde dasimamalidi. Meselen, ist-
ni paswordunu deyismeye sovq etdikde, attacker existing password-u bilmelidise, bu bas
tutmayacaq.

Attack-e qarsi mudafie usullari:

CSRF tokenləri – server side application terefinden generate olunan ve client-la bolusulen gizli,
unikal, texmin oluna bilmeyen, entropy-si yuksek bir string. Belece, istifadeci form submit etmek kimi
sensitive sayila bilecek bir emeliyyat yerine yetirdikde, hemin bu token-i de requestde include etmeli
olur. Bu da attacker-in victim-in adindan valid bir sorgu yaratmasini cetinlesdirir.

Bu tokenlerin generate olunmasinda CSPRNG - cryptographically secure pseudo-random number

generator den istifade olunur. Token nece oturulmelidir? – Adeten POST metodu ile submit olunan
HTML formun hidden field-inde yerlesdirilir ki, form submit olunanda token request parametr kimi
oturule bilsin. Yaxud tokeni contain eden field HTML doc. daxilinde mumkun qeder basda mention
olunur – non-hidden input fieldlerden qabaq. Basqa bir metod URL query string daxilinde onu
qoymaq ola biler amma bu problemlidi cunki bu query string HTTP Referer header daxilinde third
partilere transmit oluna biler, istifadecinin brauzerinde ekranda display oluna bilir. CSRF tokenleri
kukilerin daxilinde oturulmemelidir.

Token generate olunan zaman server-sideda user-in session datasinda saxlanmalidir. Validation teleb
eden her hansi novbeti sorguda server-side app. Ilk store olunan tokenle sorgunun contain etdiyi
tokeni muqayise etmelidi ve bu muqayise sorgunun kontent type-indan ve HTTP metdoddan asili
olmayaraq aparilmalidi.

SameSite kukileri – Mueyyen bir vebsaytin kukilerinin diger basqa bir vebsaytdan edilen request-lere
daxil edilib-edilmediyini teyin eden brauzer tehlukesizlik mexanizmidi. Sensitive emeliyyatlari yerine
yetirmek ucun, authenticate olunmus session cookie-lere ehtiyac oldugundan, muvafiq SameSite
limitlemeleri ile attacker-in bu emeliyyatlari cross-site olaraq yerine yetirmeye calismasinin qarsisi
alinir. 2021-ci ildən Chrome defolt olaraq Lax SameSite restrictionlarini tətbiq eliyir.

SameSite=Strict  kuki, kukini set eden saytdan originate olan request-lerde oturule biler. DEMELI,
vulnerable sibling domainler vasitesile(request cross-origin edilse de, same-site ola bilir) , client-side
redirect kimi on-site gadgetlar ist etmekle bypass oluna biler.

SameSite=Lax  kuki, linke tiklamaq ve ya adres bara URL daxil etmek kimi top-level navigation-larla
requestde oturule biler ve ya request GET method istifade edirse requestde oturule biler Subsequent
request-ler cookie-ni include etmiyecek. DEMELI, GET request istifade etmekle bypass oluna biler.

Cross-origin, same-site attacklere qarsi qorunmasizdi.

Referer esasli dogrulama - Bəzi applicationlarda, adətən, sorğunun tətbiqin öz domenindən

qaynaqlandığını yoxlayaraq CSRF hücumlarınin qarsisini almaq üçün HTTP Referer Header-inden
istifadə edilir, hansi ki CSRF token validation-la muqayisede daha az effektiv sayilir.
SSRF nedir?

Server tərəfində sorğu saxtakarlığı – atacker-in server-side applicaton-u nezerde tutulmamis

unintended location-lara sorğu göndərməyə sövq etməsinə imkan verən web security vulnerabilty-
lerinden biridir. Tipik SSRF hucumlarinda, atacker, serverin organization-un infrastrukturu daxilinde
olan internal servislerle elaqe yaratmasina sebeb ola biler. Yaxud diger hallarda, attacker serveri
ixtiyari external sistemlere qosulmaga mecbur ede ve bununla da authorization credentiallari kimi
sensitive datani sizdirilmasina yol aca biler.

Impact-I neden ibaretdir?

Trust relationshipleri exploit etmekle vuln. app.-dan hucumun basladilmasi ve unauthorized

emeliyyatlarin yerine yetirilmesi; or access to data within the organization (vulnerable applicationun
ozunde ve ya app.in communicate eleye bildiyi basqa back-end sistemlerde olan). Arbitrary code
execution.

External third-party sistemlerle elaqeler qurularsa, bu, novbeti attacklerin onlarla elaqe quran
vulnerable app-imizi host eden organization terefinden basladildigi image-ini verecek.

Serverin ozune qarsi edilen SSRF attack

Attacker application-u onu host eden servere HTTP request gondermeye vadar edir. Bu da, adeten,
host adi kimi 127.0.0.1 (yeni localhost) daxil edilen URL-i supply etmekle yerine yetirilir. Məsələn,
istifadəçiyə mehsulun müəyyən bir mağazada stock-da olub-olmadığını görməye imkan verən
shopping applicationu var deyek. Hemin bu stock information-u temin etmek ucun,
application, sozugeden mehsul ve magazadan asili olaraq muxtelif backend REST API-lara query
gondermelidi. Yeni, brauzer muvafiq backend API endpointinin URLini specify edib HTTP request
gondermelidi. Normalda stock statusunu retrieve edib qaytarmalidi, amma stockAPI-in URLi yerine,
serverin ozune local olan bir URL(http://localhost/admin) specify etse, server hemin location-un
kontentini fetch edib user-e qaytaracaq. Melum meseledi ki, hemin local URL-e edilen request lokal
machine-in ozunden geldiyi ucun bu bas tutur ve normal access control-lar bypass olmus olur.
Bu niye bele bypass oluna bilir? Disaster recovery purposes deyilen anlayis var hansi ki, application
lokal machine-den gelen istenilen user-e login etmeden administrativ access vermis olur.

Diger backend sistemlere qarsi edilen SSRF attack

Server istifadeciler terefinden birbasa elcatan olmayan back-end sistemlerle interact ede bilirse, bu
halda bu attack-e zemin yaranir. Adeten, bu sistemlere non-routable private IP adresler verilir.
Adeten, back-end sistemler network topology daxilinde protect olundugundan, ele de guclu
qorunmur. Hemin bu internal back-end sistemlerde sensitiv info saxlanilarsa ve de authntication teleb
olunmazsa sadece bir interactionla bu dataya access etmek olacaq. Meselen, deyek ki back-end
URLde olan bir administrativ interface stockApi=http://192.168.0.68/admin qeyd etsek ve requestle
gondersek, access etmis olariq.

SSRF-den mudafie usullarinden bypass olunmasi –

Blacklist-based input filterleri anti-SSRF defense kimi istifade olunduqda

Bezi app.-ler 127.0.0.1, localhost ve s kimi hostname-leri ozunde contain eden inputlari, yaxud
/admin kimi sensitiv ola bilecek URL-leri bloklayirlar. Hansi ki bu filtrlemeni circumvent etmek olar:

1. lokalhost ip-sinin oktal, decimal ve short-hand representationlarini isletmek

2. 127.0.0.1 adresine resolve eliyen oz domain name-imizi register etmek olar bunun ucun 
(spoofed.burpcollaborator.net)

3. Blok olunmus stringleri obfuscate elemekle- URL encoding stringler blok olunsa da, onlari server
terefinden interpret oluna bilecek sekile salmaq olar (percent encoding meselen) Case variation Eyni
sekilde, movcud olan defense stringi bloklayirsa, herflerin case-ini deyisib detection-u evade ede
biler.

4. Attacker-in ozu kontrol etdiyi URL provide etmesi, hansi ki eventually target URL-e redirect edecek.
Target URL ucun muxtelif redirect code-larindan(302, 307), ve protokollarindan istifade edile biler.
Redirect zamani http-den httpse switch olunmasi kimi ve s. http://attacker-site.com/redirect.php?
url=https://192.168.0.10/private-api
Whitelist-based input filterleri anti-SSRF defense kimi istifade olunduqda

Bezi applicationlar yalniz mueyyen value-larla baslayan, contain eden, yaxud onlara match eden
inputlari buraxirlar, yerde qalanlar bloklanir. URL parsingde movcud olan inconsistency-leri exploit
etmekle bu filterleri bypass etmek olar.

Meselen URL-de hostname-in qarsisinda @ isaresi qoymaqla username ve password kimi

credentiallarin embed olunmasi.  https://expected-host:fakepassword@evil-host; mueyyen URL
fragmentinin indicate etmek ucun # isaresinden istifade olunmasi (requesti basqa bir hosta redirect
etmek ucun) https://evil-host#expected-host  application ola bilsin URL-in # simvoluna qeder olan
hissesini check etsin; Attacker ozunun idaresinde olan fully-qualified DNS name-ne ozune lazim olan
inputu daxil ede biler. (DNS naming hierarchy-den istifade ederek bu fully-q domain nameler create
olunur). https://expected-host.evil-host; URL encoding de islene biler

SSRF filterlerinin open redirection vulnerability-den istifade ederek bypass olunmasi

URL-leri allow listde olan application ozunde open redirection vulnerability-si ehtiva edirse; backend
HTTP requesti eden API, redirection-u support edirse, filteri satisfy ede bilecek URL construct etmek
olar, hansi ki nezerde tutulan backend target-e redirect eleyen requestle neticelenecek.
Blind SSRF attack

Applicationun supply edilmis URL-e backend HTTP request gondermesi temin oluna bilirse, amma
backend requestden gelen response application-un front-end response-unda return olunmursa, bu
hala Blind SSRF deyilir. Exploit olunmasi daha cetin olsa da, serverde ve diger back-end
componentlerde full remote code executiona yol aca biler.

Adeten, SSRF vulnerabilityleri spot olunmasi daha asan olur, cunki app.-in normal traffic-
indeki request parametrleri ozunde full URL-ler contain edir.
Referrer header uzerinden SSRF
Bezi Appler referring saytlarin kontentini analyze etmek ucun sayt visitor-larini track eden
analytics software isledirler. Ona gore de Referrer headerde ne oldugu da SSRF ucun attack
vectorlarindan biri olmus olur.

SIEM nedir?