Is it possible use the WebSocket API of JavaScript, to communicate with a native application, on the client side, like an alternative to an applet, which have to access to the file system?
I will communicate with the client side by ws://localhost:xxxx, but I don't know if I could do it.
And If I could, this will be secure. Will I have to take some security considerations?
No, you can not install a WebSocket server on a user's machine to replace the functionality of accessing the local filesystem in the same way that Java applets would.
Not without the user actively installing the WebSocket server on their own machine intentionally.
Your biggest problem is that the Javascript client code does not have unrestricted access to the user's filesystem. This is a security feature. This is an important security feature. You can not place arbitrary files on the user's machine in arbitrary places.
After that, Javascript client code also can not start processes on your system, even if it could get a WebSocket server installed in an arbitrary location. Again, this is a critical security feature.
And finally, if your Javascript client code could install and execute arbitrary software on the user's machine, you wouldn't need a WebSocket server for the use case you're looking for right now.
If you were to convince a user to install a WebSocket server on their own machine for your use case, which is to access the user's local filesystem, then you would have major security concerns to take into consideration. Not all filesystems have user and group based read/write/execute permissions... and even then, the user might start the server from within a privileged account.
The browser is designed to implicitly trust the server that it's attached to as far as whatever Javascript it receives. If your user later browses a malicious site which knows about your locally installed WebSocket server, and what commands it might expect, the browser will quite happily allow the malicious server to send any commands to your user's WebSocket server that they wish.
With my strong personal recommendation to respect the sanctity of the user's filesystem and obey the restrictions that browsers place on Javascript clients access to the local machine, if you do decide to try to convince your users to install a local WebSocket server, you must take absolute care to be as security conscious as possible. Validate *all* input, regardless of whether you think an attacker can't possibly generate it, and never blacklist known risks, ONLY whitelist known safe functions.
Remember, if you do anything to expose the user's filesystem to the web, you are pretty much handing the keys to their computer over to anyone who can find the door.
Related
I have a logic written on my server mostly doing curl requests (e.g. accessing social networks). though, some of the sites, will be blocking my server(s) IPs soon.
I can of course, use VPN or deploy multiple servers per location, but it won't get accurate, and still some of the networks might get block the user account.
I am trying to find creative solution to run it from the user browser (it is ok to ask for his permission, as it is an action he is explicitly trying to execute) Though I am trying to avoid extra installations (e.g. downloadable plugins\extension or a desktop app)
Is there a way to turn the client browser into a server-proxy, to run those curl-calls from his machine instead of sending it from my own server? (e.g. using web-sockets, polling, etc.)
It depends on exactly what sort of curl requests you are making. In theory, you could simulate these using an XMLHttpRequest. However, for security reasons these are generally not allowed to access resources hosted on a different site. (Imagine the sort of issues it could cause for instance if visiting any website could cause your browser to start making requests to Facebook to send messages on your behalf.) Basically it will depend on the Cross-origin request policy of the social networks that you are querying. If the requests being sent are intended to be publicly available without authentication then it is possible that your system will work, otherwise it will probably be blocked.
My project has a WebSocket server built in Node.js using socket.io.
Reviewing the causes of a recent outage, I found that the front-end app gets into a state where it keeps making malformed connection attempts which the server rejects. It does so in a loop with no back-off.
What ends up happening on this server is that the single Node.js CPU thread ends up getting clogged up with the backlog and it creates a cascading effect -- no new request can be made, no other processing can happen, and so on.
The easy way to fix this is on the client -- figure out why it goes into the rapid-fire loop and add some exponential back-off.
However, this doesn't solve the problem of a similar issue happening in the future. So, I need to find a way to make my server more resilient.
One approach could be to use the backlog parameter when calling server.listen. That, however, could prevent legitimate client requests from going through.
I'd love to be able to somehow identify an out of control client in some way. IP address might not work well because of NAT, proxies, and firewalls.
So, what would be a good way of protecting my server from this type of DoS?
The ideal place to intercept a DoS attack is BEFORE the connection gets to your application server. That would typically be in a router, firewall or load balancer and you'd rely on the means that it has for rate limiting from a particular source. If you are paying for a hosting service, this should be one of the features the hosting service has to offer as many of the larger or more visible tenants will want that type of service.
From an accidentally misbehaved browser (like you describe in your question), you can cookie a request that has been denied and then rate limit any client that presents that cookie (limit them to no more than N connection requests/minute).
You cannot rely on a cookie for an actual purposeful DoS attack since attackers probably won't preserve cookies if it interferes with their attack. For that, all any infrastructure can do is to look for identifying information in the source (which is typically the IP address). If you accidentally sweep up a few legitimate clients who happen to be sharing the same NAT or proxy (and thus get identified as the same IP address as where a DoS attack is coming from), then that's just the nature of the problem. There isn't much you can do about that. You have to protect the integrity of the service at all cost and there really isn't much else you can do if cookies aren't being preserved by a real attacker.
If you choose to try to implement this type of protection yourself, then you can either try implementing it in your application server (and accept some performance hit for doing so) or you can deploy an intermediary on your same host such as NGINX to serve as mitigation for DoS attacks. Here's an article on using NGINX for that: Mitigating DDoS Attacks with NGINX and NGINX Plus.
I do not have the privileged nor the permission to ask for a server in my workplace thus I was thinking of developing a local web application on my computer and utilizing a common space folder to let everyone access my web based tool.
How can I use a client to entirely develop a web application, query database, and do all the things that you'd generally do using a server?
I don't think you can accomplish what you're talking about through a browser app alone. Modern browsers have local database storage, but without a server you simply can't have central data that everyone can access.
Why not set up a local server on your own machine? Node.js servers are very easy to set up and perfect for simple use cases. Your coworkers could access the app via your IP address anytime it is running and your computer is on the network.
For more specific information please ask a more targeted question; this question is too open-ended to have a clear answer.
Is it feasible to make access from particular environments, such as countries, operating systems, and browsers denied in Node.js and Express? I'm now constructing a web service, but must implement such filters before launching it for some reasons.
I use Node.js v0.10, Express v3.x, and would deploy on heroku. So here's my question:
Is it feasible to implement such filters in my deploy environment, and if it is, how can I do?
Is it feasible to implement such filters only on some specific services, such as comment sections?
I also wonder how secure and robust it can be to have access from those countries denied successfully.
(This is not a heroku question, and in my humble opinion not a node nor javascript question well. This is more likely an http and/or tcp question).
You can filter by these, but beware: it is not secure at all.
Detecting the user's country is usually done by ip (which you can get with req.ip) which is later converted to a location (with some ip/geo service, e.g. MaxMind).
Detecting the browser is done with the User-Agent http header. This is accessible with req.headers['user-agent'].
Detecting the OS is also done by parsing the user-agent header. There are other ways of doing this (passive os fingerprinting -- http://lcamtuf.coredump.cx/p0f3/) but these are probably not deploying on Heroku.
Note that in order to avoid filtering by country, the user can simply access your web server using a proxy in an allowed country. Also, since user-agent is a string the client sends, they can send whatever they want and fake any browser/os.
It really depends on how strict your "filtering security" requirements are.
Recently received a request to add communication to a device connected via serialport on the client's machine through my webpage.
I'd done some googling and found that node.js with node-serialport seems to be the javascript way of doing it. However, in my case, the device is actually connected to the client's machine, and not the server.
My question would be how do i implement node.js in this sense? Since the code is run at the client browser, is it possible for me to 'embed' node.js on my webpage?
Or is there any other alternative for doing this? Applet and ActiveX are out of the picture though.
Thanks
UPDATES:
Had managed to convince the client to have applet loaded from the web, so we'll be going through the applet route. Thanks all for your great info! =)
JavaScript in the browser only has access to the APIs provided by the browser: it lives in the browser sandbox where it (rightly) has no access to the client file system or other hardware.
This is different from node.js, which is a server implementation that has access to all sorts of other file system APIs.
To "break out" of the browser you must use some sort of browser extension.
You will have to create a plugin, an applet, or a client side application to get the data into the client's web browser before being sent off to your server.
You could make a small app that reads the serial port of the clients machine that creates a .js file, and then your web page includes that src of that "dynamically" created js file on the client's machine and presto your webpage gets access to the serial port in a roundabout way.
This is how GPSGate works: http://gpsgate.com/developer/gps_in_browser/
See also here: How to read from Serial port in a webpage
And a java applet based solution:
http://code.google.com/p/java-simple-serial-connector/
http://code.google.com/p/java-simple-serial-connector/wiki/jSSC_Terminal
Try app.js if you want to access node.js functions from browser.
This can only be done via Active X or a plugin like Java or Flash. Code in JavaScript is only as powerful as the APIs provided to it from the browser.
Want to sent an HTTP request to a server? JavaScript can do that (subject to the same-origin policy), because the browser has the XMLHttpRequest API. Want to query what processes are running on the operating system right now? JavaScript cannot do that, because no browser provides an API for querying the OS about what processes it is running.
No browser that I know of implements any kind of JavaScript API for performing serial port operations, so there is no way to do it without using a plugin.
However, this does not preclude the possibility of such an API existing someday: the getUserMedia function can grab data from a camera or microphone, and it could theoretically be expanded to get data from other devices as well.
Another option (other than ActiveX or Java applet with security permissions) might be Google Native Client and the Pepper API, though whether this would be sufficient to access a serial port, I do not know.
A Firefox extension can include a native XPCOM component that could access the serial port, and you might find there is already a way to access the serial port from browser chrome (which extensions are) because the security token and smartcard system supports serial readers. A Firefox extension could also be used to deliver the next solution, which requires placing a native component or application on the system.
Can you tell us what browser(s) and OS('s) are targetted here, and why ActiveX and Java are ruled out?
Others have suggested a native running proxy exposing the serial port through some protocol. You could use node for this, or python, or any other language that can create both a serial connection and a socket. To access the proxy from a browser application you would need special security permissions to be granted to the page, and then you can make your proxy an HTTP or WebSocket server. You can also serve javascript from the proxy which would grant the script HTTP and WebSocket access to it's origin server which is the proxy. Google Chrome extensions can access any destination and port with their socket client. Also, I believe a config can be set in Google Chrome to allow this for certain or every page, the same with allowing native client to be used by a webpage.
Without knowing more about your goal, I can't determine what the best solution would be.
Another option to read the serial port data is using sockjs and sockjs-client-node at the server side and sockjs-0.3.js at the client side.