One of my developers left the IP inside his code :

The code is as follows :

public string UploadFile(byte[] f, string fileName)
        MemoryStream ms = new MemoryStream(f);
        FileStream fs = new FileStream("" + fileName, FileMode.Create);
        return "OK";
    catch (Exception ex)
        return ex.Message.ToString();

If you note in his code he revealed the

The known vulnerabilities I can think of are:

  • The attacker can run a nmap scan and detect which OS and ports were open

  • If directory listing was not properly implemented then it would be a issue of browsing directory

  • If the application was publicly accessible there were possibilities to copy the application design

The above were the known vulnerabilities that I could think of for revealing IP, but what are other vulnerabilities?

  • 9
    and you post it again here? – schroeder Sep 3 '15 at 4:33
  • @schroeder trusting dmz people and posting it over here :),other than that its dummy ip – BlueBerry - Vignesh4303 Sep 3 '15 at 4:38
  • 1
    An obvious vulnerability is that you're not using HTTPS. But that's not really related to exposing IP address. Another potential vulnerability is that you can't use DDoS protection proxy or DNS load balancing as easily if you're using the IP address directly, rather than with domain name. In general though, you should treat IP address as public knowledge; if your security relies on people not knowing your IP address, you're screwed. – Lie Ryan Sep 3 '15 at 5:04
  • Another potential vulnerability is that the server is letting the client application decides the filename. Unless there's server side restriction that prevents the upload if there's already a file with that name, this may open you up to someone overwriting another people's files if they can guess the filename. None of these are directly related to IP address exposure though, the same vulnerabilities exists without exposing IP address. – Lie Ryan Sep 3 '15 at 5:08
  • What would be the alternative? Using a hostname? Then the IP is still just a DNS query away. – Philipp Sep 3 '15 at 20:58

I think the vulnerabilities are the same for all Internet-accessible servers, the only increase in risk is that the code exposes some specific information about how to interface with it, and because it is "in code" the programmer might not think to protect it as well as they otherwise might for a server that is explicitly advertised.


As stated by @Lie Ryan in the comments, IP would not be much of an issue, and can be treated as public information. For all you know, I could just run a ping from windows CMD to find your IP.

I would however like to bring to your attention, a few vulnerabilities you opened up by not cleaning up the code before posting it on this site.

1. Simply going to the IP provided here revealed your running IIS.

This kind of information could be used to understand the server side environment, and thus launch an even more specific and effective attack. I can also assume your using asp.net. More info = more strength for an attacker.

2. Going to the IP/address/to/site/ has revealed what organisation this belongs to

An attacked now knows how beneficial an attack can be. The attacks can be far more contextual to your business and location.

3. Full address reveals even more about file structure, naming conventions etc

Given that the entire address is revealed. One can get insights to the architecture, file hierarchy etc for your application.

I know this is not what you asked for, and technically off-topic, I couldn't stop my self from posting this.

I hence strongly recommend you reword the question, heighten security at your server side and be very caution while posting source code on public domain.


I just browsed through your question again, and realized you mentioned similar vulnerabilities. Baffles me as to why, the info was still revealed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.