[x3d-public] ... cross-origin scripting errors

Thu Apr 14 04:35:07 PDT 2016

These issues are not specific to X3D applications but are arising more commonly as we want to use the web browser as a platform. It's interesting to notice that if use the InstantPlayer X3D browser, it runs an HTTP server which is open while you've got a X3D browser window open; the purpose is to give nuts and bolts information on the application. To see this, go to the "Help" menu (on Mac) or "?" menu on Windows, and choose either the "Web Interface Device Management" or "Web Interface Scenegraph"; you'll get your default web browser pop up with a page giving information about your running installation of InstantPlayer.  The web browser address windows shows that it is displaying content from a server at http://localhost:63244 (or some other high port).

The information offered up this HTTP server that seems to be part of InstantPlayer looks to be of most interest to program developers and debuggers, the actual displayed X3D model is shown in a regular OS window.

Some thoughts on the security implications
1- I installed this application on my system, and my OS's gave me all the usual warnings before doing so. I have no reason to think that the server which is part of InstantPlayer is a security risk; any more so than any other application which can read files on my system.

2. The web server itself is (hopefully) implemented so that it cannot serve arbitrary files from my file system; and it may be that all the content served up is generated dynamically and that there is no reading from the file system by this server.

3. All the suggestions made on this email thread about securing servers may have been followed; I haven't checked beyond verifying that incoming traffic to port 63244 is blocked by my computer's firewall.

Incidentally, this also gives a good illustration of why the cross-origin policy is important; without it someone could place javascript on their web page which upon loading in my web browser made an XMLHttpRequest (XHR) call to http://localhost:63244 ; and if I happened to be running InstantPlayer at the time that information would be retrieved and potentially then sent out to an external server; via another XHR POST request. With that in mind, I would hope that the InstantPlayer's little web server does NOT implement the CORS (cross-origin resource sharing) protocol that would tell my web browser that it's ok to retrieve this content from Instant Player (as described here: http://www.html5rocks.com/en/tutorials/cors/ )

