<p dir="ltr">The key is to use your firewall to block the software from listening on the external interface.</p>
<p dir="ltr">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?</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<div class="gmail_quote">On Apr 13, 2016 8:03 PM, "Leonard Daly" <<a href="mailto:Leonard.Daly@realism.com">Leonard.Daly@realism.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 4/13/2016 4:46 PM, John Carlson
wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">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?</p>
</blockquote>
<br>
John,<br>
<br>
True, but I don't know the class. It may also respond to requests
originating from other sources.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<p dir="ltr">John</p>
<div class="gmail_quote">On Apr 13, 2016 5:25 PM, "Leonard Daly"
<<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Andreas,<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">Leonard,<br>
<br>
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > (x3dom) ...
suggests to uses the http server which comes
with python:<br>
><br>
> <a href="http://doc.x3dom.org/gettingStarted/pythonSimpleHTTP/index.html" rel="noreferrer" target="_blank">http://doc.x3dom.org/gettingStarted/pythonSimpleHTTP/index.html</a><br>
><br>
> Running a http server (but web browser ?)
may be considered a security<br>
> hole if outgoing traffic somehow was not
considered in security design.<br>
<br>
Please expand on this. Do you mean the simple
python server, a<br>
full-blown server on local (e.g., Apache), web
server on the LAN, or an<br>
external web server? There are different
security issues in each<br>
configuration and the risk goes from minimal to
significant.<br>
<br>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
General rules:<br>
1) Start it up only when necessary<br>
2) Start it up in the lowest directory that provides access
to all needed resources<br>
3) Start it up on a port that is blocked by a firewall (8000
usually is)<br>
4) Terminate when work is done<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">..<br>
<br>
> It may be possible to package a small local
web server, webkit with js<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > engine, and
javascript app (cobweb) into a standalone
application with<br>
> a custom UI which can open local files. But
it would be a development<br>
> effort and the resulting application may be
a larger security risk<br>
> than a standard web browser although it
would not look like one.<br>
<br>
No, please don't (for anyone here). Too much
effort has already gone<br>
into the development of web servers, browsers,
JS engines, etc. to<br>
justify doing this.<br>
<br>
</blockquote>
<div><br>
</div>
<div>yep, my point. But I think this is what Don
may have looked for.<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I suspected you were not going to code one, but I also
wanted to discourage anyone else from doing it either.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Andreas<br>
</div>
<div> </div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
x3d-public mailing list
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<br>
<br>
<div>-- <br>
<font color="#333366"> <font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
X3D Co-Chair on Sabbatical<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i> </font></div>
</div>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
<br>
<div>-- <br>
<font color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
X3D Co-Chair on Sabbatical<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</div>
</blockquote></div>