Gogs: Invalid csrf token

[ChangePlaces]

If I open an issue in a new tab from the issues page. Sometimes when I go to add a comment, I get the message "invalid csrf token". I assume this is because I have tabbed from a page that hasn't been refreshed for a while.

When I open a new issue, does the CSRF token need to be re-set or updated?

[unknwon]

I encounter this when switch between demo site and local instance because they use exact same config.

Refresh the page fixes the problem.

[ChangePlaces]

Yes, a page refresh fixes the problem, but can it be prevented at all?

[unknwon]

I'm not very sure but I think it's caused by browser cache for some kind of faster load.

[buzz]

dup of #715

[ChangePlaces]

I've just added a comment to #715. I'm not sure which issue to use! Maybe as the other contains more info, it should be re-opened?

[unknwon]

I think all comments should go here now...

[ChangePlaces]

Let's try this again! ;)

I think these are the exact steps to reproduce:

1. Open an issues queue in a tab.
2. Leave it for a certain number of hours (I'm not sure if it's, say 2, or lots more like 8).
3. Afterwards, go back to that tab, and click the 'create new' issue or open an issue
4. Either create a new issue, or add a new comment
5. Invalid csrf

To resolve, you can just press back, refresh (which leaves your text there) then submit again. But this is messy. As a (hopefully) temporary solution, I'm using a reload plugin for firefox which reloads the issue pages every x minutes. (I have the tabs pinned open)

[DigitalEnki]

I get this issue too - and sometimes it's not a matter of hours the browser is idle but sometimes minutes, if it's a session timeout issue maybe some pulse mechanism may be a solution?

[webhat]

I have the same issue. _bump_

[unknwon]

I found the way to reproduce 100%.

Completely quit browser, reopen and directly visit http://localhost:3000/repo/create . Submit, Boom!

[unknwon]

I have pushed fix to develop branch.

[unknwon]

Close as fixed?

[webhat]

:+1:

[evook]

Hi,

I still get this error sometimes. How long is the CSRF Token valid and in which assets is it saved. I guess javascript? I think it has something to do with my proxy caching to deliver statics via http2 and the cache keep-alive.

[unknwon]

@evook thanks! I think it's problem with Gogs, I'll reopen this issue.

[ChangePlaces]

can confirm this still happens - same steps to repeat. open issues pages. open a new issue page in a new tab, submit new issue and you hit 'invalid csrf token'. i do disable the browser referer string

[barsanuphe]

I can also confirm this bug; no need to open a new issue in a new tab though.

[unknwon]

I plan to use JWT to completely solve this issue.

[unknwon]

Got some ideas, will give another shot in 0.9.

Note: use redirect instead of auto-signin.

[lunny]

I think this is because xsrf check timeout is less than cookie timeout.

[unknwon]

@lunny good point! I'll keep in mind.

[dakira]

Just to add to what's been said. I get this all the time. Refreshing the page doesn't fix it for me. I need to log out and back in again.

[adamdullenty]

Jumping on this too, I get this and it's not directly related to opening 'new issue' in a new tab either. It happens in the tab which Gogs is already open in, although it's possible that it was opened in a new tab previously before navigating to the issue page.

[captbrogers]

I have the same issue when adding a webhook.

From a project page:

1. Select settings link
2. Select webhooks link from left-side navigation
3. Select "Gogs" from dropdown
4. Enter information
5. Submit form

Returns invalid csrf token. It will work if, after selecting "Gogs" from the dropdown, the page is refreshed.

Go version: 1.5.3
Gogs version: 0.8.43.0223

[CapMousse]

Same issue when editing project properties

1. Open a project
2. Go to settings
3. Edit main infos of the project
4. Send the form

Gogs version 0.8.43.0223

EDIT The issue only happen when using Nginx. Direct access don't trigger the error

[ChangePlaces]

@CapMousse

The issue only happens when using Nginx

Interesting, I can confirm I'm using nginx too.

[unknwon]

Did an attempt to solve this issue, if it's not working, will be postponed after 0.9 milestone.

You guys can test on https://try.gogs.io as well.

[unknwon]

