Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
image system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
20 Jan 2012 at 09:33 UTC
Updated:
21 Jun 2024 at 19:19 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
anrikun commentedPatch below fixes this issue.
Comment #2
swentel commentedThe check_plain for the options is indeed redundant, however, it should be check_plain'd in the table row imo, because there's a potential (although small) issue here. Open up the image.effects.inc and change the label of image resize to this:
Select that effect and you'll see a nice javascript popup, so a potential xss issue (although small, as this requires the right permission, but still). Patch attached adds check_plain on the table row so this doesn't happen.
Comment #3
swentel commentedWrong status, sorry
Comment #4
swentel commentedStill valid, rerolled since it didn't apply anymore.
Comment #5
swentel commentedAssigning to quicksketch for review
Comment #6
quicksketchLooks good to me at first pass. I'll apply and test this evening. I'm guessing this affects 7.x too?
Comment #7
quicksketchAgreed. This isn't an XSS hole in itself, there would need to be a module installed that specifically included an image effect that included an XSS string as an image effect label. If a module wanted to cause a ruckus though, it certainly has a lot more opportunities than XSS, since it's already running on the server anyway. ;)
Patch works as advertised, both properly escaping the image effect label when displayed in the table and not double-escaping the effect label when displayed in the "Add new effect" select list.
Comment #8
dries commentedCommitted to 8.x. Moving it to 7.x. Thanks guys.
Comment #9
dcam commentedBackported #4 to D7.
Comment #14
poker10 commentedI have tested this on a clean Drupal 7.101 and it does not seems to be an issue. Closing as Fixed for D8, so that credits are assigned correctly. Thanks!