User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36

Steps to reproduce:

Tested on Version 117.0 (64-bit) Windows 10.

Description

A vulnerability has been identified in how web pages embedded via iframes handle the Referer header. When a page A loads a page B within an iframe, the network request sent from page A to page B includes the Referer header with the value of the host of page A. However, when using the context menu to view the source code of the iframe containing page B, a request is sent to page B without the Referer header. This could allow an attacker to conceal malicious code when page A loads page B, and display seemingly harmless code when accessing the source code of page B through the context menu.

Watch the proof of concept video (poc.mp4) that demonstrates how a victim who views the source code of the seemingly harmless frame ends up executing malicious code hidden by the attacker.

Recommendations

• Developers are recommended to review how the Referer header is handled when loading content in iframes from different contexts.
• Ensure that the value of the Referer header is consistent in all requests, regardless of how the content is accessed.

Impact

An attacker could exploit this vulnerability to hide malicious code in visible content when page A loads page B, while seemingly harmless source code is displayed when accessing the iframe's source code through the context menu.

Steps to Reproduce

1. Set up the Ruby interpreter on your system and install the Sinatra gem.
2. Download the attached file named files.zip.
3. Choose a directory on your system and proceed to extract the contents of files.zip into it.
4. In a terminal emulator window on your system, start the server A's connection listener. This server loads an iframe. Use the following command: ruby parent.rb localhost 4444 5555.
5. In another terminal emulator window on your system, start the server B's connection listener using the following command: ruby child.rb localhost 5555 4444.
6. Open your web browser and access http://localhost:5555/.
7. Use the context menu to select This Frame/View Frame Source and observe the code of page B. This code does not pose a security risk.
8. Fill out the form fields, then press the login button and observe how the hidden malicious code is executed.

If I'm understanding this correctly, the user has already executed the malicious code by the time they do View Source, so even if View Source was working correctly it is already too late. There would have to be some kind of very specific scenario where the attacker is trying to convince the user that they ran some code instead of other code, and the user is sophisticated enough to understand view source in the first place. It sounds like undesired behavior, but I'm not sure if this rises to the level of a security bug. It is sort of like a spoof I guess.

Hi Andrew McCreight,

The posed problem refers to the situation in which a user accessing a website is unable to access the actual code of the iframe using the "This Frame/View Frame Source" contextual option. This indicates that the integrity of the information, in this case, the iframe's source code, has been tampered with malicious intent.

Best regards,
Stan.

This does not need to be hidden because this technique itself is not causing harm to users. Rather, it could be used for obfuscation and making detection difficult on a site that is doing shady stuff. This is not the only way View Source doesn't reflect the contents as shown to the user. These days, especially with dynamically generated infinite-scroll social media, the page "source" looks nothing like the current contents. People have long requested an option to view the dynamic source (e.g. bug 60426), and even created add-ons to address this issue such as https://addons.mozilla.org/en-US/firefox/addon/save-page-we/ NOTE: I know nothing about that add-on other than the description. As with any addon that doesn't have the "Recommended" badge, caveat emptor

Would duplicating all the headers such as the Referer: help? Malicious sites already do things like set a cookie on first load so the malicious content is never served more than once. We should try to pull the page out of the cache rather than reloading it. We'd have to come up with something for no-store pages though.

The Developer Tools views are generally better for inspection than historical "View Source" functionality.

(In reply to Daniel Veditz [:dveditz] from comment #3)

The Developer Tools views are generally better for inspection than historical "View Source" functionality.

As far as I can tell, Safari doesn't support the view-source scheme, and instead when opening clicking view source they open the developer tools.
If we decide to go a similar route, it might help with this. Related: View selection source opens the current source of the selected HTML via a data URL.

The severity field is not set for this bug.
:Honza, could you have a look please?

For more information, please visit BugBot documentation.