> On Apr 13, 2016, at 8:58 PM, John Carlson <yottzumm at gmail.com> wrote:
> 
> The key is to use your firewall to block the software from listening on the external interface.
> 
> Yes, there may be an issue if you have routing installed between your loop back interface and another network interface on your machine (but why would you do that???).  If a local server is listening on your main ip address, then yes, others can access it, an external host can't access a host name bound to an ip address which represents your loop back device (often lo0) -- they have their own localhost ip address.  And again, a process running on your machine (a browser) can access localhost, afaik.  If your localhost is bound to an ip address which is not your loop back device (say your main ip adress) then you could be in trouble.  You should identify the IP adress used by your loop back device using ipconfig or ifconfig and use that to connect to your server of you are paranoid.  If you can get to your local web server with http://<main-ip>:<port>  it's likely you have a security issue.  If you cannot, how could someone else access it?
> 
> Yes servers can listen on more than one interface.  I would encourage you to make sure your web server only listens on your loop back interface ip address.   Check it with another machine connected to a local network.  I believe if you do a netstat -t and see a tcp server listening on port *:80 or *:http or whatever port you have your web server running on, then you are in trouble.  The *   is the key. I believe it means all interfaces.  If your loop back ip address is there instead you should be okay, unless you see another host name or ip address that a server is listening on.  I agree that you should be careful which web server software you use as some may bind to your main ip adress...but your firewall should stop that if you want it to.  Rule is, if you don't trust software running on your machine, don't let it open a port in your firewall.  Like I don't let X3D software through my firewall.  I would think a well tested locked down web server like Andreas describes is more secure than EAI.  Only put the files you want accessible to others in the web servers folder.  You are developing this for the web?  Use a router that blocks traffic on the LAN.
> 
> Again, don't  allow the local web server to poke a hole in your firewall.   If it's good software, it will declare the ip addresses it's listening on.  Node/express does not by default.
> 
> Another problem is that if you let an interpreter such as node, java or python through your firewall once for one program, I don't think there's a way to stop another program written in the same language from accessing your firewall.  I wish interpreted programs were hashed, or given one time access to the firewall.
> 
> On Apr 13, 2016 8:03 PM, "Leonard Daly" <Leonard.Daly at realism.com> wrote:
> On 4/13/2016 4:46 PM, John Carlson wrote:
>> My understanding was that servers bound to the loop back interface or localhost (you may want to use the IP address on your loop back interface instead of something specified in a host file) were not accessible from outside the machine.  Yes, if there's someone on your machine, they can get access to the servers files, but if they're on your machine, isn't that a bigger problem?
>> 
> 
> John,
> 
> True, but I don't know the class. It may also respond to requests originating from other sources.
> 
> 
> Leonard Daly
> 
> 
> 
> 
>> John
>> 
>> On Apr 13, 2016 5:25 PM, "Leonard Daly" <Leonard.Daly at realism.com> wrote:
>> Andreas,
>> 
>>> Leonard,
>>> 
>>>  
>>> > (x3dom) ... suggests to uses the http server which comes with python:
>>> >
>>> > http://doc.x3dom.org/gettingStarted/pythonSimpleHTTP/index.html
>>> >
>>> > Running a http server (but web browser ?) may be considered a security
>>> > hole if outgoing traffic somehow was not considered in security design.
>>> 
>>> Please expand on this. Do you mean the simple python server, a
>>> full-blown server on local (e.g., Apache), web server on the LAN, or an
>>> external web server? There are different security issues in each
>>> configuration and the risk goes from minimal to significant.
>>> 
>>> 
>>> I was trying to make sense of Don's comment on security holes. The simple python server may not be that different from Apache in a security sense. As you say it is all in the configuration and network setup.
>> 
>> Python's SimpleHTTPServer class is not fully functional. It only supports GET and HEAD and only files in the current working directory (when  started) and below. It does not support POST, PUT.
>> 
>> There also appears to be no support for domain names. Everything is referenced by localhost. It is also not meant to stay running. All that being said; it still should be run on a port (D=8000) that is blocked by a firewall either on the local computer or within the [sub-]network.
>> 
>> Many websites use URL rewriting to change from a "nice" format to something easier for software to parse. the Python server does not have that capability. It is a real simple get exactly what you request.
>> 
>> 
>> General rules:
>> 1) Start it up only when necessary
>> 2) Start it up in the lowest directory that provides access to all needed resources
>> 3) Start it up on a port that is blocked by a firewall (8000 usually is)
>> 4) Terminate when work is done
>> 
>> 
>>> ..
>>> 
>>> > It may be possible to package a small local web server, webkit with js
>>> > engine, and javascript app (cobweb) into a standalone application with
>>> > a custom UI which can open local files. But it would be a development
>>> > effort and the resulting application may be a larger security risk
>>> > than a standard web browser although it would not look like one.
>>> 
>>> No, please don't (for anyone here). Too much effort has already gone
>>> into the development of web servers, browsers, JS engines, etc. to
>>> justify doing this.
>>> 
>>> 
>>> yep, my point. But I think this is what Don may have looked for.
>> 
>> I suspected you were not going to code one, but I also wanted to discourage anyone else from doing it either.
>> 
>> 
>> Leonard Daly
>> 
>> 
>> 
>> 
>>> 
>>> Andreas
>>>  
>>> 
>>> 
>>> _______________________________________________
>>> x3d-public mailing list
>>> 
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>> 
>> 
>> -- 
>> Leonard Daly
>> 3D Systems & Cloud Consultant
>> X3D Co-Chair on Sabbatical
>> LA ACM SIGGRAPH Chair
>> President, Daly Realism - Creating the Future
>> 
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>> 
> 
> 
> -- 
> Leonard Daly
> 3D Systems & Cloud Consultant
> X3D Co-Chair on Sabbatical
> LA ACM SIGGRAPH Chair
> President, Daly Realism - Creating the Future
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

Vincent Marchetti
vmarchetti at ameritech.net