A server that sends info (in this case temperature data, every second) through a socket connection which can be listened to.
The goal being to display temperature and dynamically update the value on a webpage, with javascript.
The server cannot be modified.
JavaScript can not open arbitrary TCP connections, as that would allow for all kinds of mayhem when combined with services who authenticate based on IP address, or not at all (and are only protected by firewalls). This includes Windows or NFS file shares, your average printer, your average LAN game, your average home router's web interface and lots of enterprise software.
You you cannot really prevent the browser from visiting a malicious site (since that includes visiting a trusted site with malicious ads). If these sites could effect arbitrary TCP connections, they could for example try out every IP address in the RFC 1918 private address ranges, or every IP address in the address range of the organization the client is coming from, and determine what devices you own. That alone would constitute a serious privacy breach, but imagine a malware site finding a printer and then printing out spam in your office once you visit it by accident.
What you can do is use a WebSocket server to translate native TCP to WebSockets. Most Websocket implementations will have such a server as a demonstration app, but you can also use a standalone proxy.
What you need to do is make the connection with PHP, or something else server side, and return the result via AJAX to your JavaScript.
Related
I have a public web API for a SaaS. We do not have user accounts for the users except for the admin, simply because the users who are using the system are often non-permanent workers or staff.
Instead we have a client/customer number and a PIN which is used to authenticate and setup the browser client. The authenticated JWT is stored in the browser like any other access token and is sent back to the server together with every API request. This works fine, although we do understand that a malicious actor could potentially extract this JWT and use it to illicitly authenticate as well.
Now we want to add two extra layers of security: IP whitelist and trusted devices.
First we have introduced an IP whitelist. This is straight-forward, we simply check the remote IP against a whitelist created by the admin which is bound to the client number.
Now the problem is with the trusted list of devices. For each client number, there should be a way to trust a device for that specific client number. So the client/customer should be able to use the web API only on the devices it has in the office. The ideal scenario would be that the admin can issue a "trusted device" certificate with a digital signature which sign something like "client number+year+client pin". Then the local manager individual needs to import this certificate/secret manually on the device that should be trusted.
Then for each request our web client app (via javascript) also sends this signature with each request in a HTTP header. I understand this could potentially be spoofed as well but together with the IP whitelist we assess and believe it should be secure enough for this application.
The problem is now, how to implement that? As far as I understand:
I cannot store such a secret in the browser because it might be cleared.
I cannot read the filesystem with javascript. Store the secret in a text file?
I cannot access the device certificate store.
How can I manage (import, store and read from javascript) this digital signature/certificate/secret in the client device? The web client can be anything from a iPad and Android phone to a Windows, Linux, iOS desktop. All web calls are done with SSL. We are not running any native app on the client device, only browser.
Recently i've been choosen as backend lider for course on my studies. We are suppossed to write BE for chat app that will allow users to communicate p2p without any server code (i know it means that there's no BE, but my proffessor isn't technical person). I've asked him if it could use webrtc, but he didn't like the idea of using STUN and TURN servers. So my main question is, is this possible at all? We are talking about an app that will run in browser, not directly in OS. And if it is, what protocols/apis can we use to achieve that?
I am not sure if I get your question right, so here are some general informations:
WebRTC as a P2P API relies heavily on servers.
"ICE":
To connect one Peer to the other Peer, the peers need to know their IP address to exchange data. They can "ask" their OS for the registered IP, but this will only yield 127.0.0.1 and their local Network IP. This works for connections on the same computer or between computers in the same local network, but it will fail for everything else.
The ICE Servers STUN and TURN are necessary, since your browser clients are behind your Routers Network Address Translation (NAT). STUN gets the NATs IP Address and Port and TURN forwards Packets as a known, public IP Address if STUN fails.
"Signaling":
Let's assume, that your Peers know their own reachable IP-Addresses (- probably the NATs IP and Port by using STUN and maybe even TURN). Even IF (!) they know their reachable IP, they have to tell the other Peer that this IP is in fact, their IP and the IP to use to contact them. They also have to tell the other Peer some other technical information to make the transmission of data work. To use WebRTC, you need to have a WebSocket-Server (or a combination of Server-Sent-Events and HTTP Post Messages), which forward this information.
After everything is established (they know their respective IPs and Ports, technical information, etc.), you can then send data over WebRTCs DataChannels.
My Advice:
Do not use WebRTC for the given use case. If you do not want to use a Backend-Server, you have to search for "serverless" Web-Apps. P2P will always rely on some sort of server to start the connection. If you use a "serverless" architecture, someone else is hosting the server / chat service you want to use (also commonly referred as "cloud based"). If it is about hosting costs for a prototype app, you may have a look at heroku.com, aws.amazon.com, zeit.co, firebase.google.com or other hosting providers with free, limited (test) plans.
So a website of mine is hosted on godaddy, now I want to connect it with a server that is running socket.io, and I have some balance on digitalocean. However, I am not sure how I would do this, I think it should be like this for client side?
var socket = io.connect('http://Digital.ocean.ip.here:port');
and then server side like this
http.listen(port, function(){
console.log('listening on *:port');
});
the only thing is that if this is how I am supposed to do it (and it even is possible if it's not the localhost), than users will be able to see the ip of my droplet when they take a look in the source code, and perhaps DDOS it or maybe worse I don't know?
When I see other sites using socket.io for a chat for instance, I never see their IP. Does that mean they host their entire website on a service provider where they are able to use socket.io/node.js?
Any answer will be highly appreciated!
--Edit--
My client wouldn't accept http and therefore I decided to buy a domain and ssl so it would use https.
There's no way to every hide the IP address of a server that a browser connects to. It makes no difference whether the connection to the server is http or socket.io or any other TCP based connection. Anyone can see the IP address. So, that simply isn't something you can protect or should worry about.
In most cases, code will use a DNS host name (not an IP address), but the DNS service itself provides a way to lookup the IP address for a host name so the IP address can be fetched that way. Or, one can just load a debugger or local network snooper and easily see what IP address is being connected to. A host's IP address is simply not a secret.
If you are worried about DDOS, then you will have to implement server-side protection from those types of attacks. You can't do anything in the client to protect from those kinds of attacks.
I'm using an arduino UNO and an Ethernet Shield to create a web server to response HTTP requests.
The requests are sent by ajax XMLHttpRequest.
It's working fine with static ip address.
But a want the arduindo to get a DHCP ip, so I can use it in any local network (with DHCP).
I want to discover the ip of the arduino connected on the local network.
So I can use it as url to send HTTP requests.
Is it possible to do that in javascript?
OK, thanks for answering my questions above. That helped layout the network structure and the problem you're trying to solve.
Summary of the problem
Two computers: 1 web server whose address is dynamic (DHCP) and 1 web client running AJAX and HTML. How can browser find DHCP server?
Options
This is a classic problem solved many different ways throughout the history of computer networks. I've suggested some options below.
Scan for the server via TCP.
Scan for the server via UDP (requires special browser library).
Run a DNS server.
Have Arduino signal its IP.
Modify your router.
Don't run DHCP - use a static IP.
tl;dr - Use Option 6 if you don't control your router, Option 5 if you do.
Option: Scan for the server
I'm assuming you know your browser machine's IP address (for example, 192.168.1.17). In this case, run through all of the address from 192.168.1.0 through 192.168.1.254 (not .255 and skip you browser machine's IP) testing for a connection to port 80. This will find every web server on your subnet, so be aware you will need a way to recognize your arduino responded to the web request in case some other web server is also listening on the network. It will also take some time to set up, test and wait for timeouts on most (252) of the addresses which don't have web servers. You will eventually find it.
I'm not a fan of this one, but it gets the job done. Warning: if you don't "own" the network, someone may be angry with you for scanning their machines. A company, school or other institution may have policies about not scanning networks.
Option: UDP from the browser
This one is great, but requires a browser plug-in and some fancy coding. UDP allows one to broadcast a message to your subnet (try ping 255.255.255.255 at a command line and watch the machines echo back their IPs). If the arduino is set to listen for UDP packets on a particular port, it can echo back to the sender of the UDP packet and let that user know it's present. This is how DNS, DHCP, ping and Apple's Bonjour work. Many IP based systems advertise services by responding to UDP requests. Clients need not know the address of the servers on the subnet, they discover them through broadcast messages on well-known UDP ports.
Unfortunately, this requires a browser modification because Javascript does not support UDP for security reasons. I understand this and agree with the security restriction. However, it has cut out a really nice feature of dynamic service discovery. If you're on Apple on the browser, you might be able to find a Bonjour emulator you can run on the Arduino and it might work ("arduino.local" might attach). This might be possible with Windows service discovery, too, if you're using a Windows client for your browser. I don't know what's available in Linux for service discovery.
I don't like any of these modifications for you. Browser, Arduino (Apple, Windows or Linux), just because it adds more moving parts and you're counting on the browser to "know" how to find the service.
Option: Run a DNS server
This isn't as bad as it sounds, but I'm not sure the Arduino could handle it. Find a very small DNS server written for the Arduino and have it respond to DNS requests. On the browser, look for a well-known machine name (e.g. "my-arduino.lan"). This essentially finesses the UDP problem above by making the Arduino the UDP server (handles DNS requests) and the browser already has name resolution s/w (like every machine on the planet).
I didn't search for Arduino DNS code, it might be too large for the Arduino and writing it may be a real PITA (pain in the butt).
Option: Arduino signals IP
In this model, you can attach a LCD to the arduino and have it present its IP address on the display. Alternatively, the arduino can send a message (via TCP) to a well known server on the network (internet or otherwise) reporting its IP address there. Your browser can query that server, pick up the IP address and then contact the Arduino directly. This introduces a 3rd machine and acts like your own hacked form of DDNS (look it up, if you're not familiar with it).
Option: Modify the router
If you own the router, you can modify the router to assign a specific IP address to the Arduino, even with DHCP. This is your best bet. Here, you control the network, can allow the Arduino to come up in DHCP while still fixing its IP address. You'll have to go through your router API (web or CLI) and figure out how to do it, it's a bit hard directing you as there are thousands of types of commercial and SOHO routers.
If you don't control the router...
Option: Use Static IP
This option is really your best. Give up on DHCP and just set the static IP of the arduino. Just make sure the IP address you pick doesn't conflict with any other servers on the subnet. That shouldn't be difficult.
I hope this helps.
The 2 best options I think:
1) When arduino starts, gets an IP address from DHCP, arduino should make a connection to a well know service provided by you. Also, each device should have an ID, defined by you during manufacturing, like mac address or part of mac address.
So, you can print on the box something like: 5c4e6f.my-well-know-host.com
Than, as I was suggesting, each time arduino starts, it tries to connect to that service passing parameters like:
POST www.my-well-know-host.com
ID: 5c4e6f
IP: 192.168.1.55
than, at that service, you update a DNS table to reflect this relation:
5c4e6f.my-well-know-host.com -> resolves to 192.168.1.55
obviously, from anywhere in the world the host 5c4e6f.my-well-know-host.com will resolve to 192.168.1.55, but you will only access it from you local network.
Tip: this is some kind of DDNS, but with network discovery purposes.
Tip2: there is an linux dns service called MyDNS, where the hosts are simply records inside a MySQL table, easy to maintain.
2) Network discovery
I don't know if arduino is capable to do it, but, the idea is to make arduino listen on a specific UDP port, like 4444, on any address.
So, you can build a windows app, and Android APP (I already made one android discovery for another purpose, not arduino), or, the best solution that I still researching on, is to make a custom page with some javascript code, that "looks" for devices listening on that specific port.
Works like that:
Device gets IP from DHCP
device starts a thread listening for broadcast packets on port 4444
a discovery app listen on another port, like 4445.
the discovery app announces itself using a broadcast packet to 4444 port (255.255.255.255:4444)
each device listening, reports back with its identification and IP to app port 4445.
This is a code to find the server ip:
<script type="text/javascript">
var ip = "<?php echo $_SERVER['SERVER_ADDR']; ?>";
alert(ip);
</script>
If you are using Johnny Five framework, then you can find APIs in that framework
I'm playing around trying to find a way to communicate between two browsers on the same network to establish WebRTC without a server roundtrip (no STUN/ICE/TURN). Basically an alternative to the approach found here, where the "handshake" is done via copy/mail/pasting.
After sifting through all the cross-browser-communication examples I could find (like via cookies or WebTCP) plus a bunch of questions on SO (like here), I'm back to wondering a simple thing:
Question:
If Alice and Bob visit the same page foo.html while on the same network and they know each others' internal assigned IP addresses, are there any ways they can communicate purely with what is available on the browser?
This excludes non-standard APIs like Mozilla TCP_Socket_API, but other than that all "tricks" are allowed (img tags, iframes, cookies, etc.).
I'm just curious if I can listen to someone on the same network "broadcasting" something via the browser at all.
Edit:
foo.html will be on static server, no logic, no ICE, no shortcut.
Edit:
Still not a solution but a websocket server as Chrome extension comes closer. Example here: almost pure browser serverless WebRTC
Yes, you can establish a direct connection between two browsers over the local network using WebRTC. It requires the use of ICE, but that does not mean that an outside STUN or TURN server is needed. If the browsers are on the same network, ICE will succeed with only the local candidates of each browser.
STUN/TURN is needed only in order to guarantee that two endpoints can establish a connection even when they are in different networks and behind NATs.
In fact, if you use most of the WebRTC example applications (such as apprtc) with two browsers connected in a local network, ICE is most likely to select and use the pair of local addresses. In this case a channel allocation on a TURN server will be made, but it will not get used.
In your WebRTC application, you can disable the use of STUN/TURN by passing empty iceServers when you create the PeerConnection.
While the MDN documentation lists WebSocketServer as a client API, I don't think this is accurate (maybe they wanted to document there how to write a server).
At the moment, I know no standard way to create a server socket on a web browser. I know a couple of attacks to scan the local network but most of them rely on an active server outside the network, that is you connect to a server and get JavaScript back which opens a WebSocket connection. Via that connection, I can take full control over the client and have it open more WebSockets with local IP addresses to scan the internal network.
If internal web sites don't implement CORS correctly (see here), I can access all internal web sites where the current user is currently logged in. That is a devious attack vector which allows external attackers to browser internal documents without cracking anything. This page has a demo of the attack.
Even Flash won't let you create a server socket.
If you allow a Java applet and the Java version on the client is very old or the user blindly clicked "OK", then you can create server sockets.
Related:
Socket Server in Javascript (in browsers)?
This could be explained easily. The answer is it's not possible. In order for alice and bob to communicate at all without a third-party, at least one of them needs to be listening for incoming connections. Not possible using a standard web browser alone.
You can take a look at this
https://github.com/jed/browserver-client
I think that you can easily create an http server with javascript and send messages from one browser to another
With Nodejs you can achieve the same.