Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XSS via exiftag #598

Closed
hannob opened this issue Mar 7, 2019 · 8 comments
Closed

XSS via exiftag #598

hannob opened this issue Mar 7, 2019 · 8 comments

Comments

@hannob
Copy link
Contributor

hannob commented Mar 7, 2019

The attached file contains an XSS payload as the camera model EXIF tag.

Uploading it to s9y and looking at the details of the file will execute. The exif tag printing should be escaped. (While this is only self-xss, there are situations where this could still be exploited, imagine someone sending a photo to someone else for a blogpost.)

xss

@onli onli added this to the Minor milestone Mar 7, 2019
@hannob
Copy link
Contributor Author

hannob commented Mar 8, 2019

forgot attachment
xss

@onli
Copy link
Member

onli commented Mar 8, 2019

I imagined seeing an attachement in the email? Thanks!

Is the EXIF tag also not escaped when seeing the details after upload, in the media library?

@hannob
Copy link
Contributor Author

hannob commented Mar 9, 2019

It is as far as I can see only in the details (i.e. after clicking the button with the tooltip "Media Properties").

@onli
Copy link
Member

onli commented Mar 18, 2019

Confirmed. I pushed a first fix now. With the array construction that code is a bit convoluted, do you still see a way to exploit this?

The media properties above seem like an equivalent attack vector, but they should not be read directly from the image, unlike the EXIF tags.

@hannob
Copy link
Contributor Author

hannob commented Mar 19, 2019

Seems fixed, though I see a somewhat obscure other issue:
If I add an XSS vector into the above media properties it does get escaped in this place, but if I add the image to a blogpost then it gets added unescaped into the blogpost.

Not sure if there's any risk, it would require something like a multi-editor blog where one editor is not allowed to inject html into a blogpost, but can edit image properties (not even sure if that's possible). But probably better to fix that as well. (In general I wonder how much protection s9y provides in multiuser settings and if this has even been considered before.)

@onli
Copy link
Member

onli commented Mar 19, 2019

where one editor is not allowed to inject html into a blogpost, but can edit image properties (not even sure if that's possible).

I admit to also not knowing this. The right management of s9y I never had to deal with.

But probably better to fix that as well.

Yeah. Which image property is the problem here?

(In general I wonder how much protection s9y provides in multiuser settings and if this has even been considered before.)

I know that we already had the situation that we fixed similar bugs, so I think it's okay to tackle it. But there is of course a limit on how much security we can provide here.

@hannob
Copy link
Contributor Author

hannob commented Mar 20, 2019

The "Short Comment" field is added as a "Comment". In the dialog to add the image it's escaped, but then it ends up unescaped within the blogpost itself.

@onli
Copy link
Member

onli commented Apr 27, 2019

Fixed. Thanks!

@onli onli closed this as completed Apr 27, 2019
th-h pushed a commit to th-h/Serendipity that referenced this issue Apr 28, 2019
Backported from master branch.

Signed-off-by: Thomas Hochstein <thh@inter.net>
th-h pushed a commit to th-h/Serendipity that referenced this issue Apr 28, 2019
Backported from master branch.

Signed-off-by: Thomas Hochstein <thh@inter.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants