1 2 Previous Next 17 Replies Latest reply on Apr 9, 2007 6:37 AM by fhh Go to original post
      • 15. Re: Multiple Domain Quesiton

        You said:


        I was thinking about how to do this best too for some time and I really think this is useful, not "security by obscurity", because people wont start to fiddle with something if they don't know it's there.



        This way normal users can't prove that /admin exists and wont start fiddling with it.


        What if they find out anyway?

        For security you should not rely on people "not fiddling" with your pages. The pages should be secure - FULL STOP. If you have pages that should not be visible to the public than deploy them to a different server or make them available over a different connector.

        When it comes to security I am against any snake oil. It gives you the impression that things are secure while they are not - and that makes things worse than they would have been in the first place because it makes you careless.

        Having said that I have to add that I am not against the feature suggested. I am just against using it as an security enhancement.

        Regards

        Felix

        P.S.: When I said the "the hostname I use to reach your machine is entirely under my control" I was not talking about http referers. I was refering to the idea of the original poster to make security depend on the hostname you use to access the site.

        • 16. Re: Multiple Domain Quesiton

           

          "fhh" wrote:
          You said:
          P.S.: When I said the "the hostname I use to reach your machine is entirely under my control" I was not talking about http referers. I was refering to the idea of the original poster to make security depend on the hostname you use to access the site.

          I generally agree with what you're saying, this is a touch pendantic, but... Technically if you support multiple apps on multiple hostnames, that's exactly what you're doing. You're using the security in the appserver as opposed to rolling your own, but its otherwise exactly the same. After all, your JBoss server is serving both pages, and acting differently based entirely on the URL.

          Also please note that in my (original poster's) case, in no way shape or form would I consider not securing the controlling hostname's pages. This would merely be a convenience, not-security-related feature so that when someone requested the "unknown" URL from one of the hostnames that should not know anything about it, they receive the 404 error which, if you think about it, does mean "The complete URL as you stated it does not exist," not "This server doesn't know anything about the second half of this URL on any of its hosted domains."

          I would not recommend, as the previous poster mentioned, sending a 404 error to someone using the correct administrative URL who was not logged in (or not logged in as an admin). That does break consistency, doesn't follow the definition of a 404, and eliminates the opportunity to ask them to re-authenticate themselves. In my case, no-one will ever be able to access the page through the stated URL, so I'll stand by my 404 delivery.

          • 17. Re: Multiple Domain Quesiton

             


            I generally agree with what you're saying, this is a touch pendantic, but... Technically if you support multiple apps on multiple hostnames, that's exactly what you're doing. You're using the security in the appserver as opposed to rolling your own, but its otherwise exactly the same. After all, your JBoss server is serving both pages, and acting differently based entirely on the URL.


            That depends on your setup. If you used name-based virtual hosts you are right. If you use address based virtual hosting then you are not. If you want to use the virtual hosting as a security feature you would obviously use the later and add appropriate firewalls rules.


            I would not recommend, as the previous poster mentioned, sending a 404 error to someone using the correct administrative URL who was not logged in (or not logged in as an admin). That does break consistency, doesn't follow the definition of a 404, and eliminates the opportunity to ask them to re-authenticate themselves. In my case, no-one will ever be able to access the page through the stated URL.


            If everything is configured correctly, he will not be able to. But you will make a mistake more easily: While testing you get a 404 instead of a page that is completly unsecure so it looks safe to you while it is not. When it comes to security my philosophy is that simpler is safer.

            Regards

            Felix

            1 2 Previous Next