How does Symfony2 CRSF protection work?

Question

I'm trying to test the CRSF protection system done by Symfony2, many thanks to them.
my security.yml template:(I modified the default one.)

security:

    firewalls:
        dev:
            pattern:  ^/(_(profiler|wdt)|css|images|js)/
            security: false

        login:
            pattern:  ^/demo/secured/login$
            security: false
        secured_area:
            pattern:    ^/demo/secured/
            form_login:
                check_path: _security_check
                login_path: _demo_login
                csrf_provider: form.csrf_provider
            logout:
                path:   _demo_logout
                target: _demo
            #anonymous: ~
            #http_basic:
            #    realm: "Secured Demo Area"

    access_control:
        #- { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: https }

In my form :

<input type="hidden" name="_csrf_token" value="{{ csrf_token("authenticate") }}">

That generates something like this:

<input type="hidden" name="_csrf_token" value="cKzXBHRDX_sHuT4qt9TAJIwgRvtRMtPnFDtitrSZDuw">

I don't know how symfony handles the verifications with the token, but before submitting my login, I changed the value of the token manually using firebug to look like this:

<input type="hidden" name="_csrf_token" value="MODIFIEDcKzXBHRDX_sHuT4qt9TAJIwgRvtRMtPnFDtitrSZDuw">

and when I submit my login, I get logged in. which means the token has no influence . where am I getting wrong ?

Snipe hunting

Symfony Version is 2.5.2
The system signed me in when I set manually a session variable "logged" to true. This happens after Reading from the database and comparing the passwords.

Form Html!

<form id="Loginform" onsubmit="OrganicLogin();return false;">
     <input type="hidden" name="_csrf_token" value="{{ csrf_token("authenticate") }}">
    <div id="Loginresponse" style="display:none;"></div>
        <div class="form-group" style="overflow:hidden;">
        <label style="margin-top:10px;" for="inputUsername" class="col-lg-2 control-label">Username</label>
        <div class="col-lg-10">
        <input type="text" class="form-control" id="inputUsername" placeholder="Username" style="width:215px;float:right;">
        </div>
        </div>
        <div class="form-group" style="overflow:hidden;" >
        <label style="margin-top:10px;" for="inputPassword" class="col-lg-2 control-label">Password</label>
        <div class="col-lg-10">
        <input type="password" class="form-control" id="inputPassword" placeholder="Password" style="width:215px;float:right;">
        </div>
        </div>
        <div class="form-group" style="overflow:hidden;text-align:center;" >
        <button type="submit" class="btn btn-primary btn-block" id="submitButton">Access</button>
        </div></form>

Yes ! I did
Actually that what I was arguing about the whole time, I did the login process in a native way, form, read data with JS, send POST request to controller, controller checks input and set the session.
No, All done by hand
Actually this is the first time I use security.yml, I just removed some parts I judged not useful for this thread
no ..

