ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OFBIZ-10206) Security issue in Token Based Authentication
Date Wed, 07 Feb 2018 14:22:00 GMT

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

Jacques Le Roux commented on OFBIZ-10206:
-----------------------------------------

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
>         Attachments: OFBIZ-10206-external-server-test-example.patch
>
>
> 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)

Mime
View raw message