Ory is the largest open source community in the world for cloud software application security. We maintain advanced open source security software solving authentication, authorization, access control, application network security, and delegation. Ory implements a variety of industry and best-practice standards including OAuth 2.0 / OAuth 2.1, OpenID Connect, Zero Trust Networking, Google Zanzibar Policy Framework, FIDO2 U2F, WebAuthn, TOTP, and more.

Ory Community

<@U011D3UQKNY> Hi. Thanks for creating channel. Any reason behind channel name `crsf` and not `csrf`? Are they both same?

Ah thanks for letting me know, it was just a mistake :sweat_smile:

And so you found the most common cause of bugs :D

Great that there's a channel specifically for this :smile:  We're having CSRF issues and hit a wall with our troubleshooting.. We've followed every guide (including those pinned to this thread)

When authenticating, we're getting stuck in a redirect loop between `/login?flow=X` (302) and `/self-service/login/browser`  (303)

Kratos has the error of;
```An error occurred while handling a request audience=application error=map[debug: details:map[docs:<https://www.ory.sh/kratos/docs/debug/csrf> hint:The anti-CSRF cookie was found but the CSRF token was not included in the HTTP request body (csrf_token) nor in the HTTP Header (X-CSRF-Token). reject_reason:The HTTP Cookie Header was set and a CSRF token was sent but they do not match. We recommend deleting all cookies for this domain and retrying the flow.] message:the request was rejected to protect you from Cross-Site-Request-Forgery reason:Please retry the flow and optionally clear your cookies. The request was rejected to protect you from Cross-Site-Request-Forgery (CSRF) which could cause account takeover, leaking personal information, and other serious security issues.```
The cookie header does get passed in `kratos.getSelfServiceLoginFlow(flow, req.header('cookie'))`

We also have set the appropriate config
```session:
  cookie:
    domain: <http://myproduct.com|myproduct.com>```
Our setup does use subdomains, to rule that out I replaced all that to put everything under one subdomain with unique paths (`<http://domain.com/dashboard|domain.com/dashboard>` `<http://domain.com/kratos|domain.com/kratos>` etc)

Our auth code isn't to dissimilar (and mostly copied to get something working) from <https://github.com/ory/kratos-selfservice-ui-node>

Any pointers on what else we can look at to help troubleshooting? <@U011D3UQKNY>

<@U02U9MSKL9X> <@U011D3UQKNY> Are either of you happy if I book in a 1on1 session to go through the above? We've just had three of us troubleshooting this all morning and can't understand why we're hitting it when we (believe) we've done everything that the docs is telling us

Hello. Do you have any demo accessible via public internet?

I would be best for me to prepare before our 1on1

Feel free to book <https://meetings-eu1.hubspot.com/andrew-minkin|one>

The endpoints are public, happy to share them.  I can put together a gist with all the configs etc too prior to meeting too

For context, locally for testing, we were using this setup - <https://github.com/chandanjog/ory-suite-spike/tree/hydra-integration-2021/contrib/hydra> which has some changes on top of  `hydra-integration-2021` branch for  `kratos-selfservice-ui-node` repository. We ran Kratos in --dev mode on it and now are testing in a K8 based prod like env and are coming across the CSRF errors.

I've just put the gist together for you <@U02U9MSKL9X> I'll PM it over and get a call in the diary - thanks for assisting!

Hi <@U038JEM003C>

I would need some extra information to know how you are calling Kratos and what is being sent in the browser.
Some pointers to take into consideration:

• Are you sure that the kratos csrf cookie is included in that request? The csrf cookie should be used when making the final flow call to kratos, e.g. post login or post registration. Make sure you are doing this by configuring the sdk to do `withCredentials: true`
```export default new V0alpha2Api(new Configuration({
  baseOptions: {
    withCredentials: true,
  }
}))```
• If you are behind a reverse proxy, are you allowing the cookie headers? `Authorization` headers?
• Sub domains and same domains should't be a problem if your `session.cookie.domain` is set to the TLD
Also note, there are two places to set the cookie value `cookies` and `session`

