
Turkish: 
Bu video güçlü teknik hakkında olacak
Siteler arası sahtecilik isteği sahteciliği, CSRF.
Son videolarda XSS - Cross-site-script
- Bu, içinde javascript çalıştırmamızı sağlar.
Bir kullanıcının oturumunun bağlamı.
Bu bize herhangi bir işlem yapmamızı sağlar.
kullanıcı yapabilirdi.
Böylece diğerlerine mesaj göndermek için kullanabiliriz.
kurbanı farketmeden platformdaki kullanıcılar,
veya sahte haber makalesini bir siteye enjekte etmek
ya da sadece onu bozuyor.
Ancak bir site güvenli bir şekilde kullanıcı girişi yaptıysa,
dizeleri düzgün kaçar, o zaman
şanssız.
İnsan neden basitçe kaçamayacağını merak ediyor olabilir.
kendi sitenizde javascript kontrol ettiğiniz
ve aynı istekleri ve eylemleri gerçekleştirin.
Peki tarayıcının güvenlik modeli önler
söyledi.
Bu güvenlik modeli aynı köken denir
politika.

English: 
This video will be about the powerful technique
called Cross site request forgery, CSRF.
In the last videos we have explored XSS - Cross-site-scripting
- which allows us to execute javascript in
the context of a user’s session.
This allows us to perform any actions the
user could do.
Thus we can use it to send messages to other
users on the platform without the victim noticing,
or injecting fake news article into a site
or simply defacing it.
But if a site implemented user input securely,
properly escapes the strings, then you are
out of luck.
One might wonder why you cannot simply run
javascript on your own site that you control
and perform the same requests and actions.
Well the security model of the browser prevents
that.
This security model is called the same-origin
policy.

Turkish: 
Liveoverflow.com adresinde çalışan ne varsa
etki alanı kaynaklara erişemez
Çapraz kökeni.
Bir hata alırsınız.
FAKAT BEKLE!
Bu mantıklı değil…
Reddit etki alanı kaynaklara nasıl erişebilir?
diğer bir deyişle, imge.com
Bu aynı köken politikasını ihlal etmiyor mu?
Bu soruyu sorduğun için çok zekisin!
Aynı köken politikası belli ki biraz
biraz daha karmaşık ve çok farklı
dikkate almanız gereken davalar.
Hadi birkaç örnek yapalım, görelim mi?
çok farklı.
Reddit.com'da buradayım.
Bu kökeni https://reddit.com vardır
Burada https://imgur.com adresim var.
Yani reddit üzerinde kolayca bir HTML görüntüsü kullanabilirsiniz
resim kaynağını etiketleyin ve yükleyin.
Gördüğünüz gibi tarayıcı isteği yaptı
şikayet etmeden.
Reddit’de JSON’da birçok veri bulabilirsiniz.
biçim.
Bilmiyorsan, bu harika bir numara.
bu konuda.
Soru.
İmgur.com bu JSON cevaplarına erişebilir mi?

English: 
Whatever is running on my liveoverflow.com
domain is not allowed to access resources
cross-origin.
You will get an error.
BUT WAIT!
That doesn’t make sense…
How can the reddit domain access resources,
namely images, from this other origin imgur.com?
Does that not violate the same-origin policy?
You are so smart for asking this question!
The same-origin policy is obviously a little
bit more complex and there are a lot of different
cases you have to consider.
Let’s do some examples so you just see how
diverse it is.
I’m here on reddit.com.
It has the origin https://reddit.com
Over here I have https://imgur.com.
So on reddit I can easily use an HTML image
tag and load the image resource.
As you can see the browser did the request
without complaining.
On reddit you can get a lot of data in JSON
format.
That’s a neat trick if you didn’t know
about that.
Question.
Can imgur.com access those JSON responses?

