[Bug] skillcheck minigame exploitable

[fivemsmostwanted]

Describe the bug
The minigame skillcheck can be bypassed by intercepting the fetch request. This allows users to send a modified boolean value (true) for the skillcheck, ensuring they always pass without interacting with the UI. (tested on the latest version)

To Reproduce

1. Open the NUI with browser developer tools.
2. Override the window.fetch function in the console.
3. Modify the fetch request body for the skillcheck to always send "true".
4. Trigger a key event for the skillcheck, and it will always pass.

Expected behavior
The skillcheck will always be validated without a single input

Video:
https://streamable.com/z286iv

[BerkieBb]

How should the skillcheck be validated with input?

[Hackuou]

The only way to prevent abuse would be to check input through client resource scripts, not NUI.
The new IsRawKeyDown/IsRawKeyPressed natives could be used for this without having to create key mappings (like you would have had to do in the past).

[BerkieBb]

And how exactly would you validate this with NUI? Considering that the minigame itself is made and controlled by NUI.

[Hackuou]

Generate the position (and key) on the client script, send that to the NUI so it can create the minigame and then let the client handle the correct input timing. The NUI would only need to generate the minigame based on the provided key and position information.

The correct timing could presumably be handled on the client still as NUI messages should be mostly instantaneous so there shouldn't be many syncing issues.

Making sure the key is pressed at the correct time would just be a simple timer based on how fast the minigame is and where the correct position is. If they key is pressed in the valid timeframe then they completed the minigame successfully.

[BerkieBb]

NUI isn't exactly as fast as you think it is. It takes several ms for an NUI message to be sent and NUI can hitch whilst the game continues. Not a reliable solution you got there.

[Hackuou]

Sending the NUI message through JS seems to lower the message delivery time to close to 1-2ms on average from some short testing. Which I'm sure that could increase when NUI starts to slowdown (but I would argue that should only happen if people have poorly optimized UIs running).

There's another exploit/bug with the current system (which is basically the same as the one mentioned originally) where one could seemingly keep the skill check active till they decide to complete it by hooking into and preventing the failure request being sent back to the script. And then only sending the completion request when they so wish, since there's no timeout or anything without the invoker implementing one themselves.
This could actually further cause issues with other scripts not sending skill checks because another is already open (if the scripts have implemented such a check).

(I'm sure you could technically create the UI (mostly) through native methods too if you really wanted. Small style changes would be fairly easy for users to make but major or "advanced" changes would be a little harder than they are now most likely. I don't think this is a good idea myself but I don't see anything that would actually prevent it).

Plus, shouldn't NUI only really hitch when poorly optimized UIs are active anyways? And wouldn't NUI hitches/"stutters" also cause some issues for the user trying to time the skill check with the current NUI implementation, if the slowdown is consistent then sure but if it starts to fluctuate it would be a little confusing?
Since there's no way to check NUI performance and therefore no way to mitigate those hitches I can understand that still being a concern though.

My proposed solution isn't perfect but the current system seems far too easy to exploit, with no real way to fix it in its current implementation. I understand your reasons and concerns of not wanting to change the way it works but just thought I'd give my opinion and suggestions.

[jag3dagster]

You're welcome to take some time and write up your proposed solution as a pull request and provide validation testing / results for the team to review.

[Hackuou]

Will do if I can find time. 👍

[juddisjudd]

Closing this issue due to inactivity and lack of recent updates. The proposed solutions and discussions provided valuable insights, but without further progress or a pull request, we're considering this issue stale.

If you're still interested in addressing this vulnerability, please feel free to reopen or create a new issue with updated information and proposed solutions.