```## HTTP Cookie Configuration ##
#
# Configure the HTTP Cookies. Applies to both CSRF and session cookies.
#
cookies:
  
  ## HTTP  Cookie Path ##
  #
  # Sets the session and CSRF cookie path. Use with care!
  #
  # Default value: /
  #
  # Set this value using environment variables on
  # - Linux/macOS:
  #    $ export COOKIES_PATH=&lt;value&gt;
  # - Windows Command Line (CMD):
  #    &gt; set COOKIES_PATH=&lt;value&gt;
  #
  path: ""

  ## HTTP Cookie Same Site Configuration ##
  #
  # Sets the session and CSRF cookie SameSite.
  #
  # Default value: Lax
  #
  # One of:
  # - Strict
  # - Lax
  # - None
  # 
  # Set this value using environment variables on
  # - Linux/macOS:
  #    $ export COOKIES_SAME_SITE=&lt;value&gt;
  # - Windows Command Line (CMD):
  #    &gt; set COOKIES_SAME_SITE=&lt;value&gt;
  #
  same_site: Strict

  ## HTTP Cookie Domain ##
  #
  # Sets the cookie domain for session and CSRF cookies. Useful when dealing with subdomains. Use with care!
  #
  # Set this value using environment variables on
  # - Linux/macOS:
  #    $ export COOKIES_DOMAIN=&lt;value&gt;
  # - Windows Command Line (CMD):
  #    &gt; set COOKIES_DOMAIN=&lt;value&gt;
  #
  domain: ""

## session ##
#
session:
  
  ## Session Lifespan ##
  #
  # Defines how long a session is active. Once that lifespan has been reached, the user needs to sign in again.
  #
  # Default value: 24h
  #
  # Examples:
  # - 1h
  # - 1m
  # - 1s
  # 
  # Set this value using environment variables on
  # - Linux/macOS:
  #    $ export SESSION_LIFESPAN=&lt;value&gt;
  # - Windows Command Line (CMD):
  #    &gt; set SESSION_LIFESPAN=&lt;value&gt;
  #
  lifespan: 1h

  ## cookie ##
  #
  cookie:
    
    ## Session Cookie Name ##
    #
    # Sets the session cookie name. Use with care!
    #
    # Default value: ory_kratos_session
    #
    # Set this value using environment variables on
    # - Linux/macOS:
    #    $ export SESSION_COOKIE_NAME=&lt;value&gt;
    # - Windows Command Line (CMD):
    #    &gt; set SESSION_COOKIE_NAME=&lt;value&gt;
    #
    name: ""

    ## Make Session Cookie Persistent ##
    #
    # If set to true will persist the cookie in the end-user's browser using the `max-age` parameter which is set to the `session.lifespan` value. Persistent cookies are not deleted when the browser is closed (e.g. on reboot or alt+f4).
    #
    # Default value: true
    #
    # Set this value using environment variables on
    # - Linux/macOS:
    #    $ export SESSION_COOKIE_PERSISTENT=&lt;value&gt;
    # - Windows Command Line (CMD):
    #    &gt; set SESSION_COOKIE_PERSISTENT=&lt;value&gt;
    #
    persistent: false

    ## Session Cookie Path ##
    #
    # Sets the session cookie path. Use with care! Overrides `cookies.path`.
    #
    # Set this value using environment variables on
    # - Linux/macOS:
    #    $ export SESSION_COOKIE_PATH=&lt;value&gt;
    # - Windows Command Line (CMD):
    #    &gt; set SESSION_COOKIE_PATH=&lt;value&gt;
    #
    path: ""

    ## Session Cookie SameSite Configuration ##
    #
    # Sets the session cookie SameSite. Overrides `cookies.same_site`.
    #
    # One of:
    # - Strict
    # - Lax
    # - None
    # 
    # Set this value using environment variables on
    # - Linux/macOS:
    #    $ export SESSION_COOKIE_SAME_SITE=&lt;value&gt;
    # - Windows Command Line (CMD):
    #    &gt; set SESSION_COOKIE_SAME_SITE=&lt;value&gt;
    #
    same_site: Strict

    ## Session Cookie Domain ##
    #
    # Sets the session cookie domain. Useful when dealing with subdomains. Use with care! Overrides `cookies.domain`.
    #
    # Set this value using environment variables on
    # - Linux/macOS:
    #    $ export SESSION_COOKIE_DOMAIN=&lt;value&gt;
    # - Windows Command Line (CMD):
    #    &gt; set SESSION_COOKIE_DOMAIN=&lt;value&gt;
    #
    domain: ""```

