View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000195Main CAcert Websitesource codepublic2006-04-04 04:362013-11-20 22:23
ReporterbluecAssigned To 
PrioritynormalSeveritytweakReproducibilityalways
Status closedResolutionfixed 
Fixed in Version2006 
Summary0000195: Session Security
DescriptionIf you use session_start() the php either generates a new session ID or recovers an existing one. It is possible to exploit this to access other users accounts if they follow a specially crafted link.

Example:

1. Attacker A tells user B to access http://www.cacert.org/?PHPSESSID=12345
2. CAcert will generate a Cookie with the PHPSESSID 12345 for user B
   If B logs on the attacker A knowns his session ID and can read this
   lost password questions.
Additional InformationWorkaround: Not possible. Just don't follow other peoples links.

Possible fix in the source code: As long as a user is not logged on don't create a session. At least change the session ID everytime the user accesses the page. This can be easily and sufficiently done using session_regenerate_id(), eg.

if (not-logged-on) { session_regenerate_id(); }
TagsNo tags attached.
Reviewed by
Test Instructions

Activities

bluec

2006-04-04 19:55

manager   ~0000143

CAcert doesn't accept Session IDs sent via GET. Without knowing the settings in php.ini I guess that session.use_only_cookies is activated. This should be sufficiant to avoid session fixiation.

Anyway I would recommend not to use "cacert" instead of "PHPSESSID" in the cookies CAcert sends out. It is more likley that people trust the first link than the second (see below). If for any reason session fixiation might be possible this might be a problem.

  http://www.cacert.org/?id=5&cacert=1
  http://www.cacert.org/?id=5&PHPSESSID=1

Also adding something like if (not-logged-on) { session_regenerate_id(); } might increase security a bit more aswell.

Binding sessions to an IP address is not considered to be usefull as the IP address might change with every request and this is allowed by the http protocoll.

duane

2006-04-21 07:14

developer   ~0000171

if($_SESSION['profile']['id'] > 0)
                session_regenerate_id();

bluec

2006-04-21 17:47

manager   ~0000178

Well ... now you're generating a new session ID every time an logged-in user access the site. As this really makes it impossible to steal a session ID it introduces some (theoretical) issues:

* What if I quickly open two cacert pages in my browser. Both requests will have the same coockie sent to the server but only the first request will be processed as it will change the session ID and invalid the cookie of the second request.

* The coockies are stored as files on the server. I'm not sure about the impact the regeneration might have on the systems load.


My recommendation was do regenerate the ID every time a user accesses CAcert _before_ she logs on. Doing that afterwards is an interesting approache which I have to think about ...

duane

2006-04-21 18:26

developer   ~0000182

In any casee it's no longer a security issue...

bluec

2006-04-21 20:30

manager   ~0000185

There is still a security issue if you exploit a race condition:

If an attacker initiates a session fixiation he knows the session ID the users uses to log in. In that session (which session ID is not regenerated in the current solution) the variable $_SESSION['profile']['loggedin'] will be set to 1 in www/index.php:155.

In www/index.php:166 the the users receives a header("location: https://".$_SERVER['HTTP_HOST']."/account.php");

If the user doesn't follow that location header (e.g. DoS) or the attacker is quicker to follow it, the session ID will be regenerated for the attacker and the user isn't logged in anymore.

The user will just be promted for his password a second time but wouldn't notice the attack.

Solutions:

Either ALWAYS regenerate the session ID or just do it while the user is NOT logged in. The later is the solution as recommended in PHP security handbooks.

Please do not add an additional if($_SESSION['profile']['id'] > 0) session_regenerate_id(); before the location-Header is sent.

duane

2006-08-14 02:30

developer   ~0000393

removed the regenerate the session ID code, and made sure that the php.ini uses only cookies...

session.use_only_cookies = 1

bluec

2006-08-14 02:50

manager   ~0000396

Looks good.

(Could you in the future assign bugs to the reporter to verify the solution and close it?)

duane

2006-08-14 03:01

developer   ~0000401

Do all reporters have the ability to close bugs?

duane

2006-08-14 03:01

developer   ~0000402

Also how is bug 0000226 related to this bug?

bluec

2006-08-14 03:51

manager   ~0000417

The relation to bug 0000226 was a rough guess.


I changed the mantis configuration that reporters can close their bugs now.

Viewers (=everyone) can set "open" and "feedback".
Reporters can set "closed"
Admins can set everything

duane

2006-08-14 04:24

developer   ~0000420

Ok so this bug was assigned to you, in future I'll assign and then mark as resolved.

As for bug 0000226, I've removed the link, I doubt they are the same thing...

Issue History

Date Modified Username Field Change
2006-04-04 04:36 bluec New Issue
2006-04-04 19:55 bluec Note Added: 0000143
2006-04-04 19:55 bluec Severity major => tweak
2006-04-04 19:55 bluec Status new => needs feedback
2006-04-04 19:55 bluec Resolution open => suspended
2006-04-04 19:55 bluec Summary Fun with IDs => Session Security
2006-04-04 19:55 bluec Description Updated
2006-04-21 07:14 duane Status needs feedback => closed
2006-04-21 07:14 duane Note Added: 0000171
2006-04-21 07:14 duane Fixed in Version => production
2006-04-21 17:47 bluec Note Added: 0000178
2006-04-21 17:48 bluec Assigned To => duane
2006-04-21 17:48 bluec Status closed => needs feedback
2006-04-21 17:48 bluec Resolution suspended => reopened
2006-04-21 18:26 duane Status needs feedback => closed
2006-04-21 18:26 duane Note Added: 0000182
2006-04-21 18:26 duane Resolution reopened => no change required
2006-04-21 20:30 bluec Note Added: 0000185
2006-04-21 20:30 bluec Status closed => needs work
2006-05-06 18:22 bluec Relationship added related to 0000226
2006-08-14 02:30 duane Status needs work => solved?
2006-08-14 02:30 duane Resolution no change required => fixed
2006-08-14 02:30 duane Note Added: 0000393
2006-08-14 02:50 bluec Note Added: 0000396
2006-08-14 02:50 bluec Assigned To duane =>
2006-08-14 02:50 bluec Status solved? => closed
2006-08-14 03:01 duane Note Added: 0000401
2006-08-14 03:01 duane Note Added: 0000402
2006-08-14 03:51 bluec Note Added: 0000417
2006-08-14 04:21 duane Relationship deleted related to 0000226
2006-08-14 04:22 duane Status closed => needs work
2006-08-14 04:22 duane Assigned To => bluec
2006-08-14 04:22 duane Status needs work => closed
2006-08-14 04:24 duane Note Added: 0000420
2013-01-14 03:09 Werner Dworak Assigned To bluec =>
2013-01-14 03:09 Werner Dworak Fixed in Version => 2006
2013-11-20 22:23 NEOatNHNG View Status private => public