Please do go get -u github.com/go-macaron/csrf and recompile Gogs see if problem solved.

[ChangePlaces]

I'd like to help test this, but now confused as to how to recreate the problem. Can we get a list of ways to recreate please? I've just opened a list of my issues on try.gogs.io and will wait a few hours to then submit a change to an issue as this is the only way I know of causing the bug.

[unknwon]

@ChangePlaces Just updated to latest version and use normal, there is no certain way to 100% reproduce this right now...

[ChangePlaces]

Ohh... It's one of "those" is it!

Well, I just added a comment to an issue from a page that has been open for hours, and it let me do it without the csrf issue which is how I remember seeing the error. So, I guess that's good news at least!

[evook]

It didn't happened during my workflow today. Seems to be fixed.

[DigitalEnki]

This isn't limited to nginx - i am running it on apache2 and i got this - but much less often than when i was running it on nginx

Gogs: 0.9.0.0306
Go: 1.6

[adamdullenty]

Seems to happen more frequently for me when I add labels to the issue
before hitting save.

On Wed, Mar 9, 2016 at 3:06 PM, Danny Hearnah [email protected]
wrote:

This isn't limited to nginx - i am running it on apache2 and i got this -
but much less often than when i was running it on nginx

Gogs: 0.9.0.0306
Go: 1.6

—
Reply to this email directly or view it on GitHub
https://github.com/gogits/gogs/issues/1891#issuecomment-194335887.

[petarov]

I had this issue today occurring once on 0.8.43 and then on 0.9.0.0306. It happened upon creating a new repo or sending test mail from Configuration. Restarting gogs or nginx didn't fix the issue, but a log out and log in again did. Maybe it's user session related.

[dakira]

I can still reproduce this in 0.9.1.0306.

[unknwon]

@dakira 100% after refresh the page?

[dakira]

@Unknwon No. Force-refreshing now allows me to proceed (before I had to log out and back in to get rid off the error).

[unknwon]

Damn this bug... :sob:

[ChangePlaces]

Could it be caused by the way nginx handles cookies / sessions differently than to apache?

[unknwon]

Had discussion with @dakira on gitter, found one possible reason, fixing.

[unknwon]

OK guys, let's try 0.9.8!

Please update all deps!

[dakira]

I just updated. Can't find any cookies anymore being set at all for the domain I have gogs running under. 3 cookies are created on login but they are gone once I close the browser and restart it. How are you tracking sessions? Are you saving sessions under the main domain?

[unknwon]

@dakira https://github.com/gogits/gogs/blob/master/conf/app.ini#L209

[dakira]

Well, strange. Chrome doesn't show me any cookies for the domain but everything looks to be working. I can't reproduce the error anymore.

[unknwon]

@dakira yes, you need to find cookie in the icon near URL, not in response header.

[biji]

@Unknwon I want to try version 0.9.8, but can not find in releases
thanks

[dakira]

@biji It's a development version that you manually have to compile. This will probably soon released as a regular package when @Unknwon is convinced this is fixed. I tested this for three days now and couldn't find any problems.

[unknwon]

OK, I'm closing this right now.

Just to note, change of SECRET in app.ini can cause this error as well, but that's the fault of Gogs. You can fix that by delete data/sessions directory.

[oleersoy]

I'm still getting seemingly whenever I try to do something from a fresh tab when Gogs has not been used for a while. For example:
1) Open new tab and go to gogs URL
2) Try to create an issue or a new repository
3) Get the invalid csrf token message

At this point I can just open another fresh tab and now everything works.

So it seems like the first time I open a new tab the connection tries to reuse a stale CSRF token, and this causes Gogs to realize that the token is stale. Then on the subsequent connection Gogs sends a new token, and now it's all good.

[unknwon]

@oleersoy are you able to reproduce on https://try.gogs.io?

[unix4you2]

Hi everyone!

I found that this error message is presented when ther is a difference between the time you logged in GoGs and the actual time in your server.

Hot to reproduce the issue:

1. Login to your GoGs installation
2. Go to your server and change the date/time (in my case I update the time to five hours ago)
3. Try to do any write operation in your repository by web interface (like create a new label for your Issues).
4. The error message will be displayed.

