Juice-shop: [馃悰] Hacking instructor: DevTools open detection is CPU and RAM heavy and never stops

Created on 1 Dec 2020  路  12Comments  路  Source: bkimminich/juice-shop

:bug: Bug report

Description

When doing a challenge with Hacking Instructor which checks for the opening of the devtools (e.g. "view basket" challenge) I noticed that the devtools console was going crazy in a loop as my CPU 馃く
image

I understand that this comes from the code that waits for devtools:
https://github.com/bkimminich/juice-shop/blob/d29573a5d88209ecbe482b2b2140ded6f17d6b5b/frontend/src/hacking-instructor/helpers/helpers.ts#L128-L131
And this potential issue was mentioned: https://stackoverflow.com/questions/7798748/find-out-whether-chrome-console-is-open/48287643#comment110980766_48287643 馃

Moreover, this never stops even after completing the challenge! We have to refresh the page to stop the loop.

Is this a regression?

No

:microscope: Minimal Reproduction

  1. Go to scoreboard
  2. Launch "view basket" challenge
  3. Follow instructions until you are asked to open devtools
  4. Open the devtools and go to the console tab
  5. Notice the many "" elements being logged, which is normal as it's the way this hack works... (which is a nice trick anyway! 馃槄)
  6. Follow the remaining instructions, clear the console, see how it continues to fill up

:fire: Exception or Error

N/A

:deciduous_tree: Your Environment

N/A
Running latest code from develop branch as of now

Additional Information

Some suggestions:

  • Sleep longer between each check. Currently: 100ms but I think 500ms or even 1s might be reactive enough while reducing the load
  • At least stop it when the condition (devtools opened) is reached. I don't have enough mastery of async to suggest something sorry...
bug

All 12 comments

Does this properly detect if your dev tools are opened?
The check should鈩笍 stop once the dev tools have been opened :)

Edit: Tried it out, wow you're totally right, had to force quit my browser as it wasn't responding anymore 馃槵馃槄

Might be possible if I understand the detection method correctly to use a "more" light weight element then the image element for the logs. Light weight meaning a element with less properties

If the DevTools detection is only possible in a "whacky" way, then we can also drop it entirely as it was before. The tutorial would still be fine, it just made it feel more smooth when waiting for the DevTool to open. But it's by no means essential.

https://github.com/sindresorhus/devtools-detect

Seems pretty stable and easy to use

The current solution works fine and detects when I open the devtools but I confirm that it continues in the background (but I cannot say why because of my limited understanding of its implementation with a promise...)
It's a very nice thing to have (and I was actually very curious to see how it detected it!) so it would be nice to keep it! I think it could work good enough with a higher sleep time and by making sure it properly stops the loop

I've also found the devtools-detect that you mentioned @J12934, but I find its implementation to be more unreliable because it relies on checking the dimension of the display:

        const widthThreshold = window.outerWidth - window.innerWidth > threshold;
        const heightThreshold = window.outerHeight - window.innerHeight > threshold;

It also doesn't work if the devtools are opened in a second window...

Mh took another look,
For me, it's working correctly in chrome, meaning it properly detects open devtools and stops the logging immediately after the detection.
In Firefox it doesn't work at all, I have to click the Hacking Instructor to continue there. This also causes firefox to be really badly impacted by this check as it never stops.

It possible to really improve the performance costs by running console.clear() behind the console.dir call in the check. This ensures that the console never gets overwhelmed by printing all of those entires, as it always only prints the last one.

I re-checked and indeed I confused Firefox and Chrome (was using both at the moment...). And I agree with you @J12934:

For me, it's working correctly in chrome, meaning it properly detects open devtools and stops the logging immediately after the detection.
In Firefox it doesn't work at all, I have to click the Hacking Instructor to continue there. This also causes firefox to be really badly impacted by this check as it never stops.

I tried to add console.clear as you said and indeed it still does not work on Firefox, but it does not make it suffer too much anymore (CPU and memory are fine, but the loop continues though), and the detection still work properly on Chrome.

This issue has been automatically marked as stale because it has not had recent activity. :calendar: It will be _closed automatically_ in one week if no further activity occurs.

@J12934 @cnotin Do you guys think something needs to be done here still?

Did we update this?
Don't remember seeing / doing any changes to the actual code, aside from experimentations.

Yeah, me neither, but I wasn't entirely sure if your conclusion was to change anything or just leave it as it is... 馃榿

I think the co conclusion was that we can add a console.clear call to fix the performance problems on both chrome and Firefox, but the detection will still only work in chrome.

Only downside would be that this would clear all console history of the current tab. This should not really be an issue in my view.

Same conclusion here :)
Let's try with this, which is still a progress!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cnotin picture cnotin  路  5Comments

bkimminich picture bkimminich  路  8Comments

kingthorin picture kingthorin  路  4Comments

RezaRahmati picture RezaRahmati  路  4Comments

inkz picture inkz  路  4Comments