You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for reporting it! As discussed on Twitter, the JavaScript injection in the extension takes about 15-20ms, which is too much for an inline script at the top of a document :(
For readers, no worries, it doesn't impact an inline script in the middle of the document (e.g., https://mizu.re/) or a script loaded via src.
I'm currently working on a fix, but it's super hard because I'm dependent on how browser extensions work. If anyone has an idea on how to fix this, please do not hesitate to propose :D
I was thinking about how to properly fix this issue, but I haven't found a clean solution yet. The fact that the extension script gets overridden by the page loading isn't something I can address at the extension level.
However, an interesting point is that scripts loaded by the DOM and scripts loaded by the extension aren't in the same queue. This means that a potential solution could be to replace with <script src="XXXX"></script> on all the in-scope response documents.
For example:
Expose a server that returns an empty no-cache response (this is really important to force the browser to fetch it every time). In PHP, this can be done like this:
On Burp, set up a match-and-replace rule that loads the associated script (make sure not to use your own file to avoid leaking sensitive information to your server!):
Go to the page, and it should work properly now :)
Not sure why, but when testing https://public-firing-range.appspot.com/address/index.html with DomLogger++ and using Dom Invader config, it doesn't detect the common sinks when the source is location.hash
The text was updated successfully, but these errors were encountered: