Problem/Motivation
SA-CONTRIB-2013-082 was fixed for bean.module, but D8 has exactly the same problem with block_content (and maybe other custom block implementations as well)
To reproduce, just create a block content with <script>alert('booo')</script>
. It's fine on the block content overview, it's fine on the block selection sidebar, but when you click on it, you get a boo dialog, because the block description is not escaped.
Proposed resolution
The question is whether admin_label is supposed to be a safe string, so that implementations, like block_content need to check it, like bean.module did in 7.x, or if we should enforce it in block.module and run them through checkPlain()/filterXss().
Remaining tasks
User interface changes
API changes
Comment | File | Size | Author |
---|---|---|---|
#10 | block_content_titles-2446995-10.patch | 4.38 KB | tim.plunkett |
#7 | block_content_titles-2446995-7-PASS.patch | 3.59 KB | tim.plunkett |
#7 | block_content_titles-2446995-7-FAIL.patch | 2.75 KB | tim.plunkett |
Comments
Comment #1
BerdirComment #2
BerdirWhich means that #2273925: Ensure #markup is XSS escaped in Renderer::doRender() would have prevented this I guess.
Comment #3
BerdirNote: You can do the same with menus and I suspect that the same is true for views.
Comment #4
Berdir#2025649: Add title-related methods to BlockPluginInterface to help clarify and resolve many issues was trying to clarify that the admin_label is a raw and must be filtered.
Comment #5
tim.plunkettComment #6
tim.plunkettWorking on a test.
Comment #7
tim.plunkettComment #10
tim.plunkettComment #11
tim.plunkettOops, forgot interdiff. Was just this:
Comment #12
tim.plunkettOff my game
Comment #13
kim.pepperReviewed with @jibran and looks good.
Comment #14
tim.plunkettComment #15
Fabianx CreditAttribution: Fabianx commentedComment #16
webchickMakes sense. Thanks for the quick identification AND turnaround of this one!
Committed and pushed to 8.0.x. Thanks!