View Issue Details

IDProjectCategoryView StatusLast Update
0000608Main CAcert Websitemy accountpublic2013-11-20 22:23
ReporterC_A Assigned To 
PrioritynormalSeveritymajorReproducibilityhave not tried
Status closedResolutionopen 
Fixed in Version2009 Q3 
Summary0000608: CSRF vulnerabilities
DescriptionThis issue was orginaly reported privately
to on 07. june 2008
and is now put here, just to not get lost.


today I investigated if CAcert's forms are vulnerable to CSRF attacks
and there were no big problems to setup such an attack.

There can be various scenarios where a CSRF attack can start from, lets
begin with the worst case.

 a) User has a client certificate installed and no master password
(firefox/iceweasel) set.
In this case the user does not even has to be logged in to start an
attack against him because for the login no user interaction is required
(I can only speak for firefox/iceweasel).
Just call before you do
anything else and you (as an attacker) are fine.

 b) User has a client certificate installed and master password set, was
already logged in, clicked on the logout button but didn't close the
browser entirely. Requirements for login: none (master password is saved
until broser is closed)

 c) If the target user has no client certificate installed (password
login) or uses client certificate with master password set and was not
yet logged in, a certain amount of social engeneering is necessary to
have a beachhead for a CSRF attack

I tried csrf attacks (on myself) on these sites/features:
    * change secret questions**
    * change password (certificate login only)**
    * change contact info
    * add new email address
    * change language

**user will get an email notification

all of these would end successfully for an attacker.
TagsNo tags attached.
Reviewed by
Test Instructions



2008-09-07 23:20

administrator   ~0001156

Thanks a lot of your report!

The CSRF vulnerability has been closed for the mentioned features.
Please review the implementation of the fix.
Additionally, please research, which other features have to be protected as well.

(The only exploit vector I do not understand is "change password", since there the attacker would have to know the current password, which would make the CSRF attack a bit pointless. How did you test this vector?)


2008-09-08 08:25

reporter   ~0001157

If you login using your client certificate the current password is not requested to change the password. For that reason there was "(certificate login only)" behind the "change password" point.
So the 'change password' pages differ depending how you logged in.
Only the page used when loging occurs with a client certificate has to be protected.

I guess also an assurance maybe possible using csrf if the attacker knows everything about the person who wants to get assured. I obviously didn't try it out (on myself as an assurer) because if successful it would result in a forged assurance.
So the new introduced 'csrf' field maybe added also here

From a quick look at the page html source it looks fine - a good common csrf protection - I will try to fetch the new php source later.


2008-09-08 14:24

developer   ~0001159


2009-09-20 17:11

administrator   ~0001480

CSRF protection has been implemented at the mentioned places and a few other ones. Please test again now. (Preferrably on the testsystem)


2012-05-30 21:17

administrator   ~0003033

Closing issues that have been resolved more than one year ago…

Issue History

Date Modified Username Field Change
2008-09-06 00:10 C_A New Issue
2008-09-06 02:12 Sourcerer View Status public => private
2008-09-07 23:20 Sourcerer Note Added: 0001156
2008-09-07 23:20 Sourcerer Status new => confirmed
2008-09-08 08:25 C_A Note Added: 0001157
2008-09-08 14:24 iang Note Added: 0001159
2009-09-20 17:11 Sourcerer Note Added: 0001480
2009-09-20 17:11 Sourcerer Status confirmed => solved?
2012-05-30 21:17 NEOatNHNG Note Added: 0003033
2012-05-30 21:17 NEOatNHNG Status solved? => closed
2013-01-15 02:59 Werner Dworak Fixed in Version => 2009 Q3
2013-11-20 22:23 NEOatNHNG View Status private => public