You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Jacques Le Roux (JIRA)" <ji...@apache.org> on 2018/03/21 13:41:00 UTC

[jira] [Comment Edited] (OFBIZ-10206) Security issue in Token Based Authentication

    [ https://issues.apache.org/jira/browse/OFBIZ-10206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16355499#comment-16355499 ] 

Jacques Le Roux edited comment on OFBIZ-10206 at 3/21/18 1:40 PM:
------------------------------------------------------------------

I completed in

trunk r1823467

R17.12 r1823469

 


was (Author: jacques.le.roux):
I completed in

trunk r1823467

R17.12 r1823469

I updated the security.properties content related to JWT
 Refers to the last up to date external-server-test-example.patch at OFBIZ-10206
 Makes demo-trunk.ofbiz.apache.org default external-server-name so that anybody
 can try the feature from own machine. The use-external-server=Y was already set

> Security issue in Token Based Authentication
> --------------------------------------------
>
>                 Key: OFBIZ-10206
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-10206
>             Project: OFBiz
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: 17.12.01
>            Reporter: Jacques Le Roux
>            Assignee: Jacques Le Roux
>            Priority: Major
>
> The version I commited so far in OFBIZ-9833 has a small security issue.
> I added the JWT (JSON Web Token [https://fr.wikipedia.org/wiki/JSON_Web_Token]), which guarantees an exchange between 2 servers. But the way I used it did not prevent from changing the parameter externalServerLoginKey in the URL. Note that this is only possible from the server where the JWT was sent from. This is still a risk (minor) if an unauthorized and malicious person managed to gain access to the backend of the source server.
> The flaw is that I was using a query parameter in the ContextFilter. doFilter () wrapper where the JWT is created.
> I just replaced it with an autoLoginCookie reading on the source server. I would have preferred to use the session, but when creating the JWT, the session contains neither userLogin nor userLoginId. I also need the source server webapp to read the autoLoginCookie. The webapp must therefore be passed as a new parameter in the query. On the target server I use a userLoginId reading from the JWT and no longer from the request, that was the goal I missed!
> I have secured all cookies with OFBIZ-6655, so an autoLoginCookie can only be created or updated when creating the session on the source server. However, autoLoginCookies have a lifetime of one year and are not deleted during a logout. So an autoLoginCookie of another webapp (webapp passed in parameter thus modifiable in the URL) could in theory be used to force another loginUser contained in the autoLoginCookie of this other webapp.
> I think that this lifespan may make sense for frontends (ecommerce, ecomseo, webpos), which have their own logout and where I suppose this feature (from ecommerce in fact) comes to keep a customer's memory. For the backend I don't see the interest also I propose to delete autoLoginCookies to the logout on backend. For that I'll reopen and use OFBIZ-4959 that I closed as incomplete.
> I will commit an improved version in the trunk that I have tested locally with 2 different webapps but still have to test on 2 servers. I'm going to do it using the trunk demo from my machine.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)