Joomla! Discussion Forums

Awesome you're looking to this!

Any change we'll also see back some of the other suggestions posted here?

I've been testing the AOL variant of this hack now for two days and I've had no problems.

I've experienced nothing but the added benefit of slight pageload speed improvement.  Oh and my mos_session table entries are consistently about 1/3rd of what they used to be, thus my "who's online" module is reflecting a more accurate number of guests.

I'm sticking with this hack unless something goes wrong (in which case, I'll report back my results in this forum).

-Tyler

Thanks Tyler!

GRAM

Diff file for unified solution (AOL/Proxy fix is option that can be enabled) is attached. 

I created the last one incorrectly.

GRAM

Thanks, this I can follow easier.

New unified verion of this hack (attached to first post of this thread) now looks for a POST variable called 'force_session'.  If it finds it, it will proceed with session setup.  New version does not check the value of this variable, only tests (isset()) to see if it is there.

External login forms that include this variable will now properly log users in, and they won't get the 'cookies required' message.

Thanks for the suggestion Hackwar!

GRAM

I'll be testing this hack out as well--THANKS! Until now, just had to tell people it was their fault for using AOL. 

@lpkb,

Please keep us posted with how it goes.

Thanks,

GRAM

I've implemented "original Gram AOL hack" sounds nice  and my guests number dropped about 2/3 (visitor count is much more accurate right now I think).



I would adjust Step (3) in a way that new session_id hash would be based on IP+rand+time+previous_session_id somehow, and implement mechanism/function to allow recreation of past few session_ids, that way if users arrives with old(er) session_id because of TCP problems, Joomla can still authenticate. Is that even possible and feasible?

Or may be simply remember past 5 session_ids and their expiration time in database?

Thanks Peter! 

I appreciate you reporting your results.



It kind of defeats the rolling mechanism, by allowing a previous session to authenticate.  But would be do-able.  The less previous sessions allowed, the stronger it becomes....

It also requires a QUERY - Compare, where we now just have a query, so if used, would need to be subsequent to a failed initial query (looking for current session id).

However, this could be done by adding one field to the database, and converting the query to a query compare.  If a sessionid remained constant, and we added an auth_id field, we could serialize an array of acceptable auth_id's, in order of use, to be compared against.  On success, we pop the array to roll one off, add the new one and proceed with update.

This could actually provide a mechanism for deploying a rolling session value without verifying that the client had recieved an updated auth_id from the last page request (for TCP failure).  By keeping the last assigned auth_id and the auth_id it replaced, we could confirm the client was in posession of one of the last two assigned auth_id's , roll the values and save.  Client could authenticate with either of the last two assigned auth_ids, which would constantly roll with the page requests.

We are already doing an update, so only added overhead is the compare, and pop and replace.

GRAM

Wow, long reading so far. I just realized this thread... Gram, haven't looked at your patch yet, will do so later. Thanks for taking over this problem anyway.



Thanks also for this good explanation on the problem of rolling session IDs. I like Prutkar's suggestion of allowing a few (as few as possible, so maybe only one) old session id's in addition to the most current one.



In addition to this, here's my proposal on how to get some feedback that an user has received the new session id. As almost every template is using  a CSS-file or at least an image, wouldn't it be possible to have an php-file that

• returns the css-file or image with apropriate headers (Mime-type...),
• sends out headers that this file may never be cached,
• and finally takes a look at the session id it gets send back by the user. If this is the new session id, the old one could be deleted out of the array of previos session ids.

I know, the drawback of this method would be some even higher page traffic. On the other hand, you could also use the php-script to send back the favicon which is fairly small. As the favicon is included in the html-headers (and this one gets created in the core, mosShowHead()), this should be fairly easy to implement without having to change all templates.

I hope I could make myself clear. Please let me know what you think about this idea.

Another two cents on this:
What about having another variable than $mosConfig_fix_proxy? On that could take a "subnet" mask that gets applied with "logical and" to the visitors IP? Thus, every admin could decide for him-/herself how important security is for them. One would use a subnet of "255.255.255.0" for the AOL hack, "255.255.255.255" for no IP jumping at all, or "0.0.0.0" for those who don't need security at all or want to allow AOL users with jumping class A proxies.

I really like this idea.  We could send a request to a session validator (as you outlined), session validator would always return the favicon (in spite of how it may have been called).

I don't know the answer to this, but do all browsers respect and load the favicon?  For example, would a reader respect it?  Thinking only of accessibility, not the search engines.

GRAM

