RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3]

[Jaikiran Pai]

Hello Julia,

On 17/09/21 3:14 pm, Julia Boes wrote:
> On Thu, 16 Sep 2021 14:05:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
>
>>> Julia Boes has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    correct path handling
>> src/jdk.httpserver/share/classes/module-info.java line 55:
>>
>>> 53:  *                                  [-o none|info|verbose] [-h to show options]
>>> 54:  *    Options:
>>> 55:  *    -b, --bind-address    - Address to bind to. Default: 0.0.0.0 (all interfaces).
>> I understand that the purpose of this simple server is for development and testing only. But even then, for security considerations, would it be more appropriate to default the bind address to a loopback address instead of making it accessible potentially to entire public? In the past, application servers which used to bind to all interfaces by default have now moved to using the loopback address as a default to avoid such accidental exposing of the server.
> We did consider defaulting to the loopback address, but this would limit the usefulness of the server too much in the default configuration as it can only be accessed from localhost. The goal of this JEP is an out-of-the-box web server with easy setup, so in this case we favour usability. The purpose of a web server is to make things accessible on the web so it is assumed that the developer is familiar with the terms this comes with.
>
> The concern of accidental exposure is alleviated by the informative output printed at start up, e.g.
> ```~ $ java-sb -m jdk.httpserver
> Serving /current/directory and subdirectories on 0.0.0.0:8000
> http://123.456.7.891:8000/ ...

I think this is still a really big risk. I say this based on some of my 
past experience with application servers (JBoss AS) where in older 
releases it used to do this same thing of binding to 0.0.0.0 by default 
and how that had lead to numerous (production) instances ending up being 
vulnerable. In the case there, the management console ended up being 
exposed and almost anyone over the internet could just access it to 
shutdown the server (through a JMX MBean).

In the case of this simple server being proposed, I think it's a lot 
more riskier because unlike in the case of the application servers where 
the server would have preventive measures that wouldn't allow local 
filesystem access, the current server being proposed will end up 
exposing the user's local filesystem to the internet. It's my opinion 
and experience that log messages no matter how much they scream out, 
won't prevent this default out of the box usage.

I'm not saying 0.0.0.0 should be disabled, but instead, IMO it should be 
the user who should explicitly use -b 0.0.0.0 to do that, so that they 
are at least responsible and aware of what they are doing.

-Jaikiran