Your videos are true gems. You not only replicate the exploit, but also fit a thorough explanation about the underlying concepts in relatively short video. Huge thanks and dont stop!
It took me a while to finally find a video that shows clearly how CSRF would happen despite SOP, with both img and forms. Thank you very much for this vid!
Also take note that you can forge every header by just not using a browser, and instead using curl or a httpclient of some sort in your favorite programming language.
I was confused by the POST example, where the POST went thru but the GET was blocked. After some searching, MDN's article on SOP points out: cross-origin writes are typically allowed, while cross-origin reads typically aren't.
Google made a web Excelerator extension a couple of years ago, probably more like 10 years ago. What it would do is it would follow URLs so that it could pre-save them if you decided to click on them. The problem was with admin‘s were also using this for their database software like PHP my admin. And unfortunately software like that was changing state of the database from get requests. A lot of people lost a lot of data. Google pulled the extension soon after.
Great videos! You can send data that is not url-encoded in a form post request just use which can be more convenient to use in inter-protocol attacks, for example. Also I couldn't send data to a different domain with content-type=application/json using the sendBeacon API, there was only just an OPTIONS request (preflight for CORS) being sent whenever I tried to send a Blob. So it seems to be fixed.
Can anyone explain why at 4:13 even though authenticated request was send (cookies included) no data is received ? Or is it not rendered by the browser since it's not a valid image date ?
@LiveOverflow Can somebody explain why we are able to see the imgur image at 1:41 mark after changing DOM model by adding src element? If you try to open i.imgur.com/xReW1yH.jpg in browser you will see (in developer tools) that the GET request is sent with some cookies, shouldn't then the same-origin-policy make the content of the image unavailable to us? Does it mean that when we add src element to DOM model the browser doesn't send those cookies?
I think you are able to see it because browser didn't sent any cookies along with the request so no private info is given. If you try to open the link another context is created this is completely different scenario. If you open reddit.com reddit will make the request for images and everything for you. so requests to reddit will go with cookies but imgur requests have to go without any cookies. Edit: Doing some research I found out that if you make a request to imgur "i.imgur.com/xReW1yH.jpg" in the response header you get Allow-Access-Control-Allow-Origin which basically tells the browser to stop being paranoid let the origin access the webpage.
image tag dosen't set cookie. Does it fixed now? Or am I wrong? all I did is logged in to reddit and opend www.reddit.com/message/messages.json added to elements in i.imgur.com/1UeGNVL.jpg. request was sent but there were no cookie attribute in request headers. also the request headers said Provisional headers are shown. and console said Cross-Origin Read Blocking (CORB) blocked cross-origin response
I am curious, does the CSRF token works the same way as any access token? In the explanation, it says that all POST request should be included with a CSRF token, and I thought, wait, that's how normally access token is used. Can someone explains, if they are the same in this case or different?
In the example at the end of the video, wouldn’t the exploit be useless due to the “notes” XSS only being able to be accessed by someone logged in as us, because we are the only ones who can view it, as you explained at the start of the segment?
The idea is that you could maybe load an iFrame with personal data first, then perform the logout/Login, get XSS on the domain and now you are allowed to access the old iFrame that contains secret data because it was loaded from the old session
I have one small question: 3:35 although the browser cannot access the response, the request is already successfully sent to the server with the cookie and any associated operations should be done right (If there is no referer check on the server side)? I mean if some dude are so careless to delete an article using a GET request then the article should already be deleted even though you cannot read the response (probably saying {action: 'delete', success: 'true'} ). Is my understanding correct?
The XHR will be sent anyway to its destination, even you can't read the HTTP response. It happens because it is another origin, albeit you can reach if it is the same. When you made a request using `XMLHttpRequest.withCredentials`, your origin B need to response with CORS headers (Access-Control-Allow-*), in this case, "Access-Control-Allow-Credentials" to the browser allows the cross-communication without restricting credentials, authorizations headers, and TLS certificates.
I was trying for like 3 days to get that navigator.sendBeacon() trick to work, but it looks like it was addressed about the time this video was uploaded. Coincidence? Anyway, the sendBeacon CSRF for "application/json" doesn't work in any newer Chrome or FF browsers. bugzilla.mozilla.org/show_bug.cgi?id=1364132
Your video might raise the assumption that 1. cross domain requests can't be sent(!) only when credentials are going to be sent via javascript (XHR) 2. this can be bypassed by using an img/form tag Maybe i am wrong, but as far as i understood the SOP only prevents reads and not writes in ANY case (doesn't matter if with/without credentials or via javascript/tags). Could you clear this up? Otherwise: Nice video i liked it :)
No. You are wrong. 1. Same-origin Policy deems page as "same-origin" conforming the following policies: * Same schema/protocol ("" differs from ""); * Same domain ("example.com" differs from "www.example.com"); * and, same port ("80" differs from "8080") Whereas in Internet Explorer is an exception, the 3rd attribute aforementioned (port) is not a resource required to match. As you have noticed, the Same-origin Policy is a restriction rule to access the resource from a different origin(s). May this isn't explicit, but it includes local files as well. Therefore, the schema "file://" and "chrome://" is such a thing to be considered too. 2. The "HTML tags" are referred to as the Document Object Model (DOM). This DOM is a way to JavaScript reach all elements of the Berners-Lee's Hyper-Text Markup Language (HTML). In the case of developers want to interact with different origins, they can use "document.domain" in JavaScript. Suppose a cross-domain from "account.example.com" and "api.example.com." * current domain: "account.example.com" `document.domain = "example.com" ` * current domain: "api.example.com" `document.domain = "example.com"` If you mention the subdomain on "document.domain" on the root domain, it would won't work. The last thing you must need to understand is: *How "**reddit.com**" accept resources from "**i.imgur.com**"?* So that's where it importance of the "Cross-origin Resource Sharing"(CORS) comes in. When use an XMLHttpRequest object to send a request to a different origin, you may not be able to read the response. However, this request will still arrive at its destination. A way to SOP left you to read the "imgur.com" HTTP response headers or body data from "your-domain.com" with XHR is using CORS headers: Access-Control-Allow-Origin: *.imgur.com (or just "*" to allow all websites) Access-Control-Allow-Methods: POST, GET (you can specify others HTTP methods) Access-Control-Allow-Headers: Origin, Accept, X-Requested-With (or any other headers) * To allow credentials, authorizations headers, and TLS certificates: Access-Control-Allow-Credentials: true This header works in conjunction with `XMLHttpRequest.withCredentials`. Hence, if the request sends credentials and "your-domain.com," return the header, the browser would accept the cross-communication without restricting the web content. Otherwise, it will be ignored by the browser if the CORS preflight request not consent. (developer.mozilla.org/en-US/docs/Glossary/Preflight_request) Now, look at this image and note the "Request URL" and its HTTP "Access-Control-Allow-*" headers: i.imgur.com/mCjU81f.png.
With PHP and cURL you can write a little proxy script to bypass same origin policy, f.e. could look like this: proxy.php?url_to_non_same_origin, i really have cases where i have to use this trick.
Sure you can do that but using that to actually get a third party site to commit actions not authorised by the user would need you to trick the user into logging into the other site via the proxy. Usually a CSRF attack is instead attempting to perform a confused deputy attack on the browser tricking it into using the users stored credentials (or cookies) for domain2 in order to perform actions at the direction of domain1. For instance if the domain stealyourmoney.com wanted to transfer money from the users paypal account merely using stealyourmoney.com/paypal_proxy.php wont work as the browser will access that URL with the cookies scoped for stealyourmoney.com not paypal.com. Getting the user to log in via your proxy is more of a social engineering attack than a true CSRF since you are ultimately attacking the human vulnerabilities (abusing human naivety, trust, etc) not the technological ones.
+Christian Fernandez reddit user Community guidelines say, that self promotion is bad. And my posts got deleted from other subreddits because of that. So I prefer if people share videos they like :)
thanks a lot humble great master, phishing attack is a kind of man in the middle. sha1 and blockchain. pls teach us about VPN and there is a hacker with bad supposedly free vpn.
Thanks for the help on this! Just one thought - dropping a random F word in a training training video is pointless and is, by definition, offensive language. I would like to be able to watch this when my children are around. It just lowers the quality/standard of your video. Again thanks for passing you knowledge on!
Your videos are true gems. You not only replicate the exploit, but also fit a thorough explanation about the underlying concepts in relatively short video. Huge thanks and dont stop!
That "WTF" seriously took me by surprise loool. Great video!
It took me a while to finally find a video that shows clearly how CSRF would happen despite SOP, with both img and forms. Thank you very much for this vid!
Finally a perfect example walkthrough on the SOP. Now I get the full picture, you are the best
Nice DHMIS reference
Perfect amounts of profanity in every tutorial.
If possible please make more videos on web category too. you make things soo simple to understand ☺☺
Also take note that you can forge every header by just not using a browser, and instead using curl or a httpclient of some sort in your favorite programming language.
i love the DHMIS reference on the tumbnail
I was confused by the POST example, where the POST went thru but the GET was blocked. After some searching, MDN's article on SOP points out: cross-origin writes are typically allowed, while cross-origin reads typically aren't.
guyz like you will make us happy
I think people tend to forget to like on these types of videos...
there was a lot of stuff to learn here great video...
4:31 turn on captions. I dont know why no one is talking about it here in the comment section. LMAO
Google made a web Excelerator extension a couple of years ago, probably more like 10 years ago. What it would do is it would follow URLs so that it could pre-save them if you decided to click on them. The problem was with admin‘s were also using this for their database software like PHP my admin. And unfortunately software like that was changing state of the database from get requests. A lot of people lost a lot of data. Google pulled the extension soon after.
Damn, that example at the end... Great video!
i love ur videos liveoverflow ❤🔥
Great videos! You can send data that is not url-encoded in a form post request just use which can be more convenient to use in inter-protocol attacks, for example. Also I couldn't send data to a different domain with content-type=application/json using the sendBeacon API, there was only just an OPTIONS request (preflight for CORS) being sent whenever I tried to send a Blob. So it seems to be fixed.
Your subtitles jokes are incredible lol
Can anyone explain why at 4:13 even though authenticated request was send (cookies included) no data is received ? Or is it not rendered by the browser since it's not a valid image date ?
if i were to use something like an OAuth API in my php website, could i use one of the values in the user's $_SESSION as a CRSF token?
@LiveOverflow Can somebody explain why we are able to see the imgur image at 1:41 mark after changing DOM model by adding src element? If you try to open i.imgur.com/xReW1yH.jpg in browser you will see (in developer tools) that the GET request is sent with some cookies, shouldn't then the same-origin-policy make the content of the image unavailable to us? Does it mean that when we add src element to DOM model the browser doesn't send those cookies?
Same Question !!
I think you are able to see it because browser didn't sent any cookies along with the request so no private info is given.
If you try to open the link another context is created this is completely different scenario. If you open reddit.com reddit will make the request for images and everything for you. so requests to reddit will go with cookies but imgur requests have to go without any cookies.
Edit: Doing some research I found out that if you make a request to imgur "i.imgur.com/xReW1yH.jpg" in the response header you get Allow-Access-Control-Allow-Origin which basically tells the browser to stop being paranoid let the origin access the webpage.
why SOP will not restrict to access the img sources from imgur.com on reddit.com
image tag dosen't set cookie. Does it fixed now? Or am I wrong?
all I did is
logged in to reddit and opend www.reddit.com/message/messages.json
added
to elements in i.imgur.com/1UeGNVL.jpg.
request was sent but there were no cookie attribute in request headers.
also the request headers said Provisional headers are shown.
and console said Cross-Origin Read Blocking (CORB) blocked cross-origin response
I am curious, does the CSRF token works the same way as any access token? In the explanation, it says that all POST request should be included with a CSRF token, and I thought, wait, that's how normally access token is used. Can someone explains, if they are the same in this case or different?
An access token passed as a header could serve as a CSRF token.
0:12 it seems like page www.tutorialspoint.com/php/src/form_get.php is no longer there
In the example at the end of the video, wouldn’t the exploit be useless due to the “notes” XSS only being able to be accessed by someone logged in as us, because we are the only ones who can view it, as you explained at the start of the segment?
The idea is that you could maybe load an iFrame with personal data first, then perform the logout/Login, get XSS on the domain and now you are allowed to access the old iFrame that contains secret data because it was loaded from the old session
How can we then protect a website which uses Get for state changes?
Wow, clear explanation, subscribed)
wow, so cool! i didn't understand a word you said
Clean Content and Great Presentation #subscribed
The rabbit in the outro is a reference to going down the rabbit down the rabbit hole?
8:43 don't miss that part guys !!!
I have one small question: 3:35 although the browser cannot access the response, the request is already successfully sent to the server with the cookie and any associated operations should be done right (If there is no referer check on the server side)? I mean if some dude are so careless to delete an article using a GET request then the article should already be deleted even though you cannot read the response (probably saying {action: 'delete', success: 'true'} ). Is my understanding correct?
The XHR will be sent anyway to its destination, even you can't read the HTTP response. It happens because it is another origin, albeit you can reach if it is the same. When you made a request using `XMLHttpRequest.withCredentials`, your origin B need to response with CORS headers (Access-Control-Allow-*), in this case, "Access-Control-Allow-Credentials" to the browser allows the cross-communication without restricting credentials, authorizations headers, and TLS certificates.
document.origin is depreciated use window.origin instead
Thanks man.
Still live here..GET IN MY HOUSE!
I was trying for like 3 days to get that navigator.sendBeacon() trick to work, but it looks like it was addressed about the time this video was uploaded. Coincidence? Anyway, the sendBeacon CSRF for "application/json" doesn't work in any newer Chrome or FF browsers.
bugzilla.mozilla.org/show_bug.cgi?id=1364132
Let's all agree never to be creative again
What if csrf tokens are included in cookies? With xhr.withCredentials=true set an attacker can send the valid credentials required right?
You are awesome 👏
creativity is awesome
Also noticed the Don't Hug Me I'm Scared draw, but i wasn't sure.
Green is not a creative color.
Your video might raise the assumption that
1. cross domain requests can't be sent(!) only when credentials are going to be sent via javascript (XHR)
2. this can be bypassed by using an img/form tag
Maybe i am wrong, but as far as i understood the SOP only prevents reads and not writes in ANY case (doesn't matter if with/without credentials or via javascript/tags).
Could you clear this up?
Otherwise:
Nice video i liked it :)
No. You are wrong.
1. Same-origin Policy deems page as "same-origin" conforming the following policies:
* Same schema/protocol ("" differs from "");
* Same domain ("example.com" differs from "www.example.com");
* and, same port ("80" differs from "8080")
Whereas in Internet Explorer is an exception, the 3rd attribute aforementioned (port) is not a resource required to match.
As you have noticed, the Same-origin Policy is a restriction rule to access the resource from a different origin(s). May this isn't explicit, but it includes local files as well. Therefore, the schema "file://" and "chrome://" is such a thing to be considered too.
2. The "HTML tags" are referred to as the Document Object Model (DOM). This DOM is a way to JavaScript reach all elements of the Berners-Lee's Hyper-Text Markup Language (HTML).
In the case of developers want to interact with different origins, they can use "document.domain" in JavaScript. Suppose a cross-domain from "account.example.com" and "api.example.com."
* current domain: "account.example.com"
`document.domain = "example.com" `
* current domain: "api.example.com"
`document.domain = "example.com"`
If you mention the subdomain on "document.domain" on the root domain, it would won't work.
The last thing you must need to understand is: *How "**reddit.com**" accept resources from "**i.imgur.com**"?*
So that's where it importance of the "Cross-origin Resource Sharing"(CORS) comes in.
When use an XMLHttpRequest object to send a request to a different origin, you may not be able to read the response. However, this request will still arrive at its destination. A way to SOP left you to read the "imgur.com" HTTP response headers or body data from "your-domain.com" with XHR is using CORS headers:
Access-Control-Allow-Origin: *.imgur.com (or just "*" to allow all websites)
Access-Control-Allow-Methods: POST, GET (you can specify others HTTP methods)
Access-Control-Allow-Headers: Origin, Accept, X-Requested-With (or any other headers)
* To allow credentials, authorizations headers, and TLS certificates:
Access-Control-Allow-Credentials: true
This header works in conjunction with `XMLHttpRequest.withCredentials`. Hence, if the request sends credentials and "your-domain.com," return the header, the browser would accept the cross-communication without restricting the web content. Otherwise, it will be ignored by the browser if the CORS preflight request not consent. (developer.mozilla.org/en-US/docs/Glossary/Preflight_request)
Now, look at this image and note the "Request URL" and its HTTP "Access-Control-Allow-*" headers: i.imgur.com/mCjU81f.png.
With PHP and cURL you can write a little proxy script to bypass same origin policy, f.e. could look like this: proxy.php?url_to_non_same_origin, i really have cases where i have to use this trick.
Sure you can do that but using that to actually get a third party site to commit actions not authorised by the user would need you to trick the user into logging into the other site via the proxy. Usually a CSRF attack is instead attempting to perform a confused deputy attack on the browser tricking it into using the users stored credentials (or cookies) for domain2 in order to perform actions at the direction of domain1.
For instance if the domain stealyourmoney.com wanted to transfer money from the users paypal account merely using stealyourmoney.com/paypal_proxy.php wont work as the browser will access that URL with the cookies scoped for stealyourmoney.com not paypal.com. Getting the user to log in via your proxy is more of a social engineering attack than a true CSRF since you are ultimately attacking the human vulnerabilities (abusing human naivety, trust, etc) not the technological ones.
You are right, abusing it for logins wont work, but i just wanted to share that info.
sauce, pls
I feel so dumb for not asking this question :P
Rare video where I don't have to turn the speed to 1.5x
Awsome :D Create videos more often :D
+Abiral Shrestha how am I supposed to do that? :D they are so much work and at some point I have to study and earn money.
@@LiveOverflow find an exploit for that
Now let's all agree never to be creative again.
Dont Hug Me Im Scared
49th
hmis
feel free to post your videos on /r/anarcho_hackers
+Christian Fernandez feel free to post the ones you think are interesting for that community ;)
:) well I will be glad but if I post them is not the same :) I do post some times.
+Christian Fernandez reddit user Community guidelines say, that self promotion is bad. And my posts got deleted from other subreddits because of that. So I prefer if people share videos they like :)
thanks a lot humble great master, phishing attack is a kind of man in the middle. sha1 and blockchain. pls teach us about VPN and there is a hacker with bad supposedly free vpn.
Thanks for the help on this! Just one thought - dropping a random F word in a training training video is pointless and is, by definition, offensive language. I would like to be able to watch this when my children are around. It just lowers the quality/standard of your video. Again thanks for passing you knowledge on!
document.origin is deprecated, use self.origin