"CSRF token verification failed" for new Login Attempts - Existing Sessions Remain Working

Infos:

  • Used Zammad version: 5.2.2-11
  • Used Zammad installation type: docker-compose
  • Operating system: debian buster
  • Browser + version: Safari 15.6.1, Firefox 91, Chomium 90.0.4430.212

Expected behavior:

  • I can login to Zammad

Actual behavior:

  • Every new login attempt is rejected displaying the error message: CSRF token verification failed!
    Existing sessions remain active, even after restarting the docker containers via “docker-compose down” and “docker-compose up -d”
    I transferred the zammad instance from a package installation to docker-compose on a shared docker installation using traefik as a reverse proxy by Aug 30 with version 5.2.1-7 and by then the login was possible from all clients and all browsers.
    On Sep 6 the first Agent complained not to be able to login with the above error message but, he is only part time and busy with other topics, so I coudn’t follow up on that immediately. Meanwhile only one Agent is still able to work with zammad, so things are getting urgent.

The respective log entry of the zammad-nginx container reads:

“POST /api/v1/signin HTTP/1.1” 401 102 “https://zammad.< Domain>/” “Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0”

The respective log entry of the zammad-railsserver container reads:

I, [2022-09-21T14:13:45.099912 #1-111080] INFO – : Started POST “/api/v1/signin” for 172.25.0.2 at 2022-09-21 14:13:45 +0000

I, [2022-09-21T14:13:45.109455 #1-111080] INFO – : Processing by SessionsController#create as JSON

I, [2022-09-21T14:13:45.109572 #1-111080] INFO – : Parameters: {“username”=>“< Correct username>”, “password”=>“[FILTERED]”, “fingerprint”=>“540605522”}
I, [2022-09-21T14:13:45.124603 #1-111080] INFO – : CSRF token verification failed
I, [2022-09-21T14:13:45.124865 #1-111080] INFO – : CSRF token verification failed! (Exceptions::NotAuthorized)
app/controllers/application_controller/prevents_csrf.rb:36:in verify_csrf_token' app/controllers/application_controller/has_download.rb:21:in block (4 levels) in module:HasDownload
app/controllers/application_controller/has_download.rb:20:in block (3 levels) in <module:HasDownload>' app/controllers/application_controller/has_download.rb:19:in block (2 levels) in module:HasDownload
app/controllers/application_controller/handles_transitions.rb:16:in `handle_transaction’
I, [2022-09-21T14:13:45.126709 #1-111080] INFO – : Completed 401 Unauthorized in 17ms (Views: 0.3ms | ActiveRecord: 5.5ms | Allocations: 2767)


The docker-compose.yml is mainly untouched:


version: ‘3’

services:

zammad-backup:
command: [“zammad-backup”]
depends_on:
- zammad-railsserver
- zammad-postgresql
entrypoint: /usr/local/bin/backup.sh
environment:
- BACKUP_SLEEP=86400
- HOLD_DAYS=10
- POSTGRESQL_USER=${POSTGRES_USER}
- POSTGRESQL_PASSWORD=${POSTGRES_PASS}
image: ${IMAGE_REPO}:zammad-postgresql${VERSION}
restart: ${RESTART}
volumes:
- zammad-backup:/var/tmp/zammad
- zammad-data:/opt/zammad

zammad-elasticsearch:
environment:
- discovery.type=single-node
image: ${IMAGE_REPO}:zammad-elasticsearch${VERSION}
restart: ${RESTART}
volumes:
- elasticsearch-data:/usr/share/elasticsearch/data

zammad-init:
command: [“zammad-init”]
depends_on:
- zammad-postgresql
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- POSTGRESQL_USER=${POSTGRES_USER}
- POSTGRESQL_PASS=${POSTGRES_PASS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:zammad${VERSION}
restart: on-failure
volumes:
- zammad-data:/opt/zammad

zammad-memcached:
command: memcached -m 256M
image: memcached:1.6.10-alpine
restart: ${RESTART}

zammad-nginx:
command: [“zammad-nginx”]
expose:
- “8080”
depends_on:
- zammad-railsserver
image: ${IMAGE_REPO}:zammad${VERSION}
restart: ${RESTART}
volumes:
- zammad-data:/opt/zammad

zammad-postgresql:
environment:
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASS}
image: ${IMAGE_REPO}:zammad-postgresql${VERSION}
restart: ${RESTART}
volumes:
- postgresql-data:/var/lib/postgresql/data
- zammad-data:/opt/zammad
- zammad-backup:/var/tmp/zammad:ro

zammad-railsserver:
command: [“zammad-railsserver”]
depends_on:
- zammad-memcached
- zammad-postgresql
- zammad-redis
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:zammad${VERSION}
restart: ${RESTART}
volumes:
- zammad-data:/opt/zammad

zammad-redis:
image: redis:6.2.5-alpine
restart: ${RESTART}

zammad-scheduler:
command: [“zammad-scheduler”]
depends_on:
- zammad-memcached
- zammad-railsserver
- zammad-redis
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:zammad${VERSION}
restart: ${RESTART}
volumes:
- zammad-data:/opt/zammad

zammad-websocket:
command: [“zammad-websocket”]
depends_on:
- zammad-memcached
- zammad-railsserver
- zammad-redis
environment:
- MEMCACHE_SERVERS=${MEMCACHE_SERVERS}
- REDIS_URL=${REDIS_URL}
image: ${IMAGE_REPO}:zammad${VERSION}
restart: ${RESTART}
volumes:
- zammad-data:/opt/zammad

volumes:
elasticsearch-data:
driver: local
postgresql-data:
driver: local
zammad-backup:
driver: local
zammad-data:
driver: local


My docker-compose.override.yml reads:


version: ‘3’

services:

zammad-backup:
networks:
- zammad_net

zammad-elasticsearch:
environment:
- “ES_JAVA_OPTS=-Xms4096m -Xmx4096m”
networks:
- zammad_net

zammad-init:
user: root
networks:
- zammad_net

zammad-memcached:
networks:
- zammad_net

zammad-postgresql:
volumes:
- zammad-data:/opt/zammad
- zammad-backup:/var/tmp/zammad:ro
networks:
- zammad_net

zammad-railsserver:
volumes:
- ./conf/proxy_params:/etc/nginx/proxy_params
- ./sites-available/default:/etc/nginx/sites-available/default ro
networks:
- zammad_net

zammad-redis:
networks:
- zammad_net

zammad-scheduler:
volumes:
- ./conf/proxy_params:/etc/nginx/proxy_params
- ./sites-available/default:/etc/nginx/sites-available/default ro
networks:
- zammad_net

zammad-websocket:
networks:
- zammad_net

zammad-nginx:
container_name: zammad-nginx
depends_on:
- zammad-websocket
volumes:
- ./conf/proxy_params:/etc/nginx/proxy_params
- ./sites-available/default:/etc/nginx/sites-available/default ro
- < Path to chained.crt>:/etc/ssl/certs//cert.crt
- /etc/ssl/private/private.key:/etc/ssl/private/key.key
labels:
- “traefik.enable=true”
- “traefik.docker.network=traefik_proxy”
- “traefik.http.routers.zammad-router.entrypoints=web”
- “traefik.http.routers.zammad-router-secure.tls=true”
- “traefik.http.routers.zammad-router.rule=Host(<FQDN>)”
- “traefik.http.routers.zammad-router.middlewares=log4shell-foo”
- “traefik.http.middlewares.log4shell-foo.plugin.log4shell.errorcode=200”
- “traefik.http.routers.zammad-router.middlewares=redirect-to-https”
- “traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https”
- “traefik.http.services.zammad.loadbalancer.server.port=8080”
- “traefik.http.routers.zammad-router-secure.entrypoints=websecure”
- “traefik.http.routers.zammad-router-secure.rule=Host(<FQDN>)”
- “traefik.http.routers.zammad-router-secure.middlewares=log4shell-foo”
networks:
- zammad_net
- traefik_proxy

networks:
zammad_net:
driver: bridge
traefik_proxy:
external: true

Steps to reproduce the behavior:

  • Fill the login form and press the “Login” button
1 Like

Short update: Yesterday the last remaining agent was also thrown out, so we don’t have access to the web interface anymore.

Any hint to track down the issue is gently appreciated. All hints ant tips to alike problems (e.g. clearing the browser cache, proxy_set_header X-Forwarded-Proto http) I found here are checked and don’t lead to resolving the issue.

You’re really using Zammad without https and https_type is configured to http as well?
If not above setting definitely is wrong.

Since traefik did the TLS-termination (traefik.http.routers.zammad-router-secure.tls=true), I don’t regard using plain http as a security issue because this all took place on a single (virtual) machine. Therefore all network traffic behind traefik was transferred only within the virtual network interfaces of docker, where I don’t mind whether or not the traffic is encrypted.

Where is the https_type configured?

Since our problem appeared on 21 September, we could not wait that long for a solution. Instead we gave up self hosting and transferred our configuration and database to zammad.com and let them host our ticket system which was up and running literally within a few hours.

Anyway, thanks for your reply.

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.