1341463 - DevTools Debugger Panel re-fetches JavaScript and can show fake source, frustrating debugging

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P5)

Description

[Jeff Dileo]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

a)
I wrote a web application that returns different responses depending on the Accept header supplied. This was intended to be used to return JavaScript payloads on / when loaded from a script tag via the src attribute, but load a proper HTML webpage when visited directly in a browser. I then wrote a page to load the application's / path in a script tag with DevTools open.

b)
I then modified the application to return "fake" JavaScript for non-JavaScript requests.
I currently have it up at https://1g.ht/ (https://1g.ht/js.html can load it for testing).


Actual results:

a)
The Debugger panel displayed the HTML version as if it was the source code for the loaded JavaScript. The actual script could not be debugged.

b)
The Debugger panel displayed the "fake" JavaScript code for the resource. Attempting to set a breakpoint would "work," but the actual code was the one that ran, regardless of the UI stepping through the "fake" code.


Expected results:

The JavaScript file that was actually loaded for the script tag should have been cached and reused within the DevTools. It should have been possible to properly set breakpoints to debug the actual code.

Note: Performing a "correct" request for the resource from the DevTools after the fact would still be observable to the server and likely subject to similar behavior if a fake file was returned for every other request to the resource.

Comment 1

[:Gijs (he/him)]

Can you explain why this is a security bug, rather than a correctness bug?

Jason, do you know why we re-fetch scripts in this case?

Comment 2

[Jeff Dileo]

The current behavior exposes the browser to an anti-debugging attack.
This is a security issue if one believes (as I do) that a browser should be able to analyze and debug 3rd-party JavaScript code (though not necessarily code that might actually exploit the browser itself).

It's also worth noting that I was told out-of-band (via :selenamarie) to submit this as a security bug.

Comment 3

[Jason Laster [:jlast]]

The debugger will show the source text that corresponds to a url that the browser received. If the browser is receiving "fake" javascript, it will be shown in the debugger.

Comment 4

[Jeff Dileo]

Jason, that is not how it currently behaves. The DevTools/debugger makes a separate request for the resource and it uses that in the UI, regardless of what the script tag actually loaded and ran.

Comment 5

[Daniel Veditz [:dveditz]]

This does not put our users or Firefox at risk directly. It certainly could frustrate analysis of malware so there's a security nexus, but that doesn't mean it needs to be hidden. It's akin to other steps malware authors take to frustrate analysis like minimized or more often "packed" scripts, or even stuff like the recently reported campaign that stored its payload hidden in bitmap images.

Comment 6

[:Harald Kirschner :digitarald]

We are requesting the file for the debugger, as seen in the profile: https://perfht.ml/2Emz0G4

Maybe this happens because it isn't cached, so the engine requests it again. View source works fine though, so the file should be available somewhere.

P5 as this might cause some side effects but not for many devs. We need to figure out a better caching strategy though so we stop requesting too many file in the Debugger.

Comment 7

[Logan Smyth [:loganfsmyth]]

With https://bugzilla.mozilla.org/show_bug.cgi?id=1643540 along with Brian's work for storing HTML as it is loaded in the parser, I think this is covered, as long as you already had devtools open already. If devtools was closed and you open it later, at present we have no way to know the specifics of the original request that was made, so we do a best-effort GET for the URL.