search

mattermost-community / focalboard

Focalboard is an open source, self-hosted alternative to Trello, Notion, and Asana.
https://www.focalboard.com
Other
22.02k stars 1.99k forks source link

Bug: Can't get CSRF token #5028

Closed sagos95 closed 4 months ago

sagos95 commented 4 months ago

Steps to reproduce the behavior

  1. Deploy Focalboard server locally with officially suggested way: docker run -it -p 80:8000 mattermost/focalboard
  2. Ensure that UI works
  3. Send POST request to http://localhost:80/api/v2/login with X-Requested-With: XMLHttpRequest header and obtain so called token. No any additional info was returned (no additilnal headers, etc)
  4. Try to call GET request http://localhost:80/api/v2/teams
  5. See error 
    {
"error": "checkCSRFToken FAILED",
"errorCode": 400
}

Expected behavior

Edition and Platform

Additional context (optional)

I also tried suggestions from previous issue 4420, but when I'm using API version any instead of v2, I'm getting some HTTP 200 response with HTML content which I could say tries to say that there is an error:

<!doctype html><html lang="en"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=0"><title>Focalboard</title><script>window.baseURL = ''</script><link rel="icon" href="/static/favicon.svg?v=1"/><script defer="defer" src="/static/main.js?ccf8d6c26f31398c2ea5"></script></head><body class="focalboard-body"><div id="focalboard-app"></div><div id="focalboard-root-portal"></div></body></html>
sagos95 commented 4 months ago

Turned out that the server doesn't require some token itself, instead it requires just X-Requested-With: XMLHttpRequest header header for consequent requests and that's it. Though I found a solution, a true CSRF protection mechanism works different and involves generating a unique, random token for each session (or request). This token is then included in forms or API requests and validated on the server side. The method I saw in the application source code is much simpler and less secure, so I can't say that this is "CSRF token check fail" literally. I'd rather call this a bug.

PS: The source code checks if the X-Requested-With header is set to XMLHttpRequest value. If this header is present, the request is considered valid