1582997 - Self-XSS attack by switching character encoding

Status: RESOLVED INCOMPLETE

(Firefox :: Untriaged, defect)

Description

[Tsubasa FUJII]

Attachment: 画面収録 2019-09-22 6.16.30.mov

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15

Steps to reproduce:

Displaying a specially crafted HTML document intentionally causes a character encoding mismatch.
An XSS attack is established when the user changes the character encoding to Unicode (UTF-8).

1. It leads to a malicious web page
2. Change the character encoding to Unicode (UTF-8)
3. XSS attack is established

Actual results:

Is this what is called Self-XSS?
I'm not sure, but Self-XSS countermeasures due to mismatched character encoding seem to have been taken, but this seems to be bypassed.
Similar results were obtained with Chrome and Safari.
In the case of vulnerabilities, we will send additional information, is this a bug?

Expected results:

Originally a character encoding mismatch document should invalidate character encoding changes.

Comment 1

[Tsubasa FUJII]

Attachment: Fix_ScreenCapture 2019-09-22 6.16.30 - HD 720p.mov

The media did not play and was re-encoded.

Comment 2

[Tsubasa FUJII]

Attachment: 1_スクリーンショット 2019-09-22 6.51.08.png

Comment 3

[Tsubasa FUJII]

Attachment: 2_スクリーンショット 2019-09-22 6.51.20.png

Comment 4

[Tsubasa FUJII]

Attachment: 3_スクリーンショット 2019-09-22 6.51.39.png

Comment 5

[Tsubasa FUJII]

Attachment: ScreenCapture 2019-09-22 6.16.30.mov.gif

Sorry for posting many times.
Watch this video as we converted .mov media to GIF Animation.

Comment 6

[:Gijs (he/him)]

Henri, am I right in thinking this is your wheelhouse?

Comment 7

[Tsubasa FUJII]

Attachment: xss.php

Publish Proof-of-Concept.
Although it is declared with shift_jis inside the document, it is actually a Unicode document.

This is a demo page.
https://threat.azurewebsites.net/Firefox/xss.php
When the character encoding is changed to Unicode(UTF-8), alert(document.cookie) is executed.

Comment 8

[Tsubasa FUJII]

A specific method is presented.
How to insert with QueryString.
https://threat.azurewebsites.net/Firefox/xss_q.php?q=%e3%81%82=0;alert(document.cookie)

I think this is Self-XSS because it is executed by myself.
However, it cannot be determined whether this phenomenon is a bug or not.
The trick uses JavaScript syntax errors.

Comment 9

[Henri Sivonen (:hsivonen)]

I think the key question here is: What would the actual attack scenario look like?

In this demo, the reason why JavaScript doesn't run as Shift_JIS is that a variable name ends up with a REPLACEMENT CHARACTER, which is not allowed in JavaScript variable names. So to show that this is an actual security bug, there'd need to be a plausible story for why a site served as Shift_JIS and accepting user-supplied content would allow a user to submit this kind of script but an otherwise identical site served as UTF-8 would not.

In this case, the script tags themselves are not masked, so I'd expect even a minimally-competent Shift_JIS site to block the user from injecting the script tags even if the bytes between them result in a JavaScript parse error and, therefore, don't run as Shift_JIS.

Reporter, can you describe a plausible attack scenario? Also, comment 0 says "Similar results were obtained with Chrome and Safari." How did you obtain the results with Chrome? I thought Chrome no longer had a user-visible encoding override.

Comment 10

[Daniel Veditz [:dveditz]]

We can reopen if we get more info from the reporter