I like how you explained this but i do have one question. This works well when the attacker is remote, but when their local they are able to see the traffic(what ever means they wish to do it, and assuming the side doesn't use SSL)and in turn able to see the token as plain text and can mount an attack based on that. Is there a better way without including it as plain text on the page? Love the videos, i don't use PHP much any more but i still like to keep up with it as well as your a very good teacher.
In delete.php require 'app/bootstrap.php' should come after if($_SERVER['REQUEST_METHOD']!=="POST") { die(); } because if an attacker tricks the logged in user to click a link which is navigating to delete.php, in that time its a GET request but in bootstrap.php validations is only for POST REQUEST , if any GET request hits the page it will create a new CSRF token that results in logged user to get invalid CSRF token error message if he/she clicks on delete button.
I noticed that you demonstrated how to generate and validate CSRF tokens in PHP to protect against CSRF attacks. However, I'm worried that this approach may not be sufficient to prevent attacks if an attacker manages to set a session on their malicious page. If an attacker can trick a user into visiting their malicious page, couldn't they potentially exploit the user's active session to perform unauthorized actions? For example, if the user is logged into a website with an active session and then visits the attacker's page, couldn't the attacker use JavaScript to send requests with the user's session cookies, bypassing the CSRF protection? Thanks!
I don't think this particular scenario will work in a real-life situation because in order for it to work, the attacker's page needs to be on the same domain as the target page (which is highly unlikely). Otherwise, the AJAX request from the attacker's page will fail because of the same-origin policy enforced by the browser.
+Михайло Вишнепольський Yes, if the attacker tricks the user into performing a GET request to the URL it would work, but since in the example shown, the request to the URL is done through AJAX, it won't work unless the attacker's page and the target page are on the same domain, which is highly doubtful.
This is my first comment after 10 years of using RUclips, but I just couldn't pass without answering this: CORS requests can be sent cross-domain, reading them is unnecessary in this case. what CORS and SOP enforce with ajax is not sending back a response, but any website can make an Ajax request to another. this is a very widespread misconception and introduces a lot of bugs in websites ;)
Can you make a tutorial about CSRF Tokens that works for multiple tabs and windows browsing ? You're previous tutorials about creating CSRF Tokens are not multiple tabs and windows friendly.
Unless im missing something, this will only protect against CSRF performed in a script under the same domain? So this is not really useful in real world applications?
Why? You can just setup in your php referer header and filter everything thats going from outside of your domain, if that going from some registered user inside your page, you can use setup md5 for all your files, and only files referal links can access your db if referal.php page gas exact checksum... 😁
Couldn't the author of the CSRF php page just use a file_get_contents to make the request for the index to grab the token, then echo it out as a submitted variable when making the ajax request for the delete.php? I understand how CSRF makes things a little more secure, but in my opinion, it just makes it slightly more difficult, but only if the author of the csrf.php file doesn't really think things through a little more.
I still don't see why the author couldn't use file_get_contents() on index.php (where the hidden field is located), then echo that value into the jquery post request for the delete.php page, thus allowing it to delete a user (or at least deactivating the account). Let's say I have a page called badsite.com/csrf.php and I am already signed into goodsite.com. Now, say goodsite.com has a form on the index.php with a CSRF token and a page called delete.php where it requires a post request with that token included to remove the account. So, by going to badsite.com/csrf.php, it would do file_get_contents('goodsite.com/index.php') to reroll the token and use preg_match() to save that token to its own variable that it would then include in jquery post request with the token value to the page goodsite.com/delete.php. I don't see why this couldn't be done. Am I wrong? What is protecting the user from that? By the way, I haven't checked to see if badsite.com and goodsite.com are real websites. Any resemblance to a real website is purely coincidental.
Manolis Agkopian That was a very good explanation on exactly why it wouldn't work. However, that will only work if you make it regenerate every request. If you use the same token for an entire session you'd be screwed anyway.
Ah. I think I get it now. You are saying that since I'm not signed in as the user, the token I get from the file_get_contents wouldn't apply. I suppose if you did do an XSS attack first to capture the cookie and submit it in the context section to get his token, that might be one way to do this. However, that is easily thwarted by simply using the http only cookies that Alex covered in a previous video. Pretty neat stuff.
+FFVison What you describe can be a major concern, if you replace the file_get_contents method with AJAX. This would require the resource to allow authenticated CORS from the attacker's site, which granted probably won't be the case normally, but it speaks to why blanket enabling CORS headers in web sever configs can be a security concern. If authenticated CORS was enabled, the attacker's page could use an AJAX request to get the token, and then do the POST.
I like how you explained this but i do have one question. This works well when the attacker is remote, but when their local they are able to see the traffic(what ever means they wish to do it, and assuming the side doesn't use SSL)and in turn able to see the token as plain text and can mount an attack based on that. Is there a better way without including it as plain text on the page? Love the videos, i don't use PHP much any more but i still like to keep up with it as well as your a very good teacher.
In delete.php
require 'app/bootstrap.php' should come after
if($_SERVER['REQUEST_METHOD']!=="POST")
{
die();
}
because if an attacker tricks the logged in user to click a link which is navigating to delete.php, in that time its a GET request but in bootstrap.php validations is only for POST REQUEST , if any GET request hits the page it will create a new CSRF token that results in logged user to get invalid CSRF token error message if he/she clicks on delete button.
I noticed that you demonstrated how to generate and validate CSRF tokens in PHP to protect against CSRF attacks. However, I'm worried that this approach may not be sufficient to prevent attacks if an attacker manages to set a session on their malicious page.
If an attacker can trick a user into visiting their malicious page, couldn't they potentially exploit the user's active session to perform unauthorized actions? For example, if the user is logged into a website with an active session and then visits the attacker's page, couldn't the attacker use JavaScript to send requests with the user's session cookies, bypassing the CSRF protection?
Thanks!
I don't think this particular scenario will work in a real-life situation because in order for it to work, the attacker's page needs to be on the same domain as the target page (which is highly unlikely). Otherwise, the AJAX request from the attacker's page will fail because of the same-origin policy enforced by the browser.
yep
could work only on same domain, perhaps with combination with js injection through a comment or some post...
+Михайло Вишнепольський Yes, if the attacker tricks the user into performing a GET request to the URL it would work, but since in the example shown, the request to the URL is done through AJAX, it won't work unless the attacker's page and the target page are on the same domain, which is highly doubtful.
+Aleksandar Salov exactly. This is worthless advice.
This is my first comment after 10 years of using RUclips, but I just couldn't pass without answering this: CORS requests can be sent cross-domain, reading them is unnecessary in this case. what CORS and SOP enforce with ajax is not sending back a response, but any website can make an Ajax request to another. this is a very widespread misconception and introduces a lot of bugs in websites ;)
Can you make a tutorial about CSRF Tokens that works for multiple tabs and windows browsing ? You're previous tutorials about creating CSRF Tokens are not multiple tabs and windows friendly.
awesome demonstrations...
Thank you very much, really nice way to explain it.
Unless im missing something, this will only protect against CSRF performed in a script under the same domain? So this is not really useful in real world applications?
Your tutorial is awesome
thank you Alex !
thanks a lot, that's very useful for me ...
Thank you very much
Why? You can just setup in your php referer header and filter everything thats going from outside of your domain, if that going from some registered user inside your page, you can use setup md5 for all your files, and only files referal links can access your db if referal.php page gas exact checksum... 😁
so exactly how well does this protect against csrf?
ocast evo good enough
Couldn't the author of the CSRF php page just use a file_get_contents to make the request for the index to grab the token, then echo it out as a submitted variable when making the ajax request for the delete.php? I understand how CSRF makes things a little more secure, but in my opinion, it just makes it slightly more difficult, but only if the author of the csrf.php file doesn't really think things through a little more.
+FFVison No, because when he does that he gets a different CSRF token than you would.
I still don't see why the author couldn't use file_get_contents() on index.php (where the hidden field is located), then echo that value into the jquery post request for the delete.php page, thus allowing it to delete a user (or at least deactivating the account).
Let's say I have a page called badsite.com/csrf.php and I am already signed into goodsite.com. Now, say goodsite.com has a form on the index.php with a CSRF token and a page called delete.php where it requires a post request with that token included to remove the account. So, by going to badsite.com/csrf.php, it would do file_get_contents('goodsite.com/index.php') to reroll the token and use preg_match() to save that token to its own variable that it would then include in jquery post request with the token value to the page goodsite.com/delete.php.
I don't see why this couldn't be done. Am I wrong? What is protecting the user from that? By the way, I haven't checked to see if badsite.com and goodsite.com are real websites. Any resemblance to a real website is purely coincidental.
Manolis Agkopian That was a very good explanation on exactly why it wouldn't work. However, that will only work if you make it regenerate every request. If you use the same token for an entire session you'd be screwed anyway.
Ah. I think I get it now. You are saying that since I'm not signed in as the user, the token I get from the file_get_contents wouldn't apply. I suppose if you did do an XSS attack first to capture the cookie and submit it in the context section to get his token, that might be one way to do this. However, that is easily thwarted by simply using the http only cookies that Alex covered in a previous video. Pretty neat stuff.
+FFVison What you describe can be a major concern, if you replace the file_get_contents method with AJAX. This would require the resource to allow authenticated CORS from the attacker's site, which granted probably won't be the case normally, but it speaks to why blanket enabling CORS headers in web sever configs can be a security concern. If authenticated CORS was enabled, the attacker's page could use an AJAX request to get the token, and then do the POST.