Oops, good point. Just tested with lynx, on my site it does not load the favicon (not showing up in logfiles). (Why should it, lynx can't display it anyway ;-)

That's exactly what I said a couple of posts earlier... I think it would be a good thing

Btw, I'm still folowing the discussion closely, but not posting atm. I'm overthinking things at the moment and working on a security document for Joomla where I want to point this out (as possible suggestions for the core team).

Hm, looks like I didn't read the thread carefully enough, although I thought I did so... 

Stay in here friesengeist 

The rest of has have the the luxery of reading this thread as each post was put up.

You had a good suggestion.

GRAM

Ah well, it is a good suggestion you made there and this confirms more people are thinking this way!

Great effort!
I actually read the whole thing! Now I'm off to implement it on my site. I had wondered why my counts had been inflated so much. What actually worries me is that I think I understood this thread. Without your efforts I would have had no clue how to do it. I had wondered about the clear text password issue myself. A number of more secure sites use https for login authentication and then drop to http for the rest of the session. I guess that is beyond joomla since it would require secure server for every site.

W

Any word on when 1.0.8 will be out with these changes? or would it be best to wait for 1.1?

I don't think 1.0.8 will have these changes, maybe 1.0.9 or 1.1.

Actually I am looking into this issue - as it affects security - to see if I can include it into 1.0.8

Still working on it, so still not sure if this will make it into 1.0.8

Ok

In direct consultation with Steve, his major components of his two part proposal is being utilized directly into 1.0.8.

• 1. Introduction of cookie testing before the creation of a session record, hopefully reducing strain on session table, reducing incorrect session records and giving a more accurate session count
• 2. Three level option for Session ID generated to handle IP subnets and backward compat.  Also a hardening of Session ID by inclusion of HTTP_USER_AGENT and $mosConfig_secret value (randomized value unique to a site).  Which should improve Session ID security even with Subnet option compared to current session ID handling
  This has resulted in a new Global Configuration param  "Session Authentication Method"
  

*Note this change may impact bridging software*

Now although the idea is Steve's the actual code utilized in core is slitghly different - but the affect is the same



Now although there was some discussion about keeping older sessions this idea is not being introduced.  Mainly because this would lead to a dilution of the security level.  Further it would lead to even more sessions in the session db table - which is what we are trying to reduce.  Further it would require more changes in other areas of code.  Basically this is a funcitonality request and as such beyond the scope of Stabiity work.



More detailed information about this change will be published on the Official Developer Blogs during the weekend:
http://dev.joomla.org/component/option, ... Itemid,51/



I'd like to publicly acknowledge Steve for his outstanding work on this matter.
He provided a succinct response and timely solution to an obvious problem.  He meticilously researched the issues at hand and put together a detailed specification of the problem, issues and more importantly provided a solution.  I also thank all the people who provided feedback on his work - helping assist in putting together the solution.

It is only through such strong community participation & involvement in this parthenership that Joomla! will be successful.


Kudos and thanks to Steve!!

Good to hear, nice improvement

I also want a "thank you" for my input in this matter *Is jalous*

Well I can report very positvely that the addition of the Cookie test before the creation of session ids - to try limit overinflated creation of sessions - seems to working properly.

I have uploaded the modifications to http://www.joomla.org
Previously the who's online counter was persistently showing session counts of 8000+, now it reports a more reasonable 200+
You can see that I have now published the who's online module.


The drawback is of course that it wont show people only opening/visiting your site once (as sessions are only created on the 2nd page request of a user) but I think this is countered by the lessening of the strain on the session db table - thereby reducing possibility of this tablke being corrupted - and leads to far more reasonable user count numbers: albeit probably undervalued slightly.

It sure is good to get that report Rey.  It confirms the devs commitment to resolving this issue and the validity of the solution (as concept).



Thank you for the kind words.  It was a small thing given the scope of work undertaken by the devs to constantly improve upon and maintain the codebase.  I am happy to have been able to contribute 

GRAM

Hi can someone please post a link to the patched joomla.php file i have tried to patch the file but i am not a php programmer i have it installed but AOL users are still complaining that they are unable to log in.

Thank you
Swampy

The file attached to the first post in this thread is the latest one Swampy.

The files from 1.08 won't work with any other version, but do essentially the same thing.

Is this the file you are using?

GRAM

If you pull the joomla.php from the 1.0.x SVN this is not enough to institute the changes.

By default the highest security setting is utilized - which is to use Full IP.
o be able to use IP Subnetting (which is what you want for AOL users) you also need the changes to the com_config folder.  This allows you to change the setting from the default.