esapi-java-legacy icon indicating copy to clipboard operation
esapi-java-legacy copied to clipboard

ESAPI Authenticator component needs documented (was "User session just jumped from unknown to 0:0:0:0:0:0:0:1")

Open meg23 opened this issue 10 years ago • 7 comments

From [email protected] on October 08, 2014 05:33:32

What steps will reproduce the problem? 1. Trying to validate the login of Authenticator class. What is the expected output? What do you see instead? It should login but getting User session just jumped from unknown to 0:0:0:0:0:0:0:1 What version of the product are you using? On what operating system? windows XP Does this issue affect only a specified browser or set of browsers? No. it is coming on every browser Please provide any additional information below. Attached file are the refrence.

Attachment: HTTPAuthenticationTest.java

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=337

meg23 avatar Nov 13 '14 18:11 meg23

From [email protected] on October 08, 2014 02:47:01

Version of library : 2.0.1

meg23 avatar Nov 13 '14 18:11 meg23

Took a little time to fully reproduce this test.

First you need to create a user using the FileBasedAuthenticator, in this case, "sunil" with password "ZeBk.936" I used a "role" of "admin" just to make something up. After also adding the following entry to esapi's pom.xml (in my dev env)

        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-all</artifactId>
            <version>1.10.19</version>
        </dependency>

I was able to get the following output:

WARNING: [SECURITY FAILURE sunil:85999@unknown -> /IntrusionDetector] User session just jumped from unknown to null
org.owasp.esapi.errors.AuthenticationHostException: Host change
    at org.owasp.esapi.reference.DefaultUser.setLastHostAddress(DefaultUser.java:525)
    at org.owasp.esapi.reference.DefaultUser.loginWithPassword(DefaultUser.java:422)
    at org.owasp.esapi.reference.AbstractAuthenticator.loginWithUsernameAndPassword(AbstractAuthenticator.java:178)
    at org.owasp.esapi.reference.AbstractAuthenticator.login(AbstractAuthenticator.java:210)
    at org.owasp.esapi.reference.AbstractAuthenticator.login(AbstractAuthenticator.java:188)
    at com.securtity.test.HTTPAuthenticationTest.main(HTTPAuthenticationTest.java:41)

User session just jumped from unknown to null
org.owasp.esapi.errors.AuthenticationHostException: Host change
    at org.owasp.esapi.reference.DefaultUser.setLastHostAddress(DefaultUser.java:525)
    at org.owasp.esapi.reference.DefaultUser.loginWithPassword(DefaultUser.java:422)
    at org.owasp.esapi.reference.AbstractAuthenticator.loginWithUsernameAndPassword(AbstractAuthenticator.java:178)
    at org.owasp.esapi.reference.AbstractAuthenticator.login(AbstractAuthenticator.java:210)
    at org.owasp.esapi.reference.AbstractAuthenticator.login(AbstractAuthenticator.java:188)
    at com.securtity.test.HTTPAuthenticationTest.main(HTTPAuthenticationTest.java:41)

Investigating as to the cause of the issue now.

xeno6696 avatar Dec 24 '15 14:12 xeno6696

Note: AbstractAuthenticator.java line 90, we're returning a user that has no sessions listed in its corresponding hashset. (Not sure if this means anything yet... just leaving a breadcrumb.)

xeno6696 avatar Dec 24 '15 15:12 xeno6696

So it appears here that the last known host address here starts out as "unknown," which isn't rediculous because the user was just created via the default FileBasedAuthenticatorTool, and not via an application that is functioning in a full web environment.

In the enclosed test case, the contributing programmer never sets up a mock call to return "unknown" from the train call ESAPI.httpUtilities().getCurrentRequest().getRemoteAddr(), which since the test case mocks the HttpServletRequest, we would expect.

This is not a bug, this is an implementation problem, as in a live system, the implementor of the authentication system would be require to set up their own default values for new users. This issue should be closed as working as intended.

xeno6696 avatar Dec 24 '15 16:12 xeno6696

@kwwall -- Recommend closing this one too. This is a quirk in the initial deployment of file-based authentication, and can be fixed simply by updating the host field in the users.txt file with the correct host value, or in setting up a different default. There are no problems here.

xeno6696 avatar Jan 16 '16 15:01 xeno6696

@xeno6696 I'm not going to close this (even though I agree with your analysis that it not a bug). Instead I've removed the 'bug' label and changed it it to 'enhancement' and added 'Component-Docs' and 'Component-Authenticator' because I think the real issue is is that this has not be clearly documented in terms of a user guide. (You noted yourself that it took time to reproduce this because you had to figure out what to do in regards to adding user, etc.).

The much bigger problem here IMO is that FileBasedAuthenticator is really just a "toy" reference implementation and I don't think that any of us working on ESAPI expected it to be used for real work. Rather it was more intended as a outline to illustrate what you would have to do to implement your own ESAPI Authenticator. At one point, I had discussed with a few people the idea of at least dropping in an LDAPAuthenticator, but to make that function it would require more properties which I didn't really want to add at the time. (I did have a JNDI-based LDAP authentication class that could be easily implement the ESAPI Authenticator interface and since it was JNDI based, it would add no additional dependencies to ESAPI.)

Anyway, I'm leaving this open, but changing it to a documentation enhancement request for the Authenticator component. (Any takers? If so, contact me.)

kwwall avatar Jan 16 '16 19:01 kwwall

Changed title to more be in line with the real issue.

kwwall avatar Jan 16 '16 19:01 kwwall