Turkish: 
Bu görüntü gibi basit bir GET isteği
çok doğru?
Ve görüntüyü gösterebildik.
bunun içeriğini alabilmeliyiz
de istek, değil mi?
Bir GET gerçekleştirmek için XMLHTTPRequest kullanabiliriz
istek.
İşe yaradı gibi görünüyor, ancak cevap
boş JSON ve verileri içermiyor
Bekledik.
Ağ sekmesine bir göz atalım
ne olduğunu gör.
İlk önce birden fazla basit olduğunu fark ettik.
istek.
Buradaki ilk kişi
Bir Konum ile reddit sunucusu: başlık.
Bu başlığı alan tarayıcı şimdi
bu yeni konuma bir yönlendirme yapın.
Ve bu yeni konum / giriş.
Ahhhh!
Mantıklı.
Yakından baktığımızda, çerez görmüyoruz.
bu istekle birlikte gönderiliyor.
Bu URL'yi basitçe açtığımızda olduğu gibi
reddit
Hızlı bir google araması size
withCredentials ayarlayarak çerezleri içerebilir
isteği göndermeden önce
Ama hayır.
Şimdi çalışmıyor.

English: 
It’s a simple GET request like the image
too, right?
And we were able to display the image, so
we should be able to get the content of this
request as well, right?
We can use XMLHTTPRequest to perform a GET
request.
Looks like it worked, but the response is
empty JSON, and doesn’t contain the data
we expected.
Let’s have a look at the network tab to
see what happened.
We first notice there is more than one simple
request.
The first one here got a response from the
reddit server with a Location: header.
The browser receiving this header will now
perform a redirect to this new location.
And this new location is /login.
Ahhhh!
That makes sense.
When we look closely, we don’t see any cookies
being sent along with this request.
Like it did when we simply opened this URL
on reddit.
A quick google search will tell you that you
can include the cookies by setting withCredentials
to true before sending the request.
But nope.
Now it doesn’t work.

Turkish: 
Artık tarayıcı ihlal ettiğinizden şikayet ediyor
Aynı köken politikası.
İmgur.com alan adının gerçekleştirilmesine izin verilmiyor
Çerezler ile reddit.com için bir GET isteği.
Bu bir saldırı için işe yaramaz kılar.
Çünkü bir saldırgan olarak çıkarmak istiyoruz
Özel kullanıcı verileri, ancak çerezler olmadan
asla özel şeyler içermeyecek.
Başka bir şey deneyelim.
Daha önceki gibi bir resim etiketi kullanalım ve
Bu .json dosyasını yükleyin.
Ağ sekmesine ve WTF'ye bakıyoruz.
Bu isteği içeren çerezleri gönderdi.
Öyleyse, aynı kökene bir bypass bulduk mu?
politika?
Şey… hayır.
Görüyorsunuz, yanıtına erişemiyoruz.
bu istek.
Json içeriğine erişemiyoruz, o yüzden
Özel kullanıcı verilerine erişilemiyor.
Tamam.
Yani aynı kökenli politika gibi görünüyor
oldukça iyi.
Özel verilere erişmemizi engelliyor
kökenleri çapraz.
Elbette bazı teknik olasılıklar var.
Bu politikayı gevşetmek için.
Ve krom bile bu konuda size anlatır
hata mesajı.

English: 
Now the browser complains that you are violating
the same origin policy.
The domain imgur.com is not allowed to perform
a GET request to reddit.com with cookies.
This makes it kinda useless for an attack.
Because as an attacker we would like to extract
private user data, but without cookies it
will never contain private stuff.
Let’s try something else.
Let’s use an image tag like earlier and
load this .json file.
We look into the network tab and WTF.
It did send the cookies with this request.
So did we just find a bypass to the same-origin
policy?
Well… no.
You see, we can’t access the response of
this request.
We cannot access the json content, thus we
cannot access the private user data.
Ok.
So it looks like the same-origin policy is
pretty good.
It prevents us from accessing private data
cross origins.
Of course there are some technical possibilities
to loosen up this policy.
And chrome even tells you about it in the
error message.

English: 
With this special response header, that could
be set by the reddit server, this could be
allowed.
But one thing is still fishy.
With the image source we just performed an
authenticated, meaning cookies were included,
request to the other domain.
We don’t get the response, but could this
be exploited in any meaningful way?
Yes it can!
Let’s see.
You remember the different HTTP methods.
Like GET and POST. generally GET requests
are intended to fetch.
To get.
a resource.
And nothing else.
While POST is used by forms to submit data.
Like POSTing in a new thread.
POST-ing.
Get it?
Hehe.
This means GET requests generally don’t
affect the site at all, while POST requests
potentially change a user’s data.
So performing an authenticated GET request
should generally be safe, except when a site
is developed badly and a URL accessible via
GET performs an actual action.
If that is the case, you have found your first
cross-site-request-forgery, CSRF vulnerability.
So if there is for example a url that deletes
a user, like /profile/delete, and you embed

