EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: peter-h on August 09, 2023, 05:58:23 am
-
This is a very simple question which doesn't seem to have a simple answer - other that you "cannot" do it unless you have client-side javascript which picks up the keystrokes and sends some sort of legitimate HTML "page requests" to the server.
So e.g. you package the keystroke into a short PUT or GET and a little URL and the server has to implement that URL as a valid web page, and it will pick the keystroke out of that. It possibly doesn't actually need to serve a page, but it might need to send some minimal page to stop the client timing-out.
Is this really right?
I already have JS code for file uploads and such, including for checking there is enough space on the filesystem. It is a simple web server which I wrote. It doesn't support anything complicated.
The application is to be able to accept PGUP/PGDO keys for altering the output of a DAC.
In short, I believe a browser never passes on keyboard activity, which remains local and can be used for e.g. input into an Edit box. I have those working too, but it is a lot of code.
-
You are essentially correct about picking up the keystrokes and sending them via HTTP request. You can also have a javascript that periodically looks at the text input area and sends over what is presently in the text box instead of a single character at a time.
These methods are used all over the web. Keystrokes (and even mouse movement) on a website don't necessarily stay local to the machine/browser.
The server just needs to send back some sort of acknowledgement that the javascript likes. Sometimes just a simple status 200 is fine with no body.
-
I'm not a web dev but found this yesterday that doesn't use java script https://odysee.com/@BrodieRobertson:5/the-worst-chat-application-ever:c
-
I understand that you may have a legitimate use for this in your project, but the idea of a bare web browser, without JS enabled, being able to send direct keystrokes to a remote server doesn't look too appealing to me from a security POV.
-
Yeah the only way to do this is with JavaScript. There are tons of examples out there, for instance JavaScript terminal emulators that let you interact with a remote shell via a browser window.
Registering the event handlers and sending a request shouldn't be that hard although it's been ages since I tried, but it's the sort of thing where you keep having one more feature or bug fix and soon you have invented Yet Another Horrible Web Framework. I dont know whether having a limited embedded web server will force you to make something small and simple or just make it intractable to get a tolerable user experience.
-
websockets instead of HTTP might be more suitable for your application.
For instance, this page looks interesting:
https://realtimelogic.com/products/sharkssl/minnow-server/
-
Yeah the only way to do this is with JavaScript.
OK; I already use JS (paid some people on freelancer.com to write it) extensively, for stuff like file transfers. Even implemented HTTP "pages" for checking there is enough space beforehand.
And I can do this PGUP/PGDO and even have a text box for the DAC output but I just wondered if there is some quick and dirty shortcut.
I understand that you may have a legitimate use for this in your project, but the idea of a bare web browser, without JS enabled, being able to send direct keystrokes to a remote server doesn't look too appealing to me from a security POV.
For sure, but this is just for local config and diagnostics. Yeah, somebody can put it on an open port but I tell them in the RM to not do that :) The right way to do remote access is with a VPN onto the local network, and my HTTP server even implements client IP filtering so you put your VPN terminator IP in there if you want to. I wrote the whole thing using the netconn API of LWIP - posted about it before. I started using the messy HTTPD module which comes with LWIP and it was too horrible.
Another topic, but nobody should be putting any embedded boxes on open ports, and I document that too ;)
Thank you all.
-
For sure, but this is just for local config and diagnostics. Yeah, somebody can put it on an open port but I tell them in the RM to not do that :) The right way to do remote access is with a VPN onto the local network, and my HTTP server even implements client IP filtering so you put your VPN terminator IP in there if you want to. I wrote the whole thing using the netconn API of LWIP - posted about it before. I started using the messy HTTPD module which comes with LWIP and it was too horrible.
I believe SiliconWizard meant the presence of such a function in a browser, not your particular use of it. A document, which could intercept and send keyboard events, would be a privacy and security nightmare.
As for implementation details, it’s worth remembering to not roll your own crypto, but rely on existing, tested features or you may join Tencent and their virtual keyboard (https://citizenlab.ca/2023/08/vulnerabilities-in-sogou-keyboard-encryption/). ;)
-
OK. No doubt that is why this is not present in browsers. OTOH if an attacker can acquire control of a server (or spoof the DNS and screw up the client's root cert store) then all bets are off anyway.
It is difficult to encrypt keystrokes. You obviously have to use block chaining otherwise every "A" will produce the same block, etc. But to do it properly you need constant (random) data.
I have TLS in this project but didn't use it because
- it is pointless for the job
- the cert has to be self-signed so the browser will complain anyway and dumb users get nervous when they see that
- TLS grabs 48k RAM in my case, leaving very little, so I want to keep its use really properly optional
- the API is a lot more complex compared to using LWIP's API directly