View Issue Details

IDProjectCategoryView StatusLast Update
0000218Main CAcert Websitesource codepublic2013-11-20 22:23
Reporteraanriot Assigned To 
Status closedResolutionfixed 
Fixed in Version2006 
Summary0000218: variables not reset
DescriptionWhen logging into the CAcert website the session variables are not reset. This allows to transfer permissions you have for one account (e.g. fully assured) to another (not assured / different name / fake data).

This case is untested but should work.
Additional Information1. Login with a fully assured account
2. Do someting that populates session variables like SESSION['config']
3. do NOT log off - just login with an unassured account
4. SESSION['profile'] will be reset but not SESSION['config'], etc.
5. finish the process you started using the old data from SESSION['config']

Haven't looked for exploits but I'm sure there are a lot! Please make sure that any old session is completely destroyed when someone is logging on.
TagsNo tags attached.
Reviewed by
Test Instructions



2006-04-25 21:24

manager   ~0000208

Possible exploit:

1. Add a domain to account A
2. Submit CSR with account A (do not yet run account?id=11)
3. delete domain from account A
4. change profile to account B
5. add domain to account B
6. complete submition of CSR

A cert with the name of user A will be connected to account B. This might even be a class 3 cert. It's not easily possible to detect this cert even if you discover that user A is an assured fake account.


2006-08-03 23:10

developer   ~0000286

How were you able to login a second time, if I try to hit the login page I get redirected when it detects the cookie...


2006-08-03 23:18

developer   ~0000287

Sprinkled special sauce through out loggedin.php

                        $_SESSION['profile']['loggedin'] = 0;
                        $_SESSION['profile'] = "";
                        foreach($_SESSION as $key)


2006-08-04 00:35

manager   ~0000297

> How were you able to login a second time, if I try to hit
> the login page I get redirected when it detects the cookie...

Just open the login page twice with the same browser before you login as A. So you have a spare login page for the second login as user B. You could do this manually aswell without a browser or by manipulating the cookie database of your browser.

I'll have a look at your solution. Is the tarball up to date?


2006-08-08 04:11

developer   ~0000327

Tarball is up to date, I've modified the original solution as this was messing with cerificate logins, changes in the tarball...

Issue History

Date Modified Username Field Change
2006-04-25 21:17 bluec New Issue
2006-04-25 21:24 bluec Note Added: 0000208
2006-08-03 23:10 duane Note Added: 0000286
2006-08-03 23:18 duane Status new => solved?
2006-08-03 23:18 duane Resolution open => fixed
2006-08-03 23:18 duane Assigned To => duane
2006-08-03 23:18 duane Note Added: 0000287
2006-08-04 00:24 Sourcerer Status solved? => needs work
2006-08-04 00:24 Sourcerer Assigned To duane => bluec
2006-08-04 00:35 bluec Note Added: 0000297
2006-08-08 04:11 duane Status needs work => solved?
2006-08-08 04:11 duane Fixed in Version => production
2006-08-08 04:11 duane Note Added: 0000327
2007-10-24 06:22 evaldo Reporter bluec => aanriot
2007-10-24 06:22 evaldo Assigned To bluec =>
2007-10-24 06:22 evaldo Status solved? => closed
2013-01-14 08:12 Werner Dworak Fixed in Version => 2006
2013-11-20 22:23 NEOatNHNG View Status private => public