Could you maybe share your browser requests? you can omit the domain details.
things to look out for is which cookies are included in the request

Screenshot 2022-05-16 at 15.39.03.png

Thanks <@U01MTU9E4CF> I've relayed the first comment to our frontend engineer to confirm.

&gt; •  If you are behind a reverse proxy, are you allowing the cookie headers? `Authorization` headers?
This is all fine as with have authorization working elsewhere
&gt; • Sub domains and same domains should't be a problem if your `session.cookie.domain` is set to the TLD
Cookies have been set for both places in the config already for these too.

First attached image is the browser requests, which you can see the redirect loop.
The 3rd request to `/self-service/login/browser` does contain the `set-cookie` for the `csrf_token` which is peristed through the rest of the requests;

```set-cookie: csrf_token_9469ea931bf0c60f31f5aacc7a8c37b9a87ca5f59b8b8d01743263aa8da4895c=Jrk1qLDjiWAXIOv4kcxQla04aIAwHxjbj7AzhnK7O3U=; Path=/; Domain=&lt;snip&gt;; Max-Age=31536000; HttpOnly; Secure; SameSite=Lax```

what is the form payload? are you including the csrf token there as well?
when you do the form post you need an input field with the csrf token included there as well

```&lt;input name="csrf_token" type="hidden" value="caj8Ws+5rPFgVd0gZ2hANG5IvI2VAc/orRcOchUW+fBLEAbE2jBusSIBe5fZ0t1S7EyB2O/cPBKGQbicK+UC7Q=="&gt;```

the token changes per flow, so you need to retrieve it when you make the initial request to kratos through the flow id

Hi there! We are experiencing an issue with CSRF after logout. The CSRF cookie is updated and is the only cookie that stays after logging out (which is expected I believe). However, any request after logout that doesn't require auth sends the CSRF cookie and returns a 401. When manually deleting the CSRF cookie, non-auth requests work as intended.

We use this configuration:
```Configuration({
  baseOptions: {
    withCredentials: true,
  }
}))```
And this is our logout call to Kratos:
```new V0alpha2Api(...).submitSelfServiceLogoutFlowWithoutBrowser({ session_token: session ? session.session_token : '' }))```
We are using NextJS. Do you have any idea what could be the problem? Thank you!

Hi <@U011D3UQKNY> <@U01MTU9E4CF> <@U02U9MSKL9X> could you have a look? I was thinking this might be a problem with Ory. Thank you :thumbsup:

Hello <@U0419KMJBGX>
apologies for the late answer…

I am not sure what is the problem here…
Can you share a bit more on your deployment? Are you using Ory Cloud or selfhosting Ory Kratos? Can you share a repo that is reproducible?

Hm actually I am not sure if the CSRF cookie should stay after logging out. Have to dig a bit in the docs. Feel free to ping me if I dont follow up by tomorrow…

Hi Vincent, we are using Ory cloud and right now I don't have a repo to share, but we were wondering exactly that - if the CSRF cookie should stay after logout. I will send you a DM if I have any other input, and am looking forward to your finding regarding the CSRF after logout

Hey Joao,
so the CRSF cookie should stay after logout.
It seems you are using the API for non-browsers in a browser environment.
<https://www.ory.sh/docs/reference/api#operation/createSelfServiceLogoutFlowUrlForBrowsers>
so use submitSelfServiceLogoutFlow
instead of submitSelfServiceLogoutFlowWithoutBrowser

Let me know if that helps :slightly_smiling_face:

Thank you Vincent :slightly_smiling_face:

So we have tested it out with `submitSelfServiceLogoutFlow` and still we are experiencing a 401 whenever we have a `csrf` cookie while logged out... We have a few APIs that don't require auth, and if we call those APIs and have the csrf token, it returns a 401.

The same happens if the user initializes a login flow `initializeSelfServiceLoginFlowForBrowsers` but doesn't login, and just goes to another page that uses an open API, it also returns a 401 due to the csrf token that is present. It seems as though Ory expects that the user is signed in when we call any API with the csrf cookie in the header...

We are checking our oauthkeeper configuration and maybe you can hold on on researching until we are sure it isn't our problem. I let you know if anything and thanks for the help :thumbsup:

Ok feel free to remind me or open a github discussion when you did find out.