See the form API portion of https://drupal.org/SA-CORE-2014-001 and the form API portions of the patch in http://drupalcode.org/project/drupal.git/commitdiff/dc791ec5839b52c7616b....
This should be forward-ported to Drupal 8.
Since it was more of a security hardening than an actual security fix, possible backport to Drupal 6 can also be discussed here.
Comment | File | Size | Author |
---|---|---|---|
#9 | 2174443-9-programmatic-form-submission-access.patch | 5.42 KB | mr.baileys |
#9 | 2174443-interdiff.txt | 1.51 KB | mr.baileys |
#6 | 2174443-6-programmatic-form-submission-access.patch | 5.39 KB | mr.baileys |
#6 | 2174443-interdiff.txt | 2.27 KB | mr.baileys |
#4 | 2174443-4-form-access-bypass-check.patch | 4.84 KB | mr.baileys |
Comments
Comment #1
David_Rothstein CreditAttribution: David_Rothstein commentedIn fact here's a Drupal 6 patch (basically the same people who worked on the Drupal 7 version in the S.A. also get credit for starting work on this one).
Comment #2
David_Rothstein CreditAttribution: David_Rothstein commentedBy the way, there was also some discussion in the security team about whether (in Drupal 8, where we can break APIs) the security hardening should default to being on for all programmatic form submissions, rather than off like in the security release.
Comment #3
David_Rothstein CreditAttribution: David_Rothstein commentedProbably we should also add a paragraph of documentation to drupal_form_submit() about how/when to use this parameter (and that part would need backport to Drupal 7 as well).
Comment #4
mr.baileysHere is a forward-port to D8 with some basic tests. Stills needs the documentation paragraph explaining the existence and usage of
programmed_bypass_access_check
inFormBuilderInterface::submitForm()
.Comment #5
pfrenssenOverall this looks very good and we really need this in D8.
Great documentation!
Using isset() to avoid notices being thrown is ingrained in every PHP developer's muscle memory, but has no place in a test. Use $this->assertEqual() instead to compare the two values.
This is actually testing two things, but which is the expected behaviour? I assume the value is expected to be empty, so you can use $this->assertFalse() on it.
There is also a superfluous line of whitespace here.
Comment #6
mr.baileysAddressed the remarks from #5
Comment #7
pfrenssenIt's looking great now, thanks!
Comment #8
catchI think we should default this to FALSE rather than TRUE. Can we open a follow-up for that maybe? It won't be in the backport to 6.x so don't want to hold this up.
Comment #9
mr.baileysdrupal_form_submit()
with\Drupal::formBuilder()->submitForm()
Comment #10
catchThose changes look good, thanks for opening the follow-up.
Comment #12
pfrenssenComment #13
catchNeeds porting still I think.
Comment #14
pfrenssenIs already included in 7.x as a security fix in 7.26. Still needs to be backported to 6.x.
Comment #16
C-LogemannWe try to get the D6 version of the important services module running again and we have a security issue waiting of D6 port of this patch: #2189921: D6 Backport of "SA-CONTRIB-2014-007 - Services - Multiple access bypass vulnerabilities"
The test of D6 Backport patch by @David_Rothstein (#1) is passing. Needs some review now.
Comment #17
catchComment #18
mr.baileysComment #20
JamesK CreditAttribution: JamesK commentedThe patch in #1 works fine and provides the necessary hardening.
Comment #21
C-LogemannThanks @JamesK for your review.
Can we please get this patch committed to D6?