pierre Posted June 15, 2016 Share Posted June 15, 2016 Hello, I'm understanding how CSRF works. On DVWA, at medium level, here is some of the correction provides: // Checks to see where the request came from if( eregi( $_SERVER[ 'SERVER_NAME' ], $_SERVER[ 'HTTP_REFERER' ] ) Do you what eregi() function is used ofr ? I think SERVERNAME is my server_@IP ? But what is http_referer ? Quote Link to comment Share on other sites More sharing options...
digininja Posted June 15, 2016 Share Posted June 15, 2016 Did you try googling for eregi? http://php.net/eregi The comment with the code describes what it does, it checks the server name (SERVER_NAME) against the referer ( HTTP_REFERER ) to check that the page that the user was on before this one was on the same site. It is basically a way to try to enforce the page only being accessed from another page on the same site. As the referer can be spoofed, this is really bad protection. Quote Link to comment Share on other sites More sharing options...
pierre Posted June 15, 2016 Author Share Posted June 15, 2016 Yes I've googled, is it a comparaison function ? Yes it is the medium protection. Ah because on my test either HTTP_REFERER is the pirates web server IP or the field is blank... So HTTP_REFERER could be equal to SERVER_NAME ? Quote Link to comment Share on other sites More sharing options...
digininja Posted June 15, 2016 Share Posted June 15, 2016 From the URL I sent Quote eregi — Case insensitive regular expression match yes, it compares the two values using regular expressions. The check is if the referrer, the page you are coming from, is on the same host as the page you are going to (technically not quite that but close enough) meaning HTTP_REFERER has to include SERVER_NAME for the match and so the code to get executed. Quote Link to comment Share on other sites More sharing options...
fugu Posted June 15, 2016 Share Posted June 15, 2016 (edited) i don't know if you have the ability to modify the code, but if you can add echo "<pre><code>"; var_dump($_SERVER); echo "</code></pre>"; will let you examine all the various header entries that are stored in the $_SERVER variable during your request. Edited June 15, 2016 by fugu Quote Link to comment Share on other sites More sharing options...
pierre Posted June 16, 2016 Author Share Posted June 16, 2016 (edited) 21 hours ago, fugu said: i don't know if you have the ability to modify the code, but if you can add echo "<pre><code>"; var_dump($_SERVER); echo "</code></pre>"; will let you examine all the various header entries that are stored in the $_SERVER variable during your request. Yes I test with this code : <html> <head> <title>PHP Test</title> </head> <body> <?php echo ('Hello you come from '.$_SERVER['HTTP_REFERER'].' ! '); echo ('Hello you come from '.$_SERVER['SERVER_NAME'].' ! '); if( eregi( $_SERVER[ 'SERVER_NAME' ], $_SERVER[ 'HTTP_REFERER' ] ) ) { echo("Same IPs"); } else { echo("Different IPs"); } ?> </body> </html> I just fucking don't know how to add a new line in PHP but it works never mind :) 22 hours ago, digininja said: From the URL I sent yes, it compares the two values using regular expressions. The check is if the referrer, the page you are coming from, is on the same host as the page you are going to (technically not quite that but close enough) meaning HTTP_REFERER has to include SERVER_NAME for the match and so the code to get executed. Yes but my HTTP_REFERER is either blanck or the IP from my hacker webserver (Kali) when the W7 hosts click on my Kali webserver to be redirect the Ubuntu webserver (CSRF) : Cc: I'm well block with the protection: if( eregi( $_SERVER[ 'SERVER_NAME' ], $_SERVER[ 'HTTP_REFERER' ] ) I plan on how to inject HTTP_referer valued in an HTTP request to bypass the boolean protection above ! Edited June 16, 2016 by tot94 Quote Link to comment Share on other sites More sharing options...
digininja Posted June 16, 2016 Share Posted June 16, 2016 Quote Yes but my HTTP_REFERER is either blanck or the IP from my hacker webserver (Kali) :) if you go to the page directly then it will be blank as you've not been referred there by anything, if you go to it from another page on your server then it will that page. If you put a link to that page on a different server and go to it from there you'll probably get that page. Quote Link to comment Share on other sites More sharing options...
pierre Posted June 16, 2016 Author Share Posted June 16, 2016 1) I go to the page directly -> HTTP_REFERER=BLANK 2) I go from http://192.168.1.1/DVWA/index.php to http://192.168.1.1/DVWA/vulnerabilities/csrf/test.php -> HTTP_REFERER=BLANK 3) I go from http://192.168.0.1/index.html to http://http://192.168.1.1/DVWA/vulnerabilities/csrf/test.php -> HTTP_REFERER=192.168.0.1 So do you why in the 2nd situation, HTTP_REFERER header is still blank ? Quote Link to comment Share on other sites More sharing options...
digininja Posted June 16, 2016 Share Posted June 16, 2016 In two, how do you get from the first page to the second? Quote Link to comment Share on other sites More sharing options...
fugu Posted June 17, 2016 Share Posted June 17, 2016 doesn't ereg and eregi use regular expressions? If you have control of what will end up in the referrer field, couldn't you try and make the referrer a very widely encompassing regex like .* or something? I'm not sure the * is valid in the hostname location but maybe you can figure something out. Quote Link to comment Share on other sites More sharing options...
pierre Posted June 17, 2016 Author Share Posted June 17, 2016 18 hours ago, digininja said: In two, how do you get from the first page to the second? Simply by navigating on the website. But another interesting thing, if from the W7 host : I run this html page with javascript included: <html> <head> <title>Yo</title> </head> <body bgcolor=white> <script> window.onload = function(){ window.open("http://192.168.1.1/DVWA/vulnerabilities/csrf/test.php"); window.open("http://192.168.1.1/DVWA/vulnerabilities/csrf/?password_new=test&password_conf=test&Change=Change"); } </script> </body> </html> Test.php is a page to test compare HTTP_REFERER & SERVER_NAME global variable, it prints this: Hello you come from ! Hello you come from 192.168.1.1 ! Different IPs -> no HTTP_REFERER IP detect, blanck That request didn't look correct. -> it means I can't change login/password HTTP_REFERER restriction even if HTTP_REFERER is blanck.. 4 hours ago, fugu said: doesn't ereg and eregi use regular expressions? If you have control of what will end up in the referrer field, couldn't you try and make the referrer a very widely encompassing regex like .* or something? I'm not sure the * is valid in the hostname location but maybe you can figure something out. Yes the point here is to bypass HTTP_REFERER restriction, on one client I can do BURP proxy :) But on a client who has been redirected to the website by another webserver, I don't how to bypass HTTP_REFERER header.. Quote Link to comment Share on other sites More sharing options...
digininja Posted June 17, 2016 Share Posted June 17, 2016 Quote But on a client who has been redirected to the website by another webserver, I don't how to bypass HTTP_REFERER header.. Simply intercept the request in Burp and add or edit the header before the request is passed on. Quote Link to comment Share on other sites More sharing options...
fugu Posted June 17, 2016 Share Posted June 17, 2016 https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet Quote Checking The Referer Header If the Origin header is not present, verify the hostname in the Referer header matches the site's origin. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce or server-side state doesn't exist. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token. In both cases, just make sure your origin check is strong. For example, if your site is "site.com" make sure "site.com.attacker.com" doesn't pass your origin check (i.e., match through the trailing / after the origin to make sure you are matching against the entire origin). I think this is the solution to that challenge, if I'm not mistaken. Quote Link to comment Share on other sites More sharing options...
pierre Posted June 20, 2016 Author Share Posted June 20, 2016 (edited) On 17/6/2016 at 0:37 PM, digininja said: Simply intercept the request in Burp and add or edit the header before the request is passed on. Yes but a client who has been redirected by a hacker webserver isn't supposed to use Burp. On 18/6/2016 at 1:19 AM, fugu said: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet I think this is the solution to that challenge, if I'm not mistaken. Ok I'll change my hacker webserver DNS. :) EDIT: Header Referer at 192.168.1.1 or http://192.168.1.1 make it works :) Edited June 21, 2016 by tot94 evolution Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.