You can test ist via cURL and POST method (just don't set `_csrf_token` field) and print the output. — Lkopo, Sep 10 '14 at 14:39
I didn't mean cUrl test, your first comment means that just setting the csrf_token can bypass the protection ? Please if you know tell me how does symfony compare the $_POST['csrf_token'] and the other element .. I'm confused .. — Aysennoussi, Sep 10 '14 at 15:43
I still don't see why it works when I change the input manually, normally it should not work, right? — Aysennoussi, Sep 10 '14 at 15:45

score 2 · Accepted Answer · edited May 23 '17 at 12:09

I'm sort of guessing that your changed token is not getting posted. Stick a die in:

namespace Symfony\Component\Form\Extension\Csrf\CsrfProvider;

class DefaultCsrfProvider implements CsrfProviderInterface
{
    public function isCsrfTokenValid($intention, $token)
    {
        die('csrf token ' . $intention . ' ' . $token);
        return $token === $this->generateCsrfToken($intention);
    }

If the die is reached then you know your configuration is okay and of course you can see the actual posted token.

Needless to say, you should also clearcache.

=======================================================

Update 1 - After many comments we have determined that the die() is not being called. Progress.

Unfortunately we still need to verify exactly how the poster has configured their system.

Next step - Login without adjusting the csrf token via firebug and verify that the die statement is reached.

Report one way or another.

Needless to say (but I will say it anyways), make sure you logout before trying to log back in.

========================================================

Update 2 - The die statement is not being reached even with a normal login.

So now comes my favorite part. Snipe hunting. Basically, I made a number of assumptions when reading the question. Need to determine which assumptions were incorrect by asking a number of basic questions.

Which version of Symfony 2 are you using. I am assuming at least S2.1.
How do you know the system has signed you in? Are you using the debug toolbar and does it show you as being authenticated? What happens when you try to login with an incorrect password?
Use your browser's view source functionality and copy the generated form into your question. In particular I want to see the action attribute but I also want to see the input elements.
Did you in fact add the die statement to vendor/symfony/symfony/src/Symfony/Component/Form/Csrf/CsrfProvider/DefaultCsrfProvider.php? Did you save the file after editing it?
You are in fact using the standard form_login process right? You don't have any code that, for example, checks the user password?
Are you using any other bundles like maybe FOSUserBundle?
The security.yml file in your question really is your actual file? You didn't "clean it up" after copying?
Have you checked your application into github? If so then can you provide a link? Looking at the entire application will probably be the fastest way to clear this up.

That should be enough for now. Update your question with your answers.

=========================================================================

Update 3 - The plot thickens

As I was typing in the above questions we discover that the basic login system itself is not properly configured. The debug toolbar indicated the user is not authenticated. More progress! As so often happens, the symptoms were masking the actual problem.

The security system is arguably the most complicated component in Symfony 2 that typical developers need to interact with. It's easy to get confused when configuring it and difficult to troubleshoot. One tiny typo can melt things down. It's also very important for the developer to have a working understanding of how security is implemented. Unless of course you are a really big company like Target or Home Depot.

My suggestion is to create a fresh Symfony 2 project using composer. Then go through http://symfony.com/doc/current/book/security.html step by step and configure the security system. Let this be kind of a reference application for understanding security.

By the end of the process I suspect you will have figured out the problem and can apply the solution to your existing application. As a bonus you will have something you can refer to for future problems.

==================================================================

Update 4 - The exciting conclusion

So now we find that a custom and naive login system is being used.

I would still suggest starting over with a new project and get things working the Symfony 2 way. After that, you can tweak the login form to use javascript if you really want to.

If you really really really want to use your own system then start here: Manual authenticate user

But you would be tossing out one of Symfony's major strengths for no particular reason.

This is actually my original question, Do I need to add something in my controller to make the protection work ? — Aysennoussi, Sep 10 '14 at 15:34
Nope. It looks like your followed this: http://symfony.com/doc/current/cookbook/security/csrf_in_login_form.html. That is all you need to do. Controllers never get hit during the check login process. All done with listeners. If the die statement is reached then you have it configured properly. If not then you have something else going on. — Cerad, Sep 10 '14 at 15:44
If you really want the ugly details of user authentication then take a look at: http://symfony.com/doc/current/cookbook/security/custom_authentication_provider.html. But it's not for the faint of heart. Trust me when I say that ultimately, isCsrfTokenValid() gets called. — Cerad, Sep 10 '14 at 15:47
Thanks ! that's interesting. You said something tricky I'm not aware of. "Controllers never get hit during the check login process. All done with listeners" My login process is inside a controller! do I need to change something ? — Aysennoussi, Sep 10 '14 at 15:51
Your login_path uses a controller to present the login form. But when you post the form it goes to check_path. That get's picked up by a listener and does the actual user authentication. Once again, if you followed the book then you don't need to do anything else. — Cerad, Sep 10 '14 at 16:09
I only followed the book for the CSRF part, but the login part was done in a native way, everything was inside the controller and the controller was called directly. I think that's why the CSRF didn't work. what do you think? — Aysennoussi, Sep 10 '14 at 16:15
I think you should add the die statement and then report if it get's reached or not. If for some reason you don't want to do that then I'm sure there are plenty of other people who can help. And once again, your login_path controller has nothing to do with csrf checking. — Cerad, Sep 10 '14 at 16:20
I'll do it ! I just want to make sure I'm doing it in good practice . — Aysennoussi, Sep 10 '14 at 16:21
Ok. I updated the answer. Next step is to do a regular login and verify the die is reached. — Cerad, Sep 10 '14 at 16:34
I have a feeling that I'm doing the login procedure in a wrong symfony2 way. the symfony debug bar tells me I'm not authenticated — Aysennoussi, Sep 10 '14 at 16:41
Let's do it Bro! I'm getting excited as well ! I'll answer all your assumptions and will edit my question to post the answers in a readable format. — Aysennoussi, Sep 10 '14 at 16:58

Leo Bedrosian · Answer 2 · 2014-09-16T22:29:41.257

The way it's supposed to work is that Symfony generates a CSRF token, which it automatically inserts into the form. It stores this token in the current session. When the form is submitted, it compares the submitted token with the value stored in the session. Regarding your specific case, it just sounds like CSRF isn't actually enabled and it may have to do with security contexts not being shared between the secured area firewall, which has CSRF enabled, and the login firewall, which does not.

Try removing this bit in your security.yml:

login:
    pattern:  ^/demo/secured/login$
    security: false

And instead, moving it into the secured_area context and using access controls to grant access:

...

form_login:
    check_path: _security_check
    login_path: login
...

access_control:
    - { path: ^/demo/secured/login$, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: https }

Alternatively, you could try adding context: secured_area for your login firewall. In my experience, not having the login firewall in the same context as the secure area prevents you from accessing the security context entirely from within your login controller.

How does Symfony2 CRSF protection work?

2 Answers2

Linked