search

oroinc / platform

Main OroPlatform package with core functionality.
Other
627 stars 351 forks source link

[Security] CSRF Header not sent from jquery ajax due to invalid cookie name in https site. #1025

Closed mahmouds closed 3 years ago

mahmouds commented 4 years ago

Summary
When I use https with my site I face 403 status code for the following ajax request "/admin/sync/ticket". After debugging the issue I found out that the csrf header is not sent from my browser with any ajax request. The main cause is that the js code try to read a csrf token with the name "https-_csrf" https://github.com/oroinc/platform/blob/master/src/Oro/Bundle/UIBundle/Resources/public/js/extend/jquery.js#L18 and the server side code is returning a cookie with the name "_csrf" https://github.com/oroinc/platform/blob/master/src/Oro/Bundle/SecurityBundle/Csrf/CsrfRequestManager.php#L53

Expected Result
I think the "CsrfRequestManager" should have an implementation similar to this one https://github.com/oroinc/platform/blob/master/src/Oro/Bundle/ApiBundle/ApiDoc/SecurityContext.php#L159

Details about your environment

anyt commented 4 years ago

Hi @mahmouds,

Make sure you don't have mixed content on a page, and all the resources are served using HTTPS, including "admin/sync/ticket".

mahmouds commented 4 years ago

For any one facing this problem. We managed to fix this problem by overriding the current oro implementation. We re implemented the following 2 services in one of our bundles ("oro_security.event_listener.csrf_protection_request_listener", "app_security.csrf_request_manager"). We used the following function https://github.com/oroinc/platform/blob/master/src/Oro/Bundle/ApiBundle/ApiDoc/SecurityContext.php#L148 instead of the use of the constant "CSRF_TOKEN_ID".

anyt commented 4 years ago

After an investigation, we discovered this is a bug. Thank you for the report!

Internal ticket id #BAP-20029

anyt commented 3 years ago

Hi @mahmouds,

The team cannot reproduce the issue locally. Tried with a different configuration with no luck. The required "https_-csrf" cookie was always generated as expected. The issue might be related to the previous installation that worked without HTTPS on the same domain. In this case, clearing the browser cookie resolves it. Also, it might be related to the way HTTPS is configured on a web server side. For example, with nginx and HTTPS proxy, you will have a similar issue, if the virtual host doesn't have fastcgi_param HTTPS on; set. So the application doesn't know it's served over HTTPS. As for now, I'm closing the issue. Feel free to reopen it, in case you would be able to provide more details on how to reproduce it locally.

mahmouds commented 3 years ago

Dear @anyt As I mentioned my previous comment. I already implemented a work around for this bug.

As for the reproduce steps.

Please open the following line https://github.com/oroinc/platform/blob/master/src/Oro/Bundle/ApiBundle/ApiDoc/SecurityContext.php#L159 and compare it with the following line https://github.com/oroinc/platform/blob/master/src/Oro/Bundle/SecurityBundle/Csrf/CsrfRequestManager.php#L53

If you need more steps please tell me.

anyt commented 3 years ago

By steps to reproduce, I mean the list of actions we have to do to see the issue. It might involve code customizations or specific web server configuration. Comparing the above code doesn't make us understand the issue, as you refer to two different things. In the first place, we read the cookie by name in the request. In the second case, we refresh the token by id in token storage. There is no direct relation between their names.

mahmouds commented 3 years ago

Do any steps that require refreshing the https csrf cookie