Turkish: 
Bu özel yanıt başlığı ile, bu olabilir
reddit sunucusu tarafından ayarlanmalı, bu
izin verdi.
Ama bir şey hala balık.
Resim kaynağı ile az önce bir
kimliği doğrulandı, yani çerezler eklendi,
diğer etki alanına istek.
Yanıt alamıyoruz, ancak bu olabilir mi?
anlamlı bir şekilde sömürülmek?
Evet yapabilir!
Bakalım.
Farklı HTTP yöntemlerini hatırlarsınız.
GET ve POST gibi. genellikle GET istekleri
getirmek için tasarlanmıştır.
Almak.
kaynak.
Ve başka bir şey yok.
POST veri göndermek için formlar tarafından kullanılırken.
Yeni bir konudaki POSTing gibi.
SONRASI ing.
Anla?
Hehe.
Bu, GET isteklerinin genellikle yapmadığı anlamına gelir
POST istekleri sırasında siteyi hiç etkilemez
Bir kullanıcının verilerini potansiyel olarak değiştirebilir.
Böylece kimliği doğrulanmış bir GET isteği gerçekleştiriliyor
Bir site ne zaman hariç, genellikle güvenli olmalı
kötü bir şekilde geliştirilmiştir ve
GET gerçek bir eylem gerçekleştirir.
Eğer öyleyse, ilkini buldun.
siteler arası istek-sahtecilik, CSRF güvenlik açığı.
Öyleyse, örneğin silen bir url varsa
/ profile / delete gibi bir kullanıcı ve siz

Turkish: 
web sitenizde bir resim olarak, sonra her
sitenizi ziyaret eden kullanıcı
profilleri fark etmeden.
Tamam, diyelim ki geliştirici takip ediyor
Bu tasarım ve hiçbir devlet değişen yoktur
İstekleri GET.
Site güvenli mi?
İşte POST istekleri için başka bir teknik.
POST yöntemiyle form oluşturabilir ve
diğer alanı hedefleyen eylem ve
formu gönderdiğinde,
Çerezlerle birlikte POST isteği.
Yani evet, doğrulanmış bir POS gerçekleştirebiliriz
de istek.
Rağmen, site de şimdi yönlendirildi
diğer etki alanı.
Ama bunu kullanıcıdan gizleyebiliriz.
Ya da umrumda değil, çünkü saldırı o zaman
Yine de.
Ancak bir kullanıcının tıklamasını nasıl sağlayabilirim?
Bir kullanıcının tıklamasına gerek yok, yapabilirsin
bu formu javascript ile otomatik olarak göndermeniz yeterlidir.
Sadece netleştirmek için, aynı köken politikası
Burada ihlal edilmedi, çünkü kökenimiz
kaynaklara, cevaba erişememek,
bu diğer etki alanının verileri.

English: 
that as an image on your website, then every
user visiting your site will delete their
profile without them noticing it.
Okay, but let’s say a developer follows
this design and there are no state changing
GET requests.
Is the site safe?
Well here is another technique for POST requests.
I can create a form with the method POST and
the action aiming at the other domain, and
when the submit the form, it will perform
a POST request WITH the cookies.
So yes, we can perform an authenticated POSt
request as well.
Though, the site also redirected now to the
other domain.
But we can hide that from the user.
Or don’t care, because the attack is then
over anyway.
But how do I get a user to click?
Well a user doesn’t have to click, you can
simply auto-submit this form with javascript.
Just to make it clear, the same-origin policy
is not violated here, because our origin does
not get access to the resources, the response,
the data of this other domain.

English: 
So how do we protect from this kind of attack?
One approach would be, to compare a legitimate
request from our domain with an illegitimate
request from another domain and see if there
are differences that we could check for.
And yeah, we could check for the Origin header,
which is definitely different.
This might sound good.
It certainly prevents some kind of Cross site
request forgery attacks.
But for example sites like forums allow users
to embed their own pictures.
And if this forum is vulnerable to a GET CSRF
attack, then users could simply embed that
URL as an image into a message.
And then the request would come from the same
domain.
So this is not a bullet proof protection.
There are also some other kind of mitigations,
for example form post requests always send
the data URL-encoded.
you may have found this old stackexchange
thread telling you that a cross-domain request
with the content-type json are impossible.
And your endpoint could only accept JSON data
- and this might prevent some noobs from exploiting

