About a security bug under IE--the ability to track the user's system mouse position _javascript tips

It is well known that DHTML under IE has a variety of ms$ private features. One of the more interesting is that Event.screenx and Event.screeny can get the system-level mouse position coordinates.

I listen, actually also feel nothing. The coordinates on the screen are nothing more than: the coordinates of the client area of the browser + the coordinates of the browser window and the customer area offset.

IE itself can get information about various screen and form locations through the event and screens objects.

However, the real weird thing hasn't started yet! As defined by the standard DOM model, the parameters associated with the event can be obtained from event only when an event is triggered.

In other words, only the trigger MouseMove, such as such mousexxx mouse events, you have access to mouse-related parameters. However, in the evil of IE, any event triggered, can get Event.screenx and event.screeny, even when the page is minimized!

Of course, you might say that it still needs to be dependent on an event. However, the events here can be arbitrary onxxx such callback functions, not confined to UI events. So, we can make it artificially!

The simplest example is to set an invalid src for a new image, and its onerror event immediately triggers!

So we can get the Event.screenx in the onerror, then continue to set the invalid SRC, so we can track the user screen level of the mouse pointer in real time. Because the generation of onerror is not limited to any UI messages, the event can still be triggered when the page is minimized or inactive!

As for whether to get the mouse or keyboard which key is pressed, unfortunately, really can not. If you capture the global button, you can not listen to the password input ...

In fact, the onerror of such non-UI events does not have any mouse or keyboard parameters passed in to the browser form, so it is not possible to obtain various mouse keyboard information. As for Event.screenx, the only explanation is that it is an getter of the event, which directly calls the GetCursorPos win API, not the trigger for the event.

Wouldn't it be fun if a page was implanted with such a tracking code and then sent it back in real time via Socket.io?