SEP24: interactive iframe causes problems with sessions and CSRF tokens

[yuriescl]

When the Wallet receives 403 interactive_customer_info_needed from POST /transactions/deposit/interactive, it's supposed to open a popup or iframe pointing to the Anchor interactive deposit url.
The Anchor interactive deposit might be composed of forms and make use of web sessions.
Modern browsers and web frameworks usually enforce strong protection against the use of third-party and cross-origin cookies and CSRF tokens, this causes forms and sessions to not work properly on iframes, since the cookies they use are considered to be third-party when running inside an iframe.
In Django, the SESSION_COOKIE_SAMESITE setting is a workaround to make the sessions work but CSRF tokens still causes forms to not work properly.
Credits to @msfeldstein for finding about iframe third-party cookies and the Django SESSION_COOKIE_SAMESITE setting.

[leighmcculloch]

@msfeldstein I think we should be encouraging wallets that are apps to open the interactive links in either the system browser, or in a popup that is provided by the system as is essentially a full browser, and wallets that are web browsers to open the interactive links in a new window. That should help resolve issues with websites needing to figure out how to set these things and then we're also encouraging best practices where users only enter in bank account details and personal details into websites when they can see the URL. I think we should remove the mention of iframe here.

Are we encouraging iframes in an attempt to improve UX? I think the UX value actually delivered is relatively low.

[msfeldstein]

Yeah iframes/webviews are mentioned because we assumed that's the UX almost all wallets would want.

[msfeldstein]

@yuriescl we were able to get django sessions working with the samesite flag, but there is a django but we had to work around to make it happen.
Here is a django PR that should make this all a moot point: django/django#11894
Here is our PR to make it work in polaris: stellar/django-polaris#43

Can you clarify what specifically is being blocked in regards to the CSRF? afaik a CSRF is simply a hidden form field injected by the server, not something that is handled in any special way in the browser

[yuriescl]

@msfeldstein Thanks. I was able to get the form to be displayed by applying the Polaris Middleware to my Django app. But the CSRF problem is still there and it happens when using the Connector Demo iframe, I imagine it's because the Connector Demo is not using HTTPS so Django is not accepting the CSRF token (session works though). Do I need to apply that Django patch to work around this HTTPS problem?

[msfeldstein]

Does it work if you use https on the Connector Demo?

[yuriescl]

@msfeldstein No, using HTTPS does not fix the issue. The CSRF token is sent in the POST data but the web server still returns the same error:

Forbidden (403)

CSRF verification failed. Request aborted.
You are seeing this message because this site requires a CSRF cookie when submitting forms. This cookie is required for security reasons, to ensure that your browser is not being hijacked by third parties.
If you have configured your browser to disable cookies, please re-enable them, at least for this site, or for 'same-origin' requests.

Django error:

Forbidden (CSRF cookie not set.)

[msfeldstein]

What browser are you using?
I get a warning in chrome, but it still works. It sounds like it will be disabled soon and is probably what you're running into. I can try to fix the warning and we'll see if it fixes it for you.

A cookie associated with a resource at http://stellar-anchor-server.herokuapp.com/ was set with `SameSite=None` but without `Secure`. A future release of Chrome will only deliver cookies marked `SameSite=None` if they are also marked `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5633521622188032.

[yuriescl]

@msfeldstein I'm using Firefox in a Private Window without Tracking Protection and I don't see any warning in the console.

[yuriescl]

@msfeldstein Do you think it's a good idea to disable CSRF protection for the iframe forms? At least until we figure out a better solution.

[msfeldstein]

Yes i think that makes sense. I've got a new task out to support popups instead of iframes in the demo client. This won't be an issue on mobile apps, and we can revise the guidance for web wallets to use OAuth style popups. This should already be supported by the SEP, we just haven't exercised it so this task should help verify it
stellar-deprecated/sep24-demo-client#147

[msfeldstein]

I think this works for everyone now. Web based wallets can use the popups as demonstrated by the demo client, native wallets can still embed however they like.