Bug #99631
open
HTML5: Overly Permissive Message Posting Policy
0%
Description
When doing a penetration test with Fortify at one of my clients we discovered a warning of level medium regarding the usage of postMessage in BE context.
Here´s the summary:
I could find usages in these places but don´t know exactly which one triggered the warningA broadcast of information to windows on the client-side using postMessage was observed. The postMessage function is one of the features of HTML5 that allows a window to send messages to another open window. The typical syntax of postMessage is window.postMessage(message, targetOrigin, [transfer]).
The message parameter contains the information to be shared and targetOrigin indicates the origin of the destination window. It is recommended to explicitly specify the targetOrigin intended for a particular message. While the function permits the use of a wildcard character, e.g. “*”, for the targetOrigin, allowing the message to be shared to any window, we strongly recommend avoiding this practice. If a malicious user injects a new window into the javascript’s execution context, then the new window will now be able to receive any information that is shared using the vulnerable postMessage construct. It is also important to validate any message that is received from another window to confirm that the sender was authorized to do so. This will avoid receiving unintended input from a malicious window.
Explanation
If the postMessage() is used to transmit sensitive information between windows, then an unauthorized window would be able to retrieve this information as well.
Execution
Inspect all messages that are transferred between windows to check the targetOrigin of the function calls. In this particular case, the given stack trace represents the execution of javascript that led to the discovery of the vulnerability.
Recommendation
All data that is shared between windows must have explicit origins to avoid eavesdropping. It is recommended to avoid using “*” for the targetOrigin in order to prevent a broadcast of the information.
- typo3/sysext/backend/Resources/Public/JavaScript/BroadcastService.js
- typo3/sysext/backend/Resources/Public/JavaScript/Utility/MessageUtility.js
- typo3/sysext/core/Resources/Public/JavaScript/Contrib/broadcastchannel-polyfill.js
- typo3/sysext/dashboard/Resources/Public/JavaScript/Contrib/muuri.js
- typo3/sysext/t3editor/Resources/Public/JavaScript/Contrib/codemirror/addon/tern/tern.js
Updated by Oliver Hader over 1 year ago
- Private changed from No to Yes
This sounds like a static code analysis only. In case there is a real exploit, please send the details via email to security@typo3.org (not to public issue trackers like this one).
I'm going to make this issue private, thus you still can reply, however it's not visible to the public anymore.
Updated by Oliver Hader over 1 year ago
Side-note postMessage really depends on the scope, see
- https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel/postMessage
- https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage
- https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage (Fortify just refers to this invocation)
Window.postMessage is only used in typo3/sysext/backend/Resources/Public/JavaScript/Utility/MessageUtility.js like this
windowObject.postMessage(message, MessageUtility.getOrigin());
(the 2nd option is
targetOrigin, which is scope-set and not *)
In case there are more details or a proof-of-concept exploit available, please report things back to us either via
Updated by Oliver Hader over 1 year ago
- Status changed from New to Needs Feedback
Updated by Robert Böttner over 1 year ago
Hi Oliver, thanks for looking into this.
Oliver Hader wrote in #note-1:
This sounds like a static code analysis only. In case there is a real exploit, please send the details via email to security@typo3.org (not to public issue trackers like this one).
As far as I have insight regarding the nature of the test, they did the testing via HTTPS only and I gave them only Frontend user credentials to perform test inside our application.
Oliver Hader wrote in #note-2:
In case there are more details or a proof-of-concept exploit available, please report things back to us either via
There will sure be further testing and I´ll try to get more information from the parties involved to report back here.
Thanks
Robert.
Updated by Markus Klein over 1 year ago
All of the mentioned JS files are backend related. So I'm not sure how the tests were conducted, if only FE access was provided
Updated by Robert Böttner over 1 year ago
Markus Klein wrote in #note-6:
All of the mentioned JS files are backend related. So I'm not sure how the tests were conducted, if only FE access was provided
Yes, that´s why I mentioned that they didn´t have backend credentials. The paths weren´t explicitly mentioned in the test report. Could it be that it´s used in the preflight when loading the login form?
As they state:
A broadcast of information to windows on the client-side using postMessage was observed.
They also reported request details:
GET / HTTP/1.1
Host: ******.de
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/8 8.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Pragma: no-cache
Referer: https://******.de/
Connection: Keep-Alive
X-Scan-Memo: Category="Audit.Attack";SID="0E60D69659FD5E13E08E890BCC6E2A61";PSID="F661F 4CAA08B2C5C75F3978AA8F2728F";SessionType="AuditAttack";CrawlType="None";AttackType="Non e";OriginatingEngineID="65cee7d3-561f-40dc-b5eb-c0b8c2383fcb";AttackSequence="0";Attack ParamDesc="";AttackParamIndex="0";AttackParamSubIndex="0";CheckId="3777";Engine="Reques t+Modify";SmartMode="4";tht="11";
X-RequestManager-Memo: stid="3253";stmi="0";sc="1";rid="151ebb61";
X-Request-Memo: rid="c3dec9f8";sc="1";thid="254";
Cookie: CustomCookie=WebInspect165276ZX391D79D335FA4401A3231A1255E181C0Y7708
Updated by Markus Klein over 1 year ago
So they only requested the start-page.
I rather assume some other JS on the page in the FE does this.