About a security bug under IE - it can be used to track the user's system mouse position_javascript skills

DHTML under IE has various MS$ private features, which are already well known. One of the more interesting ones is: event.screenX and event.screenY, which can obtain the system-level mouse position coordinates.

When I first heard it, I actually thought it was nothing. The coordinates on the screen are nothing more than: coordinates in the browser client area, browser window coordinates, client area offset, nothing more.

IE itself can obtain various screen and window position-related information through event and screen objects.

However, the really weird things haven’t begun yet! According to the standard DOM model definition, can only obtain parameters related to the event from the event when an event is triggered.

In other words, only when mousemove is triggered and such mouseXXX mouse events are triggered, can the mouse-related parameters be obtained. However, Under the evil IE, event.screenX and event.screenY can be obtained after any event is triggered, even when the page is minimized!

Of course, you may say that this still needs to rely on an event. However, The event here can be any callback function such as onxxx, and is not limited to UI events. So, we can create it artificially!

The simplest example is to set an invalid src for a new Image, and its onerror event will be triggered immediately!

So we can get event.screenX in onerror, and then continue to set invalid src, so we can track the user's screen-level mouse pointer in real time. Because the generation of onerror is not limited to any UI message, the event can still be triggered when the page is minimized or inactive!

As for whether it is possible to obtain which key of the mouse or keyboard is pressed, unfortunately, it is really not possible. If you capture global keystrokes, wouldn't it be possible to monitor password input? . .

In fact, when non-UI events such as onerror are triggered, no mouse or keyboard parameters are passed into the browser form at all, so various mouse and keyboard information cannot be obtained. As for event.screenX, the only explanation is that it is a Getter of the event. The Win API GetCursorPos is directly called internally, and it is not the trigger of the event that provides this attribute.

Wouldn’t it be interesting if a page had such a tracking code embedded in it, and then the coordinates were sent back in real time through socket.io. . .