[Esapi-user] ESAPI.authenticator().login() semantics

Jeff Williams jeff.williams at aspectsecurity.com
Sat Dec 4 09:08:43 EST 2010


The user should get stored in the session.  Then login() should use that before attempting to authenticate with parameters.

--Jeff

On Dec 3, 2010, at 5:25 PM, "Kevin Chen" <kevin.chen at scynexis.com> wrote:

> I'm a new ESAPI user, and I have been using the SwingSet 1.0 (http://code.google.com/p/swingset-demo/) application to learn the API features and usage.
> 
>  
> 
> The lab on preventing cross-site request forgery has a JSP page (CSRFLab.jsp) where the user logs in using ESAPI.authenticator.login(request, response) and must be modified by the user to decorate a link on the page using ESAPI.httpUtilities().addCSRFToken(href).  This is straightforward enough.
> 
>  
> 
> The href in question links to a second JSP page where the task is to add code to validate the CSRF token that was appended.  The lab template code uses ESAPI.authenticator().getCurrentUser() to obtain a User object, and the intended solution is for the lab implementor to use user.getCSRFToken() to obtain the current user's token and compare it against the token value added to the page link (i.e. request.getParameter("ctoken")).
> 
>  
> 
> However, when I implement this solution (or even run the lab solution provided by SwingSet), the user object retrieved by the second page is not the User object stored in the HTTP session, but the Anonymous user.  This is presumably because the reference implementation of ESAPI.authentication.getCurrentUser() only sets the thread local value currentUser on a successful call to login() (in AbstractAuthenticator).  Since these are JSPs (and I am running in a Tomcat container), it is very likely that different page requests are serviced by different threads in the container, and therefore the current user will not be populated when the second request is processed.
> 
>  
> 
> I am attempting to determine whether this is a behavior specific to the reference implementation or the intended usage pattern for ESAPI.authenticator().login() -- that is, the no-argument version of login() should perform all of the logic to populate the current user object.  The problem I am encountering is that if the answer is the latter, there is a validation call in login() to ESAPI.httpUtilities().assertSecureRequest() which treats non-POST requests as invalid.  So if I want to use login() to populate the current user, I have to wrap all of my requests in HTML form submissions, which hardly seems like a reasonable requirement for the API user.
> 
>  
> 
> Is my interpretation of the API correct, or am I running into issues (or design bugs) specific to the reference implementation?  If login() is not the correct API to use, which one should I be using?
> 
>  
> 
> Any advice/assistance is appreciated,
> 
>  
> 
> Kevin.
> 
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20101204/20b672be/attachment.html 


More information about the Esapi-user mailing list