Turkish: 
Peki bu tür saldırılardan nasıl korunacağız?
Bir yaklaşım meşru olanı karşılaştırmak olacaktır.
alanımızdan gayri meşru bir talep
başka bir etki alanından istekte bulunup bulunmadığına bakın
kontrol edebileceğimiz farklılıklar.
Ve evet, Köken başlığını kontrol edebiliriz.
bu kesinlikle farklı.
Bu iyi gelebilir.
Kesinlikle bir çeşit Cross site önler
sahtecilik saldırıları talep edin.
Ancak örneğin forum gibi siteler kullanıcılara izin veriyor
kendi resimlerini gömmek için.
Ve eğer bu forum bir GET CSRF'sine karşı savunmasızsa
Saldırı, sonra kullanıcılar basitçe
Bir mesaja görüntü olarak URL.
Ve sonra istek aynı gelirdi
domain.
Yani bu kurşun geçirmez bir koruma değildir.
Başka tür hafifletici önlemler de vardır,
örneğin form gönderme istekleri her zaman gönder
URL ile kodlanmış veri.
bu eski stackexchange’i bulmuş olabilirsiniz.
bir etki alanı isteğini söyleyen iş parçacığı
içerik türü ile json imkansızdır.
Ve son noktanız yalnızca JSON verilerini kabul edebildi
- ve bu bazı noobların sömürülmesini önleyebilir

English: 
it.
But your trust into this protection is flawed.
Down here, hidden in a comment, you find information
about a trick using navigator.sendBeacon.
It’s a super awesome trick.
And little tricks like that make the difference
between a normal web penetration tester and
a great one.
Anyhow, as you can see, this is also not bullet-proof.
So then what can we do?
The solution is a called CSRF token.
CSRF tokens can be implemented in a few different
ways, but generally you want a secret random
value to be set by the server in a way, that
it’s only accessible to the website running
on the same domain.
And this secret value has to be included in
every POST request to the server, otherwise
it will refuse to react to your request.
And that works, because the same-origin policy
prevents other domains accessing your data,
thus cannot get the secret CSRF value, but
the legit original domain can.

Turkish: 
o.
Ancak bu korumaya olan güveniniz hatalı.
Aşağıya, bir yorumda gizli, bilgileri bulabilirsiniz
navigator.sendBeacon kullanarak bir numara hakkında.
Süper harika bir numara.
Ve bunun gibi küçük numaralar fark yaratır
normal bir ağ penetrasyon test cihazı arasında ve
harika bir tane.
Her neyse, gördüğünüz gibi, bu da kurşun geçirmez değildir.
Öyleyse ne yapabiliriz?
Çözüm, CSRF belirteci olarak adlandırılır.
CSRF belirteçleri birkaç farklı şekilde uygulanabilir.
yollar, ama genellikle gizli bir rastgele istiyorum
Sunucu tarafından ayarlanacak değer
yalnızca çalışan web sitesine erişilebilir
Aynı etki alanında.
Ve bu gizli değere dahil edilmesi gerekir
Sunucuya yapılan her POST isteği, aksi takdirde
isteğinize tepki vermeyi reddedecektir.
Ve bu işe yarıyor, çünkü aynı köken politikası
diğer alanların verilerinize erişmesini engeller,
bu nedenle gizli CSRF değerini elde edemezsiniz, ancak
okunaklı orijinal etki alanı olabilir.

Turkish: 
Açıkçası, CSRF'yi sızdırmanın bir yolunu bulursanız
belirteci, sonra CSRF korumasını yenin.
Şimdi, bu belirteç ile değiştirmek zorunda değil
Her istek.
Ancak fikir şu ki, tahmin etmek zor.
Bu yüzden sonsuza dek geçerli olmamalı.
Ayrıca, çok çok önemli, CSRF belirteçleri var
Bir kullanıcının oturumuna BOUND olmak.
Aksi takdirde, örneğin geçerli bir tahsilat yapabilirim
Bir hesapla CSRF belirteçleri ve daha sonra
Bunları CSRF’deki diğer hesaplara karşı saldırı.
Siteler arası istek sahteciliği son derece olabilir
güçlü ve zayıf bir CSRF korumasını atlayarak
süper eğlenceli olabilir.
Ama yanlış yapma, sadece bir web sitesi yüzünden
savunmasız bir son noktaya sahip olduğu anlamına gelmez
kritik bir konu.
https://twitter.com/tqbf
Bunu burada bitirmeden önce teşvik etmek istiyorum.
yaratıcılığınızı size vererek biraz
birkaç düşük şiddeti nasıl dönüştürebileceğinize bir örnek
serin bir saldırı içine böcek.
Se burada tarifi.
İlk düşük önemde sorun, depolanmış bir kendi kendine XSS
Güvenlik açığı.

