@4:53 one of the important things to mention here is that the csrf token is good only as long as it is mapped to the user's session ID in the backend. Otherwise, the attacker might simply obtain a valid CSRF token by visiting the main website themself and inject it into the malicious requests. Tying the token to the user's session and validating that on the backend for each request is very important.
Man, I tried researching how CSRF attacks worked last year and I never got a solid grasp of it. This video changed that. As a cybersecurity enthusiast and web developer, this is super helpful!
There's tens of thousands of videos on Csrf but you easily beat all of them. Yet the number of views you got aren't nearly as close as theirs. Niche youtubers like you are ahead of the time. I hope people like you are revered in coming 5 years
I watched around 15 videos regarding csrf and you are the only one who explained it clearly. Also not everyone stressed on "the browser automatically sends the cookies".
I still don't understand it. What does it mean? What cookies? All the cookies from all the tabs opened in the browser are sent with all POST requests that are being made on whichever tab?
@@kornelijekovac9793 All the cookies from one website will be sent to the server of that website on each request (with website I mean domain, not origin). The most important cookie is the one with the session id (SID), which identifies the user. More about this can be found if you search for "session management".
was curious if tokens really work since you could just make a GET and read the token then post. glad you answered that question very quickly. awesome video. i will subscribe
I often find it hard to focus on educational videos like this, but somehow your videos have all of my attention. Not sure what voodoo you're using but it's working!
As I understand it, fetch and XHR require `useCredentials` to send the cookies along with the request which needs to be explicitly stated on the CORS header Access-Control-Allow-Credentials. Otherwise cookies are not being sent and the CSRF fails.
Because simply flash will forward the request as string and then the site will convert it into header and “ key = value “ type so that it would be readable by the API of vuln.com!
Before sending the delete request, isn't the browser sending a preflight OPTIONS request to the server which will return an error and the delete request won't happen anymore ?
yeah. Just as a note, It seems that you can actually send a simple request to the server and the request will go through but you won't be able to read the response due to cors. namely if you don't have any headers on your request but then again that means you won't have any cookies and won't be carrying any state so pretty useless all in all.
@Orora Brian You can still do CSRF for non-authenticated requests, such as an anonymous message on a blog post or something, which is not entirely harmless
I get this as response headers but I still get the chrome cross origin error. access-control-allow-headers: Content-Type access-control-allow-origin: localhost content-length: 0 content-type: text/html; charset=UTF-8 date: Mon, 16 Mar 2020 15:52:28 GMT server: Apache status: 200
Is it true that SOP allows to send request cross domain but not read the responses? Why would even a request be even triggered by the browser if there is a SOP?
I found a CSRF on a large website with > 500k members, so it's more common than you think! It allowed me to send their coins to my account, and those coins were bought with real money, so it was a decently critical flaw
Thats an example of Cross Origin Request, you can make requests to any website, but the response can't be read due to SOP unless the site let's you explicitly.
The attacker who created cat.com never needs to know your session ID. The javascript in cat.com makes a POST request to vulnerable.com, the browser sees that it's contacting vulnerable.com, and it automatically includes the cookies (including session id)
@@esquilax5563 sorry, so after i make request from vulnerable.com, and then i browsing another domain, and somehow open cat.com, the cat.com still can access my previous vulnerable.com cookies ? is it across the tab browser? what if i re-open the browser, will the request from cat.com still including the vulnerable.com cookies ? then cat.com really needs to know our history browser, so cat.com knows what was the useful cookies before ? does opening from private/incognito browser prevent csrf ?
@@dalewatson3978 It goes like this: browser: hey vulnerable.com server, can you send me your content? vulnerable.com: sure, here it is, and please remember "session=123" ...later... browser: hey cat.com, can you send me your content? cat.com: sure, here it is (snigger) browser: hmm, the content says I should also ask vulnerable.com to do x, y, and z browser: hey vulnerable.com, can you do x, y, and z? And BTW you told me earlier "session=123" vulnerable.com: session ID checks out, OK, I'll go ahead and do x, y, and z. The browser knows *all* its cookies for *all* sites. When it makes a request to a site, it will only send the cookies for that site. Incognito mode can help in some cases. When you start off in incognito mode, you have no cookies, and they'll all be cleared when you close the incognito window. But you can still set cookies in the meantime. So if you're in private mode and you log into vulnerable.com, the same thing can happen. If you're only logged into vulnerable.com in your regular, non-private browser, then you can go to cat.com in private mode and this attack won't work. About closing and re-opening the browser, it all depends on when the relevant cookie is cleared. It can be set to expire when you close the browser, or to expire after a certain amount of time, or it can stay around forever. The server specifies how long the cookie should stay around when it sets the cookie. That's why many sites can decide to let you stay logged in even after the browser is closed and re-opened.
4:08 why is cat-website allowed to send a cookie which is not his own? Where else does it now the sessionID to give a valid answer to the server? Sorry im kinda lost
Fucking A . i had to do couple of days of deep research to understand some of those concepts in order to have some idea about where the exploits would be . you just explained it PERFECTLY in simple terms and visuals and confirmed some of my thoughts :D . u did share some valuable and accurate information despite supid youtube terms n policies. Thank you sir for the clues XD
I love your videos there amazing , professional ! but I guess slow down a little bit for new people, other than that your the best I have ever being taught
let me get this right, if cat.com sends a request to vulnerable.com the browser automatically sends cookies of vulnerable.com with the request but cat.com can't read the response right. they crucial part is that cat.com can't read the response.
But isn't the cookie domain-specific? When we click the cat site(evil) would it still send the cookie(containing sensitive data like sessionId), though it is not associated to hat cat's domain?
You are right, cookies are domain-specific. If you have two different websites opened in your browser, they will not know the Cookies of each other. But the thing is that your BROWSER knows them. And it's your browser that automatically sends them with every request to the website. Otherwise, you were supposed to re-login into the website every time you wanted to make any action.
3:49, uh but there's an origin parameter there, that means the server should be the one responsible for checking the origin has authorisation prior to carrying out any command it has sent
I'm not sure about this I think that the server can decide to check this at the own descretion however this video is in the context of "what the browser does". I guess this video is about the security from the browser point of view.
is there any way of capturing static csrf tokens by taking a payload sent by a pre-existing csrf vulnerability then capturing the response and copying it along with the headers
@4:53
one of the important things to mention here is that the csrf token is good only as long as it is mapped to the user's session ID in the backend. Otherwise, the attacker might simply obtain a valid CSRF token by visiting the main website themself and inject it into the malicious requests.
Tying the token to the user's session and validating that on the backend for each request is very important.
Seriously cant say it enough. I freaking love your videos
I second that notion
i came from LiveOverflow channel , i so glad to be here !
your channel is interesting , love it . keep up the good work
Man, I tried researching how CSRF attacks worked last year and I never got a solid grasp of it.
This video changed that.
As a cybersecurity enthusiast and web developer, this is super helpful!
No words to describe how much informational these videos are.
Thank you.
There's tens of thousands of videos on Csrf but you easily beat all of them. Yet the number of views you got aren't nearly as close as theirs. Niche youtubers like you are ahead of the time. I hope people like you are revered in coming 5 years
Yeah, late in the game, but it's totally fine, I'm just trying to give somethin back to the community.
Look at it now ;)
Damn, dude really planted the seed and let it grow
I watched around 15 videos regarding csrf and you are the only one who explained it clearly. Also not everyone stressed on "the browser automatically sends the cookies".
truuu
I still don't understand it. What does it mean? What cookies? All the cookies from all the tabs opened in the browser are sent with all POST requests that are being made on whichever tab?
@@kornelijekovac9793 All the cookies from one website will be sent to the server of that website on each request (with website I mean domain, not origin). The most important cookie is the one with the session id (SID), which identifies the user. More about this can be found if you search for "session management".
@@bsmldy8681 But how can cookies from two different tabs intermingle?
not sure what you mean by that
the music and naration in the intro made me feel like I'm discovering a mistery in another new world, lol. great video
"Cat-Site Request Forgery"
😂😂😂
Wow , I love the graphical explanatory video, really easy to follow and understand in concordance with explication
we need more of these.
literally a free service to everyone genuinely interested
Third video of yours that came up, and perfectly described the concept. Subscribed
I genuinely don't understand why you stop creating videos. Your style is so cool.
He's back!
Just came by from watching LiveOverflow's video. I subbed and put on the bell notification on. This channel looks so cool
I really enjoyed your theme of explanation and the background music. sounded adventurous
Great content. I can't believe this is free!
PS: I love your colour scheme
Incredibly amazing video as always. Very great explanation, and I love your color choices and how you draw/write everything
was curious if tokens really work since you could just make a GET and read the token then post. glad you answered that question very quickly. awesome video. i will subscribe
Great Video and your drawing is amazing bro that google logo and the adobe logo was so perfect.
You are just awesome man. Why doesn't UA-cam show such search results at the top. I couldn't find you when I needed but now I am happy. Thanks bro..
This is one of the best channel I have encountered 😍
You definitely deserve more subs ;)
Bruh you need to create more content like this. Also you give example are to fast but over all your the best. 11/10.
You put lots of effort into your videos. Transitions are amazing. Wonderful production.
I often find it hard to focus on educational videos like this, but somehow your videos have all of my attention. Not sure what voodoo you're using but it's working!
Wunderbar...................U r one awsme teacher. Hats off to the effort you put in, for us mere novices.
Came from Stök's channel. Absolutely loving it now! Subscribed and belled👏
Amazing content as always, big fan of your videos and tutorials, thank you so much ;D
Love the style of explanation!
As someone who pioneered csrf in 2007 this is a great video
you concept and style of teaching is lovely!..keep it up
This is very well explained, appreciated
You need more likes. Your work is needed for every developer.
the best channel, thanks brother for the knowledge
Best explanation I've ever heard!
Such a good video. I love the voice as well: cute and reliable
Very nice video, I love the explanation!
As I understand it, fetch and XHR require `useCredentials` to send the cookies along with the request which needs to be explicitly stated on the CORS header Access-Control-Allow-Credentials. Otherwise cookies are not being sent and the CSRF fails.
Thanks for making this. Really nice!
Great video, to the point and thoroughly explained the main concept.
Thankyou for your videos. I would very much like to see a video on Insecure CORS and ways to escalate it :)
probably the best explanation out there
Videos are so interesting and clear with basic to advance. Keep going 😀
Great explanation bro, Keep up the good work.
Wish ya da best.
Crystal clear explanation. Thanks a ton
incredibly informative!
You explained this better than the skillsoft guys, that's for sure
12:47
I dont understand why the json data + the content type header are first passed through a redirect(?) then to the vulnerable site?
Because simply flash will forward the request as string and then the site will convert it into header and “ key = value “ type so that it would be readable by the API of vuln.com!
Because the redirect can send cookies
Amazing 😅 , i learn a lot of new concepts in one video , but i think i will re-watch it later , some of them seem confusing !
Before sending the delete request, isn't the browser sending a preflight OPTIONS request to the server which will return an error and the delete request won't happen anymore ?
I was thinking the same. Ideally CORS would have stopped this.
yes. In case of Ajax request , SOP will stop the request as the preflight will return error
yeah. Just as a note, It seems that you can actually send a simple request to the server and the request will go through but you won't be able to read the response due to cors. namely if you don't have any headers on your request but then again that means you won't have any cookies and won't be carrying any state so pretty useless all in all.
As cors is just client sided, for a hacker this isn't difficult to bypass it
@Orora Brian You can still do CSRF for non-authenticated requests, such as an anonymous message on a blog post or something, which is not entirely harmless
Was watching live overflows vid a month ago, and look at me now, watching each video of yours everyday
I get this as response headers but I still get the chrome cross origin error.
access-control-allow-headers: Content-Type
access-control-allow-origin: localhost
content-length: 0
content-type: text/html; charset=UTF-8
date: Mon, 16 Mar 2020 15:52:28 GMT
server: Apache
status: 200
Awesome video. I hope that you explain some bugs like vulnerable flash files, JSONP and email spoofing
Great explained, thanks🔥
wtf you deserve way more likes on this
your channel is a gold mine !!
Very clear explanation. Thanks!
this is the best. freaking cool
this made me rethink my web security holy shit.
Is it true that SOP allows to send request cross domain but not read the responses? Why would even a request be even triggered by the browser if there is a SOP?
I found a CSRF on a large website with > 500k members, so it's more common than you think! It allowed me to send their coins to my account, and those coins were bought with real money, so it was a decently critical flaw
Great videos.........Thank you for posting them
Explained well, props to you
I Love PwnFunction Video's ILLUSTRATION🔥🙌⚡😍
Basic question 😐=> If the same origin policy blocks the request from different domain, how can cat.com make request on behalf of vulnerable.com? 🤔
Thats an example of Cross Origin Request, you can make requests to any website, but the response can't be read due to SOP unless the site let's you explicitly.
most of the cases of being bypassed by other domains for a kind of request is by using */wildcard in CORS
Amazing video, so clear!
thank you
4:00 how did cat.com get my session id?
The attacker who created cat.com never needs to know your session ID. The javascript in cat.com makes a POST request to vulnerable.com, the browser sees that it's contacting vulnerable.com, and it automatically includes the cookies (including session id)
@@esquilax5563 sorry, so after i make request from vulnerable.com, and then i browsing another domain, and somehow open cat.com, the cat.com still can access my previous vulnerable.com cookies ? is it across the tab browser? what if i re-open the browser, will the request from cat.com still including the vulnerable.com cookies ?
then cat.com really needs to know our history browser, so cat.com knows what was the useful cookies before ?
does opening from private/incognito browser prevent csrf ?
@@dalewatson3978 It goes like this:
browser: hey vulnerable.com server, can you send me your content?
vulnerable.com: sure, here it is, and please remember "session=123"
...later...
browser: hey cat.com, can you send me your content?
cat.com: sure, here it is (snigger)
browser: hmm, the content says I should also ask vulnerable.com to do x, y, and z
browser: hey vulnerable.com, can you do x, y, and z? And BTW you told me earlier "session=123"
vulnerable.com: session ID checks out, OK, I'll go ahead and do x, y, and z.
The browser knows *all* its cookies for *all* sites. When it makes a request to a site, it will only send the cookies for that site.
Incognito mode can help in some cases. When you start off in incognito mode, you have no cookies, and they'll all be cleared when you close the incognito window. But you can still set cookies in the meantime. So if you're in private mode and you log into vulnerable.com, the same thing can happen. If you're only logged into vulnerable.com in your regular, non-private browser, then you can go to cat.com in private mode and this attack won't work.
About closing and re-opening the browser, it all depends on when the relevant cookie is cleared. It can be set to expire when you close the browser, or to expire after a certain amount of time, or it can stay around forever. The server specifies how long the cookie should stay around when it sets the cookie. That's why many sites can decide to let you stay logged in even after the browser is closed and re-opened.
Won’t CORS will restrict the call, when delete request initiated from cat.com to vulnerable.com ?
Awesome explanation! Tks!
Love your videos! Please make more :3
That's crazy explanation, Thanks a lot
Well done sir, keep them coming! :)
This is awesome !
Great Explanation ✅
4:08 why is cat-website allowed to send a cookie which is not his own? Where else does it now the sessionID to give a valid answer to the server? Sorry im kinda lost
Sometimes it's warranted. sometimes one site depends on you being authorized on another website.
You saved me. Thank you so much
Fucking A . i had to do couple of days of deep research to understand some of those concepts in order to have some idea about where the exploits would be . you just explained it PERFECTLY in simple terms and visuals and confirmed some of my thoughts :D . u did share some valuable and accurate information despite supid youtube terms n policies. Thank you sir for the clues XD
I love your videos there amazing , professional ! but I guess slow down a little bit for new people,
other than that your the best I have ever being taught
Nice video thanks for the amazing content
love your videos this is a god's work
Ok, good stuff. Subscribed.
but doesn't CORS prevent this?
Question: Why not just use postman and set the headers?
Thanks
You can.... If you want to hack only yourself.
let me get this right, if cat.com sends a request to vulnerable.com the browser automatically sends cookies of vulnerable.com with the request but cat.com can't read the response right. they crucial part is that cat.com can't read the response.
I feel like you're correct
Just amazing content!
You're videos are awesome
Can cors prevent this request when credentials are included and the cookie is http only?
Awesome ! Thank you !
Hey @PwnFuncrion why you're not uploading any videos now 😐
Yes! We cannot access external website within but what about window.postMessage() ?
*Sees **11:42*
*Cries with Respect*
Your videos are amazing. Clean, informational, and perfect. I should have found your channel earlier.
But isn't the cookie domain-specific? When we click the cat site(evil) would it still send the cookie(containing sensitive data like sessionId), though it is not associated to hat cat's domain?
You are right, cookies are domain-specific. If you have two different websites opened in your browser, they will not know the Cookies of each other.
But the thing is that your BROWSER knows them. And it's your browser that automatically sends them with every request to the website. Otherwise, you were supposed to re-login into the website every time you wanted to make any action.
how is this csrf_token stored so it is not send together with cookies?
But how is it possible to post json via html form, where entry is urlencoded?
I don't get it. If a hacker needs a token, why can't he simply make a get request in order to get some token and then send post with given token?
3:49, uh but there's an origin parameter there, that means the server should be the one responsible for checking the origin has authorisation prior to carrying out any command it has sent
I'm not sure about this I think that the server can decide to check this at the own descretion however this video is in the context of "what the browser does". I guess this video is about the security from the browser point of view.
Excellent Explanation
is there any way of capturing static csrf tokens by taking a payload sent by a pre-existing csrf vulnerability then capturing the response and copying it along with the headers
nvm i forgor same-origin policy
you should make more cyber security videos i LOVE them!!!