Several sources are publishing a supposed vulnerability in Drupal. One source is the security site Packet Storm Security and attached here. This post is a response to that issue.
Summary
The Drupal Security team has concluded that this does not constitute a valid vulnerability. The attack depends on a "Man In the Middle" attack or sniffing software, which is outside of Drupal and presents a much bigger risk.
The Drupal Security team provides an easy way to report issues by sending emails to security@drupal.org, and we will credit researchers with all issues they report in this manner. No formal report of this issue was filed directly with our team. We encourage all researchers to follow principles of responsible disclosure, and report directly to our team to ensure both that we can provide public credit for authentic vulnerabilities, and keep our users as secure as possible.
Please see the handbook page for the latest description of how to report security issues.
Our response to specific claims made in the report
Analysis of 2.1 Poor Session Checking (CSRF to change any Drupal settings)
The original report states:
This flaw can be used by [an] attacker [who] knows the values of "[form_build_id]" and "form_token" parameters (for example, an internal attacker performing a "Man in The Middle Attack" or an external attacker that controls an internal client by an client-side exploit, an external attacker that controls directly a Drupal admin by a client-side exploit and son on. There are many possibilities)
The described problem (using the same anti-CSRF token for every action on a site) is actually the exact recommendation by OWASP for how to protect against CSRF. OWASP refers to this as the Token Synchronizer Pattern and it is in use in many systems and on many websites today.
An attacker who is able to read the form_token and form_build_id values via "man in the middle" (MITM) or client-side exploit is presumed to also be able to read other unencrypted elements of the HTTP request such as the username, password and session ID. If they can read the session ID, then performing the exploit as described would be more work than simply stealing the session and directly performing attacks.
Even if there is a scenario where the Token Synchronizer Pattern isn't a sufficient protection, we believe Drupal is not vulnerable to the attack as described. After repeated attempts, we are unable to reproduce the supposed exploit and substantiate the claim that any combination of form_token and form_build_id can be used to submit any other form. We encourage other individuals to attempt to exploit the issue, and confirm or deny their ability to do so privately to the team.
The original title for issue 2.1 is "CSRF to change any Drupal settings." Given that the problem is only CSRF when another exploit like MITM or client-side control is in play, and given that it only affects the specific setting the user has visited, we find this title to be misleading.
Analysis of 2.2 Poor Session Checking (CSRF to Force administrator logout)
This is a known issue that, while annoying, doesn't represent a vulnerability since the only impact is being able to terminate a user's session. The community has debated the security benefit against platform complexity and performance impact in a public issue since 2007 and decided that for most sites it is not worth the trade-off. Users concerned about this issue are invited to work on the problem in that existing public issue.
Analysis of 2.3 Poor Session Checking (POST and GET method)
This doesn't appear to play any specific role in the attack.
Analysis of 2.4 Poor Session Checking (Http Referer)
Drupal is, by nature, a flexible system. A form or link that is located at one URL by the module developer may be moved to a different URL on a specific site by the site builder making the addition of referrer checking difficult. Since HTTP Referrer headers can be spoofed by user agents, and may not even be included in any particular request, these constitute an unreliable method for establishing the validity of requests. Given that these particular exploits require MITM or some form of client-side exploit, the HTTP referrer could also be altered via that mechanism, rendering this additional protection moot.
Analysis of 3.1 Demonstration code
The supposed demonstration code doesn't work for at least two reasons:
- The e-mail address uses a hostname of "new_admin.com," which doesn't pass Drupal's e-mail validation and is not a valid Internet domain name.
- The form_token is based on a hash of:
- the form_id value (a knowable string used to describe the form)
- the user's session ID
- a private key that is stored (by default) in the database, and
- a hash salt that is stored (by default) in Drupal's settings.php file, where other important values like the database credentials are stored.
Drupal's form API validates the form_token during submission of the form by comparing it to a hash for the same form_id. If the token doesn't validate, Drupal will stop form submission and respond with the error message "The form has become outdated. Copy any unsaved work in the form below and then reload this page."
Suggested mitigation steps:
Since the report requires a site be vulnerable to MITM or some other client-side control, the solution is to address those issues with the proper technology:
- HTTPS or other secured network access (e.g. a VPN) prevent MITM and sniffing
- Protect your site against cross site scripting via proper configuration and coding practices
| Attachment | Size |
|---|---|
| drupal712_csrf_disclosure.txt | 5.71 KB |
Comments
I Disagree your analysis
Your analysis is wrong for the following motivations:
1) why do you inserted "Suggested mitigation steps" if you think isn't a real vulnerability?
2) do you know what a POC means? It is ridiculous that the exploit doesn't work because "new_admin.com" is not a valid hostname. IT IS only A POC for demonstration purpose and, normally, to avoid lamer damage in the POC voluntarily the exploit has some mistake.
3)A site cannot be vulnerable to MITM. Is the network that is vulnerable if isn't implemented "Port Security" on network switch or if there aren't IDS/IPS devices to detect and prevent man in the middle.
4) You have some anomalies in "form_token" and "form_build_id" even if you don't want to admit it.
5) A CSRF attack is more silent if you allow to send POST request instead of GET request. I think that this is the meaning.
6) Simple Http_Referrer check would allow to avoid "force logout" CSRF which could aid an hacker to sniff user and password during a MITM
Also Heine's consideration about XSS (http://drupal.org/node/1470254#comment-5714502) are wrong. Is ridiculous that Drupal doesn't perform http_referrer check as XSS could allow to bypass it. This argument is like saying "I don't put the doors at home as could be some thieves able to open them"
If you are concerned about
<img src="/logout">would be sufficient to bypass the referrer check.A referrer check would not add to the strength of the CSRF token system, but would be a hassle for users and developers alike.
The referrer check:
As such, it is less capable than the token system.
Additional discussion
For anyone who happens upon this thread, there is additional discussion on Heine's blog here. The comments are helpful to understand more of what the original advisory author was attempting to point out.
It also helps place the original reply at the top of this thread into context. It does indeed seem that most of the original issues are 'exploitable' only in the event of a MITM or someone can sniff your traffic. If that's the case you have much bigger problems than CSRF.
Most of these were already addressed in the original writeup...
And as for the others:
I think that may be a fair point; however, Greg's writeup above identified two reasons the POC doesn't work. The second one is the actual fundamental reason.
If I do
<img src="http://<drupalsite>/user/logout" />that's a GET request, but it never takes the victim to the page to know they've been logged out. I don't understand how it's possible to be more "silent" than that.In response to: 6) Simple
In response to:
As I understand it the http referrer is optional and is sometimes removed through firewalls, proxy servers, and even in browsers. It's not reliable to use for a purpose like this.
If you're concern is a MITM attack use HTTPS. If someone can perform MITM there are easier ways to get into a system that to watch someone log out and back in. I'd suggest a better understanding of the problem space.
If a particular session is
If a particular session is vulnerable to MiTM, then all bets are off - the very definition of a MiTM means that the attacker can intercept and perform any operation which that session is able to perform. There is nothing that the application can do to protect against this - the only effective defense is to protect the transport.
IBM X-Force advisory
My friends,
IBM X-Force does not think like you:
http://xforce.iss.net/xforce/xfdb/73674 (Drupal 7.12 IBM advisory)
Https does not provide MITM protection. Read more about SSLStrip (http://www.thoughtcrime.org/software/sslstrip/) and similar.
Is not so simple protecting from MITM. I have alredy written some solutions:
Report Confidence:
Report Confidence: Uncorroborated
Exploitability: High - Consequences: Gain Access
Exploitability: High
Consequences: Gain Access
Uncorroborated means that it was not confirmed by vendor.
From the CVSS Complete
From the CVSS Complete Documentation:
Here's my suggestion to you
Here's my suggestion to you or anyone else whose really interested in this. Take a look at the code, setup a test site, and try these exploits. Look at how "man in the middle" (MITM) or client-side exploit comes in and understand all the other vulnerabilities that come around that.
When this "exploit" first came out and the security team had not yet responded to it I did just this to try and understand the impact to Drupal.
Based on several conversations I've had there seems to be a bit of FUD going around in regards to this issue. Lets talk about the details and specific technical issues at hand.
Agreed. Or even file issues
Agreed. Or even file issues and start working on patches to fix the problems. I think there are some legitimate bugs here, but I don't see how the bugs can be exploited for security reasons.
The fact that we have multiple forms with the same form_id should be fixed since form_id determines the form_token.
knaddison blog | Morris Animal Foundation
My tests
I took issue #2.1 with your #3.1 exploit and ran it through a few quick tests. Here's what I did. For sanity, the first part of this was just checking standard form permission validation and not CSRF.
1) Log in to a Drupal 7 site as an authenticated user. No admin rights. Inspected the site to discover a form_build_id and a form_token for a form. In this case it was the default search form.
2) Logged out of the site and made sure all cookies were gone from the browser.
3) Created a local HTML page with the POC, as follows. I used the captured form_build_id and form_token from step 1.
<html><body onload="javascript:document.forms[0].submit()">
<H2>CSRF Exploit change user to admin</H2> <form method="POST" name="form0" action="http://mysite.org/admin/people/create?render=overlay&render=overlay">
<input type="hidden" name="name" value="newadmin"/>
<input type="hidden" name="mail" value="myvalidemail@myemail.com"/>
<input type="hidden" name="pass[pass1]" value="testme"/>
<input type="hidden" name="pass[pass2]" value="testme"/>
<input type="hidden" name="status" value="1"/>
<input type="hidden" name="timezone" value="Europe/Prague"/>
<input type="hidden" name="form_build_id" value="form-CAPTUREDFORMID"/>
<input type="hidden" name="form_token" value="CAPTUREDFORMTOKEN"/>
<input type="hidden" name="form_id" value="user_register_form"/>
<input type="hidden" name="op" value="Create new account"/>
</form>
</body>
</html>
4) Opened that HTML page in the browser and allowed it to post its form.
I expected to receive an 'access denied'. I did receive an 'access denied' message and a 403 page. I also tried the above again with an authenticated user rather than an anonymous user and received the same result.
OK, so let's now get on to the CSRF part of it. I then ran another test, which is closer to what I think he's getting at with the original advisory.
1) Log in to a Drupal 7 site as an authenticated user. No admin rights. Capture a form_build_id and a form_token from any form. I again used the search form.
2) Log out of your authenticated user session.
3) Create the HTML from #3.1 in the original post. Insert the form_build_id and form_token that was saved from your unauthenticated user session.
4) Log in to your site as an administrator. Open the HTML file, which will auto-post the form.
In my case, it dropped me in to the /admin/people/create page - but with a big banner at the top that says "The form has become outdated. Copy any unsaved work in the form below and then reload this page." It did not post the form or create the account, which is why I am posting this reply publicly.
I believe the idea here is that a user with lower privilege could get an admin to visit a webpage with a preloaded form and get it to post back to the site using their existing valid session and cookie. The concept behind the vulnerability is that the form_build_id and form_token are not closely associated with the account that created them.
I don't know if this failed by design or accident in my test, and I have not tried this with D6 or D8.
erickc - is this more along the lines of what you are aiming for?
The thing about form tokens
The thing about form tokens is that they are based, in part, on session id. When the token is generated the session id is used and when the form is validated by drupal this is tested. See drupal_get_token().
In order to get past form token validation someone would need to spoof your session as well. If they are able to spoof your session to mock this form they are able to act as you on the site. Hence the talk about MITM.
If the concern is someone creating a mock form elsewhere to act as a drupal form note this. Tokens are based on a value, session id, private site specific key, and hash salt. So, how could they get a form token and form id specific to a given user. A form token would be different for different users. This is why there's talk of MITM.
Thanks for getting down to
Thanks for getting down to the task and attempting to replicate this specific part of vulnerability.
There is this paragraph here from our response about how we attempted to do the same thing.
When I say "repeated attempts" I mean that Dylan Tack and I did what you describe under several scenarios using the html form from the original report, using webkit and firefox's DOM inspector tools to edit different forms, etc. The only way we were able to use a token from one form on another form is when a user is viewing the same Drupal "form" - i.e. if I'm logged in as an administrator and go to user/1/edit then the form_token I get there as administrator is the same as the token I will get for user/23/edit or user/500/edit during that same session. Trying to use
All of those tests failed for us with different messages.
So the only "vulnerability" we confirmed is if someone can get the form_token/form_build_id for the current user for a form with the same form_id. Then they can potentially use those values to trick that user into submitting that form with different values. HOWEVER, in order to steal an admin's form_token from that form and re-use it on an attack someone has to have some other non-Drupal compromise that is already able to takeover the site via that other non-Drupal compromise. That is why we listed steps to mitigate that solve non-Drupal problems. There's nothing for Drupal to do here, but there are best-practices for server administrators to do.
knaddison blog | Morris Animal Foundation
Agree
Thanks, that's consistent with what I saw. It would be excellent if the original author of the advisory could point out either where we are wrong in our efforts to replicate the issue, or perhaps state that the conclusions in the advisory were inaccurate.
So any idea where this
So any idea where this originated? It seems a lot of it is pretty bogus. I tried the "Exploit" in 3.1 and it did not work with a site I administer.
People publishing false security reports about software is troubling.
Simple steps to reproduce exploit
Sorry for the delay but nobody told me about this discussion.
To reproduce the exploit you have to only:
With exploit provided You can only add normal (not admin) account. To add administrator you have to insert also the following line:
so the exploit become:
CSRF Exploit change user to admin
:80/drupal/admin/people/create?render=overlay&render=overlay">
Brief considerations about this exploit:
- In my original exploit is correctly explained that you only have to sniff form_token and not form_build_id
- In my original exploit I deliberately used fake email domain (simple anti-lamer method)
- In my original exploit I deliberately omitted code () to add administrator (anti-lamer)
- I don't think that this is a high level vulnerability and I agree with greggles when he says that "someone has to have some other non-Drupal compromise...", but ssl is not a definitive anti-MITM solution.
Regarding force logout exploit:
- Drupal should use form_token to avoid this "problem" that could aid an attacker - who I's sniffing Drupal network - to force Drupal administrator to insert his authentication credentials in order to steal them.
I believe in full disclosure http://en.wikipedia.org/wiki/Full_disclosure.
I think that Drupal is a great cms, but do you really think that:
IBM X-Force
Packet Storm
Offensive Security Exploit-DB
many others
publish a security advisory without source verification?
Soon I'll write more about this advisory in my blog.
When you did this testing did
When you did this testing did you have a different session from the one where you sniffed the form_token? It sounds like you had the same session. form_tokens are specific to a users session. Two sessions (even by the same user or two different users) will have difference tokens.
You do point out a legitimate bug in 2 forms having the same form id. No question, this is a bug.
According to the IBM X-Force site (http://xforce.iss.net/xforce/xfdb/73674) this is "Uncorroborated". So, IBM did post it without verifying it.
This is all centered around stopping information taken from a MITM attack (as you sniffed the form_token). MITM attacks happen at a different layer than drupal. This isn't a security issue with Drupal but a specific sites setup. If you can sniff the form_token you can sniff the session and simple spoof being that user. The same applies to a lot of applications.
mfer, the sniffed form token,
mfer, the sniffed form token, say from admin, is used to generate a form that is subsequently posted by the Admin (this is the CSRF). The form token is accepted as valid as it was generated using the same session ID.
The crux of the matter is that we do not consider a sniffed form_token an important vulnerability of the CSRF defense token system. An attacker could simply use the sniffed session ID to became the admin user himself.
To prevent sniffing or MITM use HTTPS on a non borked browser.
Exactly. Said that already
Exactly. Said that already http://groups.drupal.org/node/216314#comment-711589
The exploit become....
<html><body onload="javascript:document.forms[0].submit()">
<H2>CSRF Exploit change user to admin</H2>
<form method="POST" name="form0" action="http://<drupal_ip>:80/drupal/admin/people/create?render=overlay&render=overlay">
<input type="hidden" name="name" value="heine"/>
<input type="hidden" name="mail" value="heine@didnotunderstand.com"/>
<input type="hidden" name="pass[pass1]" value="password"/>
<input type="hidden" name="pass[pass2]" value="password"/>
<input type="hidden" name="status" value="1"/>
<input type="hidden" name="roles[3]" value="3"/>
<input type="hidden" name="timezone" value="Europe/Prague"/>
<input type="hidden" name="form_build_id" value="form-oUkbOYDjyZag-LhYFHvlPXM1rJzOHCjlHojoh_hS3pY"/>
<input type="hidden" name="form_token" value="sniffed_token"/>
<input type="hidden" name="form_id" value="user_register_form"/>
<input type="hidden" name="op" value="Create new account"/>
</form>
</body>
</html>
Several people have asked
Several people have asked (and I have still not seen a clear explanation) of:
(A) Is there a situation where it would be easier for a MiTH to sniff a form_token than a session ID?
(B) If not, then what is the value of this exploit, considering that an attacker who has sniffed a session ID could simply impersonate the user via their session ID to directly build and submit forms themselves?
From my understanding the form_token and session IDs are equally easy/difficult to intercept, and I have not seen any clear reason why a CSRF attack would be used instead of an attacker simply hijacking the users session. Additional hardening of the form_token (while probably worthwhile, since it is easy enough) don't seem to fundamentally strengthen a MITM attack scenario, because the attacker would typically be able to build their own forms (including form_tokens) using a hijacked session.
(B) Yes, there's a scenario
(B) Yes, there's a scenario where the fact that form_tokens are identical for identical form_ids could be necessary to exploit a sniffer (note: not MiTM): When login or access to a site is eg IP-restricted and CSRF HAS to be used.
The only way to sniff in
The only way to sniff in switched network is to perform a MITM attack.
@mref @heine
@mref
- yes the test was performed in the same session context, but this is CSRF.
- try to send to IBM X-Force a fake vulnerability and let me know when it will be published ;-)
@heine
- Owasp says (https://www.owasp.org/index.php/Man-in-the-middle_attack):
"The MITM attack could also be done over an https connection by using the same technique; the only difference consists in the establishment of two independent SSL sessions, one over each TCP connection."
Let me see if I understand if
Let me see if I understand if I understand what you are saying. This CSRF is targeted at a specific user session and you need a MITM attack to get the information for the specific session. The technique used here follows the OWASP recommendation for this.
Are you posting exploits against every project open to MITM in the middle attacks that also follow the OWASP recommendation for tokens?
- try to send to IBM X-Force
Somebody already successfully did this on March 02. It got published on March 12.
The browser will complain
The browser will complain that the certificate is invalid.
The browser will complain
Note the collection of certificate authorities that have mistakenly(?) issued SSL certificates(in come cases root certs) to malicious users. Also look into the brokenness of how various browsers respond (or don't) to malicious SSL certs - either not updating CRLs, ignoring CRLs, accepting invalid CA chains, or still trusting CAs which have been invalid for significant periods of time. Most recently Chrome recognized CRLs are not worth the effort and stopped relying on them, instead using google-published blacklists.
And then there's the fun of how users have been trained that "Oh it's OK to ignore that warning."
SSL alone is no longer acceptable mitigation to web application vulnerabilities. Defense needs to be done in depth.
Protected Industries
Please post a feature request
Please post a feature request in the core queue for what we should do with the session token.
If you bypass SSL and perform
If you bypass SSL and perform a MITM attack stealing a session based form token is the least of your worries. Someone could just take your session id and spoof being you on the site all together. This applies not just to Drupal but to PHP sessions and sessions across different platforms.
When you look at how you get form tokens for a specific user session and see the other data available (session id among them) this is a bigger issue than form tokens. Looking at how MITM attacks happen to obtain all this data it's at a level other than the application level. While we can debate the merits of SSL the debate is at a level other than the application.
How do you suggest Drupal (the application) stop MITM attacks that happen at a lower level in the stack? If you have a great answer that protects session sniffing and other MITM issues A LOT of projects will be interested in them. Otherwise this issue isn't with Drupal but with securing a different layer in the stack.
So I went through and labbed
So I went through and labbed it out to reproduce the exploit. My findings:
D7 seems to be implementing Synchronizer Token Pattern just fine. I think when I read the vuln post my interpretation was that form_build_id/form_token could either be used from another user, or could be replayed. That's not the case, so my apologies for thinking the Drupal dev team had done otherwise. That pretty much is state of the art and what I usually advise my clients to implement in their applications.
One way I could see to improve the implementation is to bind the intended action to the form - this way an un-used "create page" token could not be used to create a user. I suspect this is what Ivan is getting at. Note, MITM attack is not needed here. I believe I can craft a chained attack (xss+xsrf, or probably clickjack) which would result in admin privileges being misused.Either way, guys - remember we're here to make Drupal a better, safer product. Let's keep the discussion civil.
John
CORRECTION: Went back and double-checked, I'm NOT able to use a "create page" token to create a user.
Protected Industries
Drupal tokens are more than
Drupal tokens are more than form_id + session based. You can see the details in drupal_get_token. It's always worth reading the code.
A token for "create page" would not be the same as that for creating a user. See drupal_prepare_form. Different forms with different form ids get different tokens. For example the node add form for pages would have a form id of page_node_form. To create a user the user register form is called with an id of user_register_form. These two "actions" get different tokens because drupal_prepare_form uses the form_id as as part of the token generation.
If I "intercept" form_build_id/form_token I can use them, once.
John,
you only have to intercept form_token. You can use any "form_build_id".
Note that to use my exploit (add admin account) you need to intercept a form_token generated with "Create new account" form_id.
To "create a page" you need to intercept specific "form_token" generated for that form_id.
To force logout you don't need to intercept form_token.
You only have to intercept
Understood. But what would you suggest the Drupal team do to minimize this exposure?
John
Protected Industries
Hi John, I suggest to make
Hi John,
I suggest to make form_token unique for any single operation (not for form_id) an admin/user performs, exactly as other application/cms already done.
Furthermore Drupal need to implement an anti-CSRF solution in logout script.
Http_referrer check could be another improvement (to be used with form_token), but is not so important if form_token works correctly.
Simple, not? In my opinion these are little improvements that could make better this great cms.
John I like your approach which is, in my opinion is, the right one to reach good result.
Ivano
Forms in Drupal are
Forms in Drupal are persistent between requests. When a form is validated and processed for a user we have the details about the form from when it was generated. Some form information is stored in this persistent state and not sent in the html. The value used to generate the token is stored in this persistent store. The form token is validated based on this value. This means the build id can't be spoofed to use a different token with it. We know exactly what token should be associated with that submission.
The case for the create new account functionality never occurs in practice. That form appearing to an anonymous user and to a user admin account would will have a different form token. Form tokens are based on session id. When a user logs in their session is regenerated.
Your descriptions of dealing with tokens seem to be absent of how tokens actually work within Drupal. I've linked to plenty of code within Drupal, please take some time to read it. Please accurately represent what's happening.
@proindustries
@proindustries I completely agree with you! Drupal should implement all defences to make MITM related vulnerabilities more difficult to exploit.
@Gerhard, @mref
@Gerhard
If what you are saying is true you should insert references to it.
@mref
Do you want really know what I think? I think that if you don't know what a CSRF vulnerability exactly means you should not write comment in this group (at least not for security related questions). Sorry for my sincerity.
I've analyzed Joomla 2.5.1 (Attention I'm not saying that Joomla is better than Drupal) and the anti-csrf token is generated different for every single operation. So I think that, also if this is not a high level vulnerability (IBM X-Force correctly classify it as "Medium Risk") Drupal could fix it, also regarding "force logout" problem (even if also this is not high level vulnerability).
Regarding IBM X-Force:
- I have not sent them Drupal CSRF vulnerability.
- As you can read in the Advisory (http://xforce.iss.net/xforce/xfdb/73674) they refer to Packet Storm and Offensive Security Exploit-DB.
If you think that all Packet Storm or Offensive Security Exploit-DB vulnerabilities/exploits become automatically official IBM X-Force advisories, you can check by yourself that this is not true.
If what you are saying is
Of course:
http://xforce.iss.net/xforce/xfdb/73674
The forced logout protection
The forced logout protection you suggested was to check the http referrer. This is an optional header. In browsers sending the http referrer header can be disabled. Proxy servers can be configured to remove the http referrer. There is even a section on wikipedia about referrer hiding. Relying on this optional field would mean users in situations where referrer is removed would not be able to log out of these sites. This is a problem.
If someone does want enforce http referrer checking this could be done quite simply in contrib. But, before you do this I would suggest understand the usage patterns of this header as you could get yourself into trouble with your users if they find themselves in situations where they can't log out.
As for CSRF in general, the suggestion from OWSAP is to use tokens like those that are used here. If you have a general suggestion on handling CSRF that's better than what OWSAP recommends please share it.
For the specific cases you call out in in 2.1 there is a misunderstanding. Form tokens are generated per user session per form id. Two forms with different form ids will have different tokens. For example, the form token from a comment form cannot be used to submit a form for an admin page. The value used to generate the token and validate it is not sent as part of the form. So, changing the form_build_id and form_token to be 2 that work together on a different form won't work. Forms have a saved state between page requests and details are stored there.
In the example above the user registration form is called out as an example. The same form is used for /user/register (public registrations) and for /admin/people/create (the admin method for creating users) which means they have the same form id. Form tokens are generated per user session. Only anonymous users can visit /user/register for a public registration. Registered users cannot visit this page (even uid 1 can't). Only registered users who can create users can visit /admin/people/create. Since tokens are based, in part, on session id these tokens won't be the same.
In the technical details here or in the code can you please point out the security issue is? Speaking in generalizations doesn't help.
The exploit in 3.1 only works if you have successfully performed a MITM attack to obtain the form_token for a specific user in a specific session on a specific form for a specific site (form tokens on every site are different). Then you get that user on that session for that site to submit your form. Please take a look at how form_tokens are generated.
Too many generalizations are being thrown around. Lets talk about implementation specifics. Outside of MITM attacks which are at a different level in the stack I'm not seeing the specific security issue in question. If I'm missing something please point me right to it in the code with some details.
I've analyzed Joomla 2.5.1
I looked around (briefly) and just found http://docs.joomla.org/How_to_add_CSRF_anti-spoofing_to_forms - could you explain a little more how Joomla's approach is different than Drupal?
John
Protected Industries
CVE-2007-6752
MITRE CVE Numbering Authority assigned CVE-2007-6752 for "force user/logout" vulnerability (sections 2.2, 3.2 of my Drupal 7.12 CSRF Advisory).
Furthermore MITRE CVE Numbering Authority, considers that:
. Sections 2.1 and 3.1 – Poor Session Checking (CSRF to change any Drupal settings) – would be a Drupal’s “Security Improvement”.
. Section 2.3 – Poor Session Checking (POST and GET method) – and section 2.4 - Poor Session Checking (Http Referer) - would be Drupal’s “Potential Security Improvements”.
I like to use the logout
I like to use the logout "vulnerability" in training emails to site admins, asking them to click on Log out (which I actually link to https://example.com/user/logout) when they have finished their work. An HTTP referrer check would prevent me doing that :)
There's now a discussion of
There's now a discussion of this issue on the Security.StackExchange forum. Summary of the responses: bogus report, no vulnerabilities identified, Drupal should consider responding to POSTS/GETS differently and consider making logout link a POST (but neither is a security issue per se).
knaddison blog | Morris Animal Foundation