English: 
Obviously if you find a way to leak the CSRF
token, then you defeat the CSRF protection.
Now, this token doesn’t have to change with
every request.
But the idea is that it’s hard to predict.
So it shouldn’t be valid for forever.
ALSO, very very important, CSRF tokens have
to be BOUND to a user’s session.
Otherwise I could for example collect valid
CSRF tokens with one account, and then use
them in the CSRF attack against other accounts.
Cross site request forgery can be extremely
powerful and bypassing a weak CSRF protection
can be super fun.
But make no mistake, just because a website
has a vulnerable endpoint doesn’t mean it’s
a critical issue.
https://twitter.com/tqbf
Before we finish this here, I want to stimulate
your creativity a little bit by giving you
an example in how you can turn a few low severity
bugs into a cool attack.
Se here is the recipe.
First low-severity issue, is a stored self-XSS
vulnerability.

Turkish: 
Self-XSS, bir javasript enjekte edebileceğimiz anlamına gelir
web sitesine iş yükü, örneğin kişisel
o sitedeki defter, ancak yalnızca etkiler
kendi kullanıcı hesabımız.
İdamda kimseyi kandıramayız.
Bu javascript yükü, çünkü biz
kişisel notumuzu gören sadece biri.
Yani işe yaramaz, değil mi?
Yoksa öyle mi.
Sıradaki sorun, siteden çıkış oturumu kapatma isteği
kalpazanlık.
Bu, ziyaret eden herhangi birinin oturumu kapatmamızı sağlar
bizim kötü sayfamız.
Son sorun bir giriş çapraz site isteğidir
kalpazanlık.
Böylece giriş bilgilerimizi göndermemize izin verilir.
bu web sitesi ile doğrulamak için.
Ama bunu ne için kullanırız?
İşte, saldırı planımız.
İlk önce yeni bir hesap oluşturup
öz-XSS.
Belki de yük, sahte giriş yapabilir
kullanıcılara tekrar giriş yapmalarını isteme
şifre - böylece çalabiliriz.
Sonra yürütecek bir saldırı sitesi kurarız
Aşağıdaki iki şey sırayla.
İlk önce mağdurun olmadığından emin olacak
oturumu kapatmayı kullanarak siteye giriş yaptınız
CSRF.

English: 
Self-XSS means that we can inject a javasript
payload into the website, for example a personal
notebook on that site, but it only affects
our own user account.
We can’t trick anybody else in executing
this javascript payload, because we are the
only one seeing our personal note.
So it’s useless, right?
Or is it.
Next issue is a logout cross-site-request
forgery.
This allows us to logout anybody visiting
our evil page.
The last issue is a login cross-site-request
forgery.
So this allows us to send the login credentials
to authenticate with that website.
But what the hell would we use that for?
Well, here is our attack plan.
First we create a new account and add the
self-XSS.
Maybe the payload can create a fake login
prompt telling the users to reenter their
password - so we can steal it.
Then we build an attack site that will execute
the following two things in order.
First it will make sure the victim is not
logged into the site, by using the logout
CSRF.

Turkish: 
Ve sonra bir giriş CSRF yapmak
kendi XSSed hesabımızın hesap bilgileri.
Şimdi kurbanı yönlendirmek zorundayız.
siteye geri döndüğünüzde mağdurun kimliği doğrulanacaktır
hesabımızda self-xss'i çalıştırırken sormak
şifre için.
Güzel kimlik avı saldırısı.

English: 
And then we perform a login CSRF with the
account credentials of our self-XSSed account.
Now we simply have to redirect the victim
back to the site, and the victim will be authenticated
with our account executing the self-xss, asking
for the password.
Beautiful phishing attack.
