2025-04-10, 04:03 PM
(This post was last modified: 2025-04-10, 04:15 PM by bitstream. Edited 5 times in total.)
Are you saying JF hasn't implemented protection against OWASPTOP10 attacks and similar like i.e. input validation and so on? Is this what you mean with "not hardened"?
How can changing a port make an application more or less secure? When it comes to ports, the question is, who can access which IP in which network segment on which port from where using which protocol. This is what firewalls are for. In my case JF is running on a VM in a non public routed network segment. So no access for any sort of pirates :-).
If I get you right, you suggest to bind JF only on the loopback adapter, not exposing any of its ports on the public interface of the machine and then have a reverse proxy running on the same machine which on the second leg is talking to JF over http on the loopback adapter and is binding https on the public leg on i.e. port 443? Furthermore, in case there should be no application security, on the reverse proxy we also should have running an deep inpection firewall i.e mod security.
Just to make sure we have the same understanding: Running JF on Host A with http on a port other than 80 and having a reverse proxy running on host B, would leave all traffic between A and B unencrypted. This indeed would be a major concern, as in this case i.e. user passwords would be transmitted unencrypted. So in a scenario like this, https or any other kind of secure tunnel between A and B would be required.
How can changing a port make an application more or less secure? When it comes to ports, the question is, who can access which IP in which network segment on which port from where using which protocol. This is what firewalls are for. In my case JF is running on a VM in a non public routed network segment. So no access for any sort of pirates :-).
If I get you right, you suggest to bind JF only on the loopback adapter, not exposing any of its ports on the public interface of the machine and then have a reverse proxy running on the same machine which on the second leg is talking to JF over http on the loopback adapter and is binding https on the public leg on i.e. port 443? Furthermore, in case there should be no application security, on the reverse proxy we also should have running an deep inpection firewall i.e mod security.
Just to make sure we have the same understanding: Running JF on Host A with http on a port other than 80 and having a reverse proxy running on host B, would leave all traffic between A and B unencrypted. This indeed would be a major concern, as in this case i.e. user passwords would be transmitted unencrypted. So in a scenario like this, https or any other kind of secure tunnel between A and B would be required.