1

We have done vulnerability analysis with third party security team. They have mentioned one point as critical findings but i don't understand risk associated with it and suggested remedial action also bit confusing.

Finding : Same web application can be access by two different URLS. Ex: http://1.1.1.1/abc, http://example.com/abc

Remedial Action : Upgrade PHP Version and Modify the HTTP ETag header of the web server to not include file inodes in the ETag header calculation.

Third Party Security Team Explanation : Users may confuse and they may victim of phishing attack

Could you please tell me someone what are the risks associated with accessing same application with It IP address and Domain name?

Improve this question
3
  • Unfortunately risk depends an awful lot on the context. One persons "critical risk" is another persons "doesn't matter". In your position I would suggest going back to the third party security team and ask them why they identified it as a critical risk. They will have your context and be able to answer that question much better than people on here can.
    – James Wilson
    Commented Feb 19, 2021 at 9:00
  • @JamesWilson Actually I asked them and their Answer was users may confuse and they may victim of phishing attack..
    – Infra
    Commented Feb 19, 2021 at 9:30
  • You should post that as an answer then for the first part. Yes, the remedial action does not seem to match, did you ask them to clarify that?
    – Dijkgraaf
    Commented Feb 19, 2021 at 10:52

1 Answer 1

Reset to default
1

There's a couple different parts here which seem somewhat jumbled. First, the remedial action listed here seems to correspond to a different vulnerability than the finding. It sounds like the finding is the one you're confused about though, so I'll try to answer that.

Specifically, this relates to exposing a web application both on a vhost and directly on an IP. Here are some of the possible issues as to why this is considered bad security practice:

  • Probably most importantly, users' browsers are going to consider these two separate origins. That means that if they visit one after the other, then password managers (both built-in and external) will not recognize it as the same site, and refuse to auto-fill the password. Coincidentally, that's also a great way to recognize phishing sites - you go to faceb00k.com and your browser doesn't auto-fill the password - red flag! So now your users are confused and have to manually dig out and copy/paste their passwords. This is probably the main issue the reviewers have a problem with.
  • Similar to the above, this will cause issues with CORS. Bonus points if your developers are hardcoding domains in API calls - now you have a site plus a subtly broken site.
  • If the site is on the public internet, listening directly on the IP means that it can be discovered by anybody with an IPv4 scanner. If you listen only on the vhost, now an attacker has to find out your domain before they can start attacking.
  • The IP address version likely does not have a valid certificate (it's not impossible to get certs for an IP, but extremely rare). Now your users accessing the IP version have to accept a security warning, and can't detect MITM attacks - you just defeated one of the two main advantages of TLS.
  • Lastly, sites that are listening directly on an IP address are often configured in a hurry by administrators that leave the web server bound to the default IP of 0.0.0.0, which means all IPs available to the server. If server has IPs in multiple network regions (internet, DMZ, internal LAN, secure segment, etc) that means that this web application may be exposed to hosts that aren't supposed to be accessing it (e.g., if the server is in the DMZ but the application is supposed to be only internally accessible).

So, recommendation: configure your web server to only expose the site on a vhost.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .