0

I've read several PHP-security books, but after reading one I got confused about the definition of a CSRF (Cross-Site Request Forgery). Wikipedia explains it as this:

Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

Normally this exploits goes about sending two requests, one for getting a token, and one for getting a token to reset e.g an administrator account. By example exploiting the vulnerability where a website generates weak entropy tokens by using e.g mt_srand(). Right?

But what if a website logs which browser you're using by collecting it's user_agent string? E.g: AdminPanel.php:

<?php
    $browser = $_SERVER['HTTP_USER_AGENT'];
    addToLog($browser);

    $logs = getAllLogs();
    echo $logs;
?>

Normally this'd return: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0

But I could edit my user-agent string in Firefox:

+----------------------------+----------+--------+-----------------------------------------------------------------------------------------------------+
| general.useragent.override | user set | string | <script>window.location.replace('http://myHackerServer.com/fakeAdminPageForPhishing.php');</script> |
+----------------------------+----------+--------+-----------------------------------------------------------------------------------------------------+

This way the Javascript code would be executed on the Admin-panel. So this way, you can exploit the XSS when the administrator logs the user-strings of users, and than checks it later.

But is this XSS or CSRF? I mean, the website does trust the user's browser to contain valid values. Like Wikipedia says. It doesn't necessary trust 'user-input' like in XSS. I got confused by what CSRF is, I've seen loads of different definitions.

Thanks.

  • Yeah. But I was rather thinking about a scenario where an administrator logs the user-agent strings. So you could exploit the XSS on the admin if he checks his logs in a HTML-environment. – O'Niel Jul 30 '16 at 18:00
  • Ok, it is exploitable in that case, and it would be stored XSS. Your example code is misleading; I suggest you replace it with the text in your comment. – paj28 Jul 30 '16 at 18:12
  • @paj28 Edited.. – O'Niel Jul 30 '16 at 18:26
  • 1
    @paj28 I think that coding a log-system with writing and reading from files, and different pages (the index logging, and the panel reading) would be more confusing for people. I just make this example to show what I mean with 'reading the user-agent' string. Edited (again) though. – O'Niel Jul 30 '16 at 21:18
3

Your example is XSS. The full definition of CSRF from Wikipedia:

Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.

Example of a CSRF attack: let's say you own a website example.com, and you have a shop where users can buy items using GET requests. An example link would be: example.com/shop/purchase?itemId=123456, and it doesn't perform any authentication but making sure the user is online. You land on the page - Boom, $30 are withdrawn from your bank account.

Now, an attacker could take that link and mask it inside an email, or by embedding it into a clickable image on an active forum - thus making it appear safe (click here to read more, etc). When a user clicks that link (who does not want to buy that item) - he's automatically charged the $30 which he didn't even want to spend!

The protection against this is fairly simple - You generate a unique CSRF token for every user when his session is created, and force him to pass the token as a parameter. So now your link is example.com/shop/purchase?itemId=123456&token=abcdefg. Now, an attacker can't send me "malicious" links - because he doesn't know my token!

As you can see, this attack really has nothing to do with Javascript. Your example was persistent XSS (an interesting topic by itself, albeit unrelated to your question so I won't dive into it here)

  • 1
    Won't it rather be Persistence XSS because it being injected in the logs? Log-injection? – O'Niel Jul 30 '16 at 18:27
  • You're correct, missed the part where you said it's stored in the logs. Fixed my answer :) – Tom Jul 30 '16 at 19:04
-1

The explanation by Tom is good but I would add the following. Typically, when you authenticate on a website you are given assigned a token that typically stores in a browser session cookie and for each subsequent request the cookie identifies you.

Now for each request to same domain your browser will issue the cookie.

If an adversary creates a hidden image in a page and performs a GET request to the domain, the server-side has no idea if this is legitimate or not.

This is where a CSRF token comes into play. If the server side has another identifier independent of the cookie they can validate against it.

It is important the CSRF token is bound to the users session cookie.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.