Gaston Rodriguez
eecd632be4
Automatic update from web-platform-tests Add rate limiting to pointer lock to prevent abuse A malicious or misbehaving page can rapidly lock and unlock the pointer in a tight loop, effectively denying users the ability to provide input. This tight loop may prevent the user from pressing the Esc key, for which we provide a "cooldown" before a lock can be re-acquired so that users may take control of the browser. Additionally, each lock request generates inter-process messages to the browser process, which accumulate even when the user switches to a different tab. This floods the browser with messages and bogs down input processing across the entire browser. This scenario is postulated in the spec as a possible security concern [1], and the spec implies that it is up to the User Agents to implement *some* mechanism with which they can protect the users: > Security concern: > Pointer Lock can be called repeated by script after user exits pointer > lock, blocking user from meaningful progress. > Answer: > Repeated escapes of pointer lock can signal user agent to not re-lock > the pointer without more specific user action, e.g. similar to how > Chrome suppresses repeated alert() calls. With this in mind, this CL implements a rate limiting system in PointerLockController that tracks recent successful locks. If a page exceeds a threshold of unlocks within a short time window, all subsequent pointer lock requests are rejected with a NotAllowedError until the window clears. The rate limiting is behind a feature flag (kRateLimitPointerLockRequests) which will be used as a kill switch in case some issue is found with the implementation. [1] https://w3c.github.io/pointerlock/#security Bug: 40056867 Change-Id: Ib504f26f5160fb784a220b30351855c5a74c517f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7533521 Reviewed-by: Mustaq Ahmed <mustaq@chromium.org> Commit-Queue: Gaston Rodriguez <gastonr@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1644052} -- wpt-commits: 4f6a1df9d653fd4577b82db6701c9ca1124bddc5 wpt-pr: 60483
57 lines
1.6 KiB
HTML
57 lines
1.6 KiB
HTML
<!doctype html>
|
|
<html>
|
|
<head>
|
|
<meta charset="utf-8" />
|
|
<title>User agent gracefully handles pointer lock request spam</title>
|
|
<link rel="help" href="https://w3c.github.io/pointerlock/" />
|
|
<style>
|
|
html {
|
|
font-family: sans-serif;
|
|
}
|
|
|
|
input {
|
|
width: 400px;
|
|
}
|
|
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<h1>Manual test for pointer lock spam handling</h1>
|
|
<p>This page will spam pointer lock requests and free them as soon as the lock
|
|
is acquired. Ideally, the User Agent would have some sort of mechanism to
|
|
prevent the webpage from being too obtrusive of the user experience.</p>
|
|
<p>The
|
|
<a href="https://w3c.github.io/pointerlock/#security">spec</a> states
|
|
that the U.A. can implement whatever mechanism it deems appropriate to
|
|
prevent abuse.
|
|
</p>
|
|
<p><strong>Press spacebar to toggle pointer lock requests on/off.</strong>
|
|
Status: <span id="status">Active</span></p>
|
|
<input id="inputElem" name="name" autofocus value="Interactivity test">
|
|
</body>
|
|
<script>
|
|
// Constantly spam pointer lock requests and release them as soon as they
|
|
// are acquired.
|
|
let spamActive = true;
|
|
const statusElem = document.getElementById('status');
|
|
|
|
setInterval(() => {
|
|
if (spamActive) {
|
|
document.body.requestPointerLock();
|
|
}
|
|
}, 0);
|
|
document.addEventListener('pointerlockchange', () => {
|
|
if (document.pointerLockElement != null) {
|
|
document.exitPointerLock();
|
|
}
|
|
});
|
|
document.addEventListener('keydown', (e) => {
|
|
if (e.code === 'Space') {
|
|
e.preventDefault();
|
|
spamActive = !spamActive;
|
|
statusElem.textContent = spamActive ? 'Active' : 'Stopped';
|
|
}
|
|
});
|
|
</script>
|
|
</html>
|