Problem/Motivation
A FILTER_MODE_BLACKLIST was added to the Xss
class. To call this dangerous is a serious understatement. People might get confused as to which one to use and a flawed call coupled with blacklist is a sechole. With the traditional whitelist, there is much less confusion and you need to straightforward enable insecure tags.
Proposed resolution
- Remove FILTER_MODE_BLACKLIST from the Core namespace. Nuke it from orbit. Have you guys completely lost your mind?? One bad call to this and your site is toast.
- Make Drupal\editor\EditorXssFilter\Standard extend Xss
- Factor out if (!isset($html_tags[strtolower($elem)])) into a method.
- Override method
Remaining tasks
User interface changes
API changes
The optional $mode argument is gone from Filter::Xss
. Good riddance. Change notice at https://www.drupal.org/node/2365293
Comment | File | Size | Author |
---|---|---|---|
#36 | 2364647.36.patch | 12.81 KB | alexpott |
#36 | 16-36-interdiff.txt | 2.27 KB | alexpott |
#16 | 2364647_16.patch | 12.1 KB | chx |
Comments
Comment #1
chx CreditAttribution: chx commentedComment #2
chx CreditAttribution: chx commentedComment #3
chx CreditAttribution: chx commentedComment #4
chx CreditAttribution: chx commentedComment #8
Wim LeersYes, calling it incorrectly will lead to security problems. Just like forgetting to call
Xss::filter()
at all will lead to security problems.Your proposal sounds fine though — as long as the logic continues to work in the same way (i.e. functionally equivalent), I'm fine with that.
Comment #9
chx CreditAttribution: chx commentedComment #10
Fabianx CreditAttribution: Fabianx commentedRTBC, the proposal looks great to me.
Thanks chx for reminding us that by providing insecure APIs, they will be used in strange ways.
Secure-by-default FTW!
Comment #11
dawehnerI think chx did not wanted to already RTBC this issue.
We do have a compser.json as part of Drupal\Component\Utility so we should ensure that our tests don't rely on some module code,
or in other words you can't really commit and issue which still has remaining tasks :)
Comment #12
chx CreditAttribution: chx commentedYeah, it's not ready for sure, look at the IS, lists remaining tasks. 1) and 2) is technical and easy. 3) is not so easy although it shouldn't block this patch.
Comment #13
dawehner@chx
Idealy 3) should be a blocker in general, as it has shown a clear problem in our process.
Comment #14
Fabianx CreditAttribution: Fabianx commentedWoops, sorry. I missed that part in the IS. Thanks, dawehner.
Comment #15
chx CreditAttribution: chx commentedNow it should be ready. Doxygen added, test moved (and I ran both locally). As for fixing our process, I have no idea.
Comment #16
chx CreditAttribution: chx commented1 character doxygen fix. Also,
4 files changed, 94 insertions(+), 97 deletions(-)
the patch is net negative while significantly more secure. Sigh.Comment #17
Fabianx CreditAttribution: Fabianx commentedI could not find anything problematic here, the patch looks good. Test coverage is the same and applies to its own scope => RTBC
Comment #18
Wim LeersPatch looks good.
Comment #20
alexpottFor some reason
Drupal\Tests\editor\Unit\EditorXssFilter\StandardTest
does not pass locally for me - sending back for a retest.Comment #21
chx CreditAttribution: chx commentedComment #24
alexpottI broke HEAD - that has nothing to do with my local fails unfortunately. Investigating.
Comment #25
dawehner+1
Comment #26
alexpottSo this is a php version thing.
PHP 5.5.8 (cli) (built: Jan 12 2014 18:50:29)
failsPHP 5.5.18 (cli) (built: Oct 19 2014 15:32:33)
passesComment #27
Wim LeersI've been working with 5.5.11 for many months now. So this must be something that's changed in PHP in version 5.5.12 or later. Looking at the changelog now.
Comment #28
Wim LeersMost likely candidates:
Comment #29
Wim LeersDisregard #27 and #28; apparently HEAD works fine with 5.5.18, it's specifically this patch that triggers a failure on 5.5.18. I'm now betting it's late static binding, because that's the only noteworthy change here.
Comment #30
alexpottPHP 5.4.24 (cli) (built: Jan 12 2014 18:13:14)
fails tooPHP 5.6.0alpha1 (cli) (built: Jan 24 2014 09:16:15)
failsPHP 5.4.34 (cli) (built: Oct 19 2014 15:13:21)
passesPHP 5.6.2 (cli) (built: Oct 19 2014 15:53:04)
passesComment #31
alexpottLooks like https://bugs.php.net/bug.php?id=66622 is catching us.
Comment #32
Fabianx CreditAttribution: Fabianx commentedWe should run our unit tests through travis-ci to test on more PHP versions? (but that is really off-topic - follow-up?)
Comment #33
chx CreditAttribution: chx commentedComment #34
catchAdded this issue to #1867192: Testbots need to run on 5.4, 5.5, 5.6 and 7.
Comment #35
dawehnerDid someone verified whether self:: works here without problems? The amount of usecases to override just that particular method is pretty low to be honest.
Comment #36
alexpottThis fixes the issue by kind of doing our own late static binding. Tested on PHP 5.5.8 and 5.5.18 - works a treat.
Comment #37
Fabianx CreditAttribution: Fabianx commentedA very nice idea! :)
Back to RTBC
Comment #38
catchThis looks good and the workaround for the static binding/anon function issue is both nifty and self-contained.
Committed/pushed to 8.0.x, thanks!
Comment #41
quietone CreditAttribution: quietone at PreviousNext commentedPublish the change record.