From the perspective of an ASP.Net web form, can the Request.UserHostAddress be trusted? - asp.net

I have a web form that needs to act differently if the request to that form came from an internal network address or from a public IP address. I'm trying within my web form to determine if the request is from an internal network IP. Can I reliably do this, or can clients fake their source IP? Can I trust the information contained in Request.UserHostAddress?

No, you can't unfortunately. It's pretty trivial to construct an HTTP request with spoofed headers.

IP Spoofing is basically possible: Wikipedia but has limited use (as far as I understand, it is very hard to actually pull any data that way)
Best thing would of course be to route/restrict traffic on firewall or proxy level (establish a rule that allows local traffic only going to your site) to create maximum security.

Related

Is it possible to detect whether a request is truly from localhost or is forged to "look like" from localhost in application layer?

Based on my understanding, there are some tools that can send a request from an IP address and make the request appear to servers like from another IP address, including from localhost.
Now I have a server with a specific API that only allows requests from localhost but has some other APIs that allow requests from the internet.
The only way I can think of is to set the firewall so that any incoming packet will be blocked if the destination contains the "localhost only" API name. However this forces me to design my server in such a way that no other APIs has a substring name of the "localhost only" API. This means the "localhost only" API cannot have a short name and can be a risk if I forget this fact and/or the code is maintained by other people in the future.
Ideally, I want to distinguish whether a request truly comes from localhost at application layer and if not so block further processing of the API.
What I want to know is whether this is possible or not, in terms of networking.

What is the advantage of using proxy in network for accessing internet?

My college has different proxies for accessing Internet like 192.168.0.2/3/4 and also a specific port number.What is the advantage of using this ? I also would like to know what exactly happens there.I also heard that my institution has different ISP connections shared over the same network. What is the role of proxy there?
It will be very easy to know if you understand what proxies do and why they are used generally. Which could be found on a magical website called www.google.com. By using a proxy, you get more control over the network because all request go through there.Your school may want to do stuffs like traffic shaping, content filtering etc. Using the proxy server will make sure all request to the internet are routed there first.
Proxies are good for a few things:
Filtering. By using a proxy, your college can filter out viruses, porn, Facebook or torrent downloads.
Logging. By requiring a username and password, the college can track what you do with your internet time, and can tell you off if you go somewhere you shouldn't or help you be allowing them to do traffic shaping, or other network maintenance.
Line Bonding. For example, if you have two ADSL lines of 5Mb, you can bond those to get a 10Mb line (normally this is done at the gateway stage, and not the proxy, but it is possible to do it at this stage of the network)
Failover. Again, this would normally be done at the gateway/router stage. This detects which lines are active and routes your traffic to those lines.
Network Connectivity. If your college is in-turn part of a bigger academic network, this could allow crossing those network boundaries to get internet access.
Although those are valid possibilities, it's probably just for Filtering...
In the wider internet, proxies are in use for allowing access to blocked content - like giving China access to Google...

How to get visitor IP on load balancing machine using asp.net

We are having two load balancing server. In that we have hosted a asp.net 3.5 application right now we are using request userhostaddress to get visitor ip but it is giving load balancer ip instead of real ip. Can anyone have code for this.
I think that you must search not only for HTTP_X_FORWARDED_FOR, but for all that, depent what your loading ballance using
Context.Request.ServerVariables[CheckAllBelowList]
"HTTP_X_COMING_FROM",
"HTTP_X_FORWARDED_FOR",
"HTTP_X_FORWARDED",
"HTTP_VIA",
"HTTP_COMING_FROM",
"HTTP_FORWARDED_FOR",
"HTTP_FORWARDED",
"HTTP_FROM",
"HTTP_PROXY_CONNECTION",
"HTTP_CLIENT_IP",
"CLIENT_IP",
"FORWARDED",
The return of one of that, is the actual Ip of you client, except if is other proxy, I also need to learn how some one can get this, to find the user that is behind 2-3 proxy's...
If you know any other, please tell me so.
The problem is more to do with the fact that the "load balancer" is acting as a proxy. What type of load balancer are you using? I know with Microsoft ISA server there is a setting to pass the original users IP address through to the webserver.
Otherwise you will have to write a page to dump out the server variables and see if there an extra server variable being added that gives you the real client IP address.
depending on the load balancing server the client's IP could/should be written to:
Context.Request.ServerVariables["HTTP_X_FORWARDED_FOR"];
But beware if the user is also behind a proxy the value may be the proxies original client instead of the load balancer's client (which would be the proxy IP in this case). I'm not certain what behaviour is "normal".
Hope that helps,
Alex

