View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000608 | Main CAcert Website | my account | public | 2008-09-06 00:10 | 2013-11-20 22:23 |
Reporter | C_A | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | open | ||
Fixed in Version | 2009 Q3 | ||||
Summary | 0000608: CSRF vulnerabilities | ||||
Description | This issue was orginaly reported privately to support@cacert.org on 07. june 2008 and is now put here, just to not get lost. Hi, 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 https://secure.cacert.org/index.php?id=4 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. | ||||
Tags | No tags attached. | ||||
Reviewed by | |||||
Test Instructions | |||||
|
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?) |
|
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 https://www.cacert.org/wot.php?id=5 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. |
|
http://en.wikipedia.org/wiki/Cross-site_request_forgery http://www.codewalkers.com/c/a/Miscellaneous/Stopping-CSRF-Attacks-in-Your-PHP-Applications/1/ |
|
CSRF protection has been implemented at the mentioned places and a few other ones. Please test again now. (Preferrably on the testsystem) |
|
Closing issues that have been resolved more than one year ago… |
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 |