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

Wed Apr 13 17:58:22 PDT 2016

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 listx3d-public at web3d.orghttp://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*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160413/8a51298b/attachment-0001.html>