Stable way of retrieving the external IP for a host behind a NAT

Basically I want to display a hosts external public facing IP address regardless of whether or not it is part of a natted lan. What I'm doing now is just connecting to myipaddress.com and retrieving it from there. I just don't know if I trust that site as a stable source. Is there some authority that facilitates this?
Every web server on the public internet automatically sees your external IP address. There is just no standardized way to "talk it back" as far as I know (e.g. through a header or something).
If you want to do this manually, just use one of the numerous "what's my IP?" services around like www.infobyip.com/detectmyip.php
If you want to do it in an automated fashion, the most stable way would be to set up a script on a remote server, and have that output the requester's IP. In PHP, in most cases, it would look like so:
<? echo $_SERVER["REMOTE_ADDR"]; ?>
(Here is a detailed discussion on how to retrieve the IP in various ways, but if the above worked for you once, it is likely to work forever.)
STUN RFC 3489will do it, though you need access to an open STUN server. There are other sites (like myipaddress.com) that will report your apparent address back to you, but there is no "standard" service for this.

How to get browser IP or hostname?

I have a web application that should behave differently for internal users than external ones. The web application is available over the Internet, and therefore obviously to the internal users as well.
All the users are anonymous, not authenticated, but the page should render differently for internal users than external. What I'm doing in my code is use Request.UserHostName and then Dns.GetHostEntry. The result is then compared to a setting in my web.config (that holds something like *.mydomain.local) . If the comparison gives a positive result then I render the HTML that the internal user should see otherwise I render the HTML the external user should see.
However, my problem is that I don't always get the expected value from Request.UserHostName. on the development site I get the IP-number (?) of the machine running the browser but on the customer site I don't get the IP-number of the user machine, I get some other IP-number. The browsers don't have any proxies set or anything like that.
Should I be using something else than Request.UserHostName?
I recommend using IP addresses as well. I'm dealing with this exact same situation setting up an authentication system right now as well and the conditions described by Epso and Robin M are exactly what is happening. External users coming to the site give me their actual IP address while all internal users provide the IP of the gateway machine(router) on to the private subnet the webservers sit on.
To deal with it I just check for that one IP. If I get the IP of the gateway, I provide the internal access. If I get anything else they get the external one which requires additional authentication in my case. In yours, it would just mean a different interface.
Try Request.UserHostAddress, which returns the client's IP address. Assuming your internal network uses IP addresses reserved for LANs, it should be relatively simple to check if an IP is internal or external.
There might be a firewall that is doing some sort of NAT, to enable inside clients to use the external dns-name to reach the server.
Is the IP-number you get on customer site the same at the external customer-server ip? In that case you can hard code for that one IP-address. All internal computers behind that firewall will appear to have to same ip-address and you can classify them as "internal".
It looks like you're being returned a public facing IP Address. Get the user to go to http://www.myipaddress.com . If this is the same as the IP Address returned to your software, then this is definitely the case.
The only solution I can see to get around this is to either get them to connect to the machine holding the asp.net application via a VPN, or to use some other kind of authentication. The latter is probably the best option.
It does sound like there is a proxy between users and the server on the customer site (it doesn't need to be configured in the browser). It may be an internal or external proxy depending on your network configuration.
I would avoid using the UserHostName for what is effectively authentication as it is presented by the browser duing the request and would be easy to spoof. IP address would be much more effective as it's difficult to spoof an IP address in a TCP/IP connection (and maintain a connection). It's still weak authentication but may be sufficient in this scenario.
Even if you are using IP address, if there's a NAT proxy between client and server, you may have to accept that anything coming through that proxy is trusted (I'm assuming that external/untrusted clients don't come through that proxy).
If that isn't acceptable, you're back to other methods of authentication. Rather than requiring a logon or VPN connection, you might consider a permanent cookie or client certificates and only give those to internal clients but you would need some way of delivering those to the client. You could certainly deliver a permanent cookie based on a one-time logon. Cookies can be spoofed in a similar way in that the UserHostName can be however you've got a better opportunity to create a cookie value that is less guessable than a domain name.

Resources