Container-managed auth security issue?

[Dave Koelmeyer <da...@davekoelmeyer.co.nz>]

Hi All,

I've stumbled across some rather interesting behaviour which I'd like to
know if someone else can replicate, and, if this is expected with my setup.

I'm running JSPWiki v2.10.2-svn-38 with container-managed
authentication, with user accounts provisioned using a file-based
security realm in Payara Server 4.1. My JSPWiki policy file has been
deliberately locked down such that only authenticated users can view
content.

The userdatabase.xml file contains the following only, as one would expect:

<?xml version="1.0" encoding="UTF-8"?>
<users>
    <user uid="625526c4-blahblahblah" loginName="admin"
wikiName="Administrator" fullName="Administrator" email=""
password="{SSHA}somepassword" created="2016.02.20 at 23:11:59:610 NZDT"
lastModified="2016.02.20 at 23:11:59:610 NZDT" lockExpiry="" >
    </user>
</users>

To test the installation is secure a user performs the following:

 1. Navigate to the JSPWiki login screen
 2. Click on ["Don't have account?"] "Join JSPWiki now!
 3. On the "Register a new user!" page, enter a random Name and email
    address, and click "Create a new user profile". The account cannot
    be created.


Now, leaving this browser tab as-is, open a second browser tab.
Authenticate to JSPWiki as an authorised user. Next, switch back to the
original tab. Repeat step 3 above. The session logs you in. Under "User
Preferences -> Profile" for the logged-in user, the "Name" and "Email
address" values have changed to what was set in step 3 above. The "Login
name" however is still the account derived from the Payara security realm.

Now, if one inspects the userdatabase.xml file, a new entry *has* been
created. In the following example "derekz" is set in the file-based
security realm, whereas "Alex" is the name set when registering the new
user account directly:

 <user uid="b561f8e2-blahblahblah" loginName="derekz" wikiName="Alex"
fullName="Alex" email="alex@example.com" password="" created="2016.02.2
0 at 23:28:59:268 NZDT" lastModified="2016.02.20 at 23:28:59:268 NZDT"
lockExpiry="" >
    </user>
</users>

So what gives? Something tells me this perhaps shouldn't be working
quite like this, even with the unlikely scenario of attempting to
register a new user when the same authorised user is already authenticated.

Cheers,
Dave

-- 
Dave Koelmeyer
http://blog.davekoelmeyer.co.nz
GPG Key ID: 0x238BFF87

Re: Container-managed auth security issue?

[Paul Uszak <pa...@gmail.com>]

I get similarly weird behaviour but not exactly identical.  My strangest
effects are that I can't log out. If I log out, then just browse back I'm
logged back in. I also can't log in cleanly as I always get the "you can't
do that" page, but then I'm logged in. I can't get to the JSPWiki log in
page at all, just the realm basic dialogue.  If I ever try to cancel a
login dialogue I just get a Server 500 error that never goes away until I
close the browser.

I think that Access Control List x JSPWiki security x Container security x
individual JSP page granularity is just too complicated, both to manage or
debug.  There probably aren't enough deployments to identify /document
/debug all possible use cases. I'm not sure what the answer might be other
than an authorisation mechanism rethink.  I suspect that the ratio of
installations to security complexity is such that most people have some
sort of problem.

Prayer: Please God, don't add MySql support as that will just make it a
total nightmare with it's dumb ass port /socket & location based
authorisation model on top of the wiki's.


On Saturday, 20 February 2016, Dave Koelmeyer <
dave.koelmeyer@davekoelmeyer.co.nz> wrote:

> Hi All,
>
> I've stumbled across some rather interesting behaviour which I'd like to
> know if someone else can replicate, and, if this is expected with my setup.
>
> I'm running JSPWiki v2.10.2-svn-38 with container-managed
> authentication, with user accounts provisioned using a file-based
> security realm in Payara Server 4.1. My JSPWiki policy file has been
> deliberately locked down such that only authenticated users can view
> content.
>
> The userdatabase.xml file contains the following only, as one would expect:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <users>
>     <user uid="625526c4-blahblahblah" loginName="admin"
> wikiName="Administrator" fullName="Administrator" email=""
> password="{SSHA}somepassword" created="2016.02.20 at 23:11:59:610 NZDT"
> lastModified="2016.02.20 at 23:11:59:610 NZDT" lockExpiry="" >
>     </user>
> </users>
>
> To test the installation is secure a user performs the following:
>
>  1. Navigate to the JSPWiki login screen
>  2. Click on ["Don't have account?"] "Join JSPWiki now!
>  3. On the "Register a new user!" page, enter a random Name and email
>     address, and click "Create a new user profile". The account cannot
>     be created.
>
>
> Now, leaving this browser tab as-is, open a second browser tab.
> Authenticate to JSPWiki as an authorised user. Next, switch back to the
> original tab. Repeat step 3 above. The session logs you in. Under "User
> Preferences -> Profile" for the logged-in user, the "Name" and "Email
> address" values have changed to what was set in step 3 above. The "Login
> name" however is still the account derived from the Payara security realm.
>
> Now, if one inspects the userdatabase.xml file, a new entry *has* been
> created. In the following example "derekz" is set in the file-based
> security realm, whereas "Alex" is the name set when registering the new
> user account directly:
>
>  <user uid="b561f8e2-blahblahblah" loginName="derekz" wikiName="Alex"
> fullName="Alex" email="alex@example.com <javascript:;>" password=""
> created="2016.02.2
> 0 at 23:28:59:268 NZDT" lastModified="2016.02.20 at 23:28:59:268 NZDT"
> lockExpiry="" >
>     </user>
> </users>
>
> So what gives? Something tells me this perhaps shouldn't be working
> quite like this, even with the unlikely scenario of attempting to
> register a new user when the same authorised user is already authenticated.
>
> Cheers,
> Dave
>
> --
> Dave Koelmeyer
> http://blog.davekoelmeyer.co.nz
> GPG Key ID: 0x238BFF87
>
>