How to solve: Logout and re-Login. Thats all.

Regards.

[oleersoy]

Does https://try.gogs.io run from the Docker container install?

[oleersoy]

Just wanted to echo the behavior I'm seeing, since I just performed the experiment again - after not having used Gogs for 12 hours. I opened a new tab in firefox, filled in the form for a new repository, and when I clicked submit I got the invalid csrf token message. After that upon opening another tab everything works fine.

[oleersoy]

I just looked up how CSRF protection should be implemented here:
http://security.stackexchange.com/questions/162/what-is-the-correct-way-to-implement-anti-csrf-form-tokens

Here's a quote:

As per your comments, if you need to implement this yourself, your solution is not too bad, but I would simplify it.
You can generate a crypto-random nonce (long enough), store that in session memory, and change it every X minutes (you store the expiry time in session too). In each form, you include the nonce in a hidden form field, and compare that value when the form is posted.
If the form token matches, you're clear. If not, you can accept e.g. the previous token as well, to handle the edge cases.

I think the key part is:

If not, you can accept e.g. the previous token as well, to handle the edge cases.

It looks like Gogs is not handling this edge case.

[unknwon]

Just wanted to echo the behavior I'm seeing, since I just performed the experiment again - after not having used Gogs for 12 hours. I opened a new tab in firefox, filled in the form for a new repository, and when I clicked submit I got the invalid csrf token message. After that upon opening another tab everything works fine.

It sounds reasonable to me, which does the job to protect attacking from expired session.

[oleersoy]

It's certainly pretty easy to just open two tabs such that the token refreshes itself, although it seems like there has to be a simple work around for this. For example if I go to my github account right now (Which I have not done for at least 12 hours) I can create a new repository without getting the invalid CSRF token message. The same thing goes for any other OAUTH service I use.

I can't replicate the behavior on try.gogs.io because it logs me out automatically after a time period that's shorter than the period needed to trigger the behavior.

[unknwon]

@oleersoy sounds like you have the wrong config, what have you changed?

[oleersoy]

@Unknwon which part of the config do you think is wrong and why?

[unknwon]

@oleersoy you did not answer my question: what have you changed?

[oleersoy]

I followed the instructions for the docker install. I'm using a data volume mounted to :/data. Here's my configuration:

    / # cat data/gogs/conf/app.ini 
    APP_NAME = Gogs Git Service
    RUN_USER = git
    RUN_MODE = prod

    [database]
    DB_TYPE  = sqlite3
    HOST     = 127.0.0.1:3306
    NAME     = gogs
    USER     = root
    PASSWD   = 
    SSL_MODE = disable
    PATH     = /data/gogs/gogs.db

    [repository]
    ROOT = /data/git/gogs-repositories

    [server]
    DOMAIN       = 203.0.113.1
    HTTP_PORT    = 3000
    ROOT_URL     = http://203.0.113.1:3000/
    DISABLE_SSH  = false
    SSH_PORT     = 22
    OFFLINE_MODE = false

    [mailer]
    ENABLED = false

    [service]
    REGISTER_EMAIL_CONFIRM = false
    ENABLE_NOTIFY_MAIL     = false
    DISABLE_REGISTRATION   = false
    ENABLE_CAPTCHA         = false
    REQUIRE_SIGNIN_VIEW    = true

    [picture]
    DISABLE_GRAVATAR = false

    [session]
    PROVIDER = file

    [log]
    MODE      = file
    LEVEL     = Info
    ROOT_PATH = /data/gogs/log

    [security]
    INSTALL_LOCK = true
    SECRET_KEY   = v3Dx22777DC35VP

[unknwon]

Thanks, nothing looks usual, running out of ideas..

[oleersoy]

I'm right in the middle of experimenting with various Spring Boot security configurations / Concepts ATM ( go-lang is on my todo list :) ). I'll try to build a better understanding of the dynamics and come back to this.

I'll ask around as well. Thanks again for all your great work on Gogs. Hopefully I can be of more help on this one.

[oleersoy]

Scratch the issues I reported above. Since upgrading to the absolute latest version I no longer see them. Sorry for the noise.