Obtain IP Website Server Address | Tech Off

I have a rather unusual request.

I have a webservice on a server written in C# and in it, I need to obtain the IP address of the Server that is calling it.

Using

HttpContext.Current.Request.UserHostAddress

I can get the IP address of my computer that is calling the web service. But I will be calling my web service from various web sites and I only want it to be run from websites hosted in my server. So I need the IP address of the server hosting the website, not the IP address of the computer making the request to the website.

Basically, my web service is sending emails and I only want it to be callable from sites that I control. (Sites will be HTML, not necessarily ASP.NET. I have sorted out plumbing between HTML and ASP.NET Web service already).

I have also tried

HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"]

But I get the same result (The IP address of my computer, not the server hosting the website that is making the call to the web service).

Hope this makes sense.

I have also tried another way around the problem, but restricting access to the webservice by IP in IIS 6. But once I had done a "Deny All", then "Grant IP of my Server". The service could not be called from my server. So if anyone knows any "oddities" with web services and Directory Security in IIS, I would be gratefull.

Many thanks for any thoughts

Mike

W3bbo

A computer can have more than one IP address, which one are you after?

You could try and see if there's a class under System.Net that ASP.NET uses to represent the connection between the server and client, that would contain the address of both endpoints.

RichardRudek

I'm confused.

So are you saying that your user's Web Browser uses your Web Service, directly (AJAX/whatever), but you actually want the IP Address of the site that their Browser navigated to. In other words, you want you prevent others from (repackaging and) using your Web Service, yes ?

m1keread

It is quite difficult to explain, but I'll try again with a morning head on!

I have a web service written in ASP.NET hosted on SERVER01.

I have web sites also hosted on SERVER01.

I have a very basic HTML script that calls the web service, basically allowing the HTML page to send out emails as and when required. This script will be hosted on Web server SERVER01

What I dont want is "billy the script kiddie" copying my HTML page and sending his own emails via my web service.

Therefore, I was hoping for a way to stop any invocation of the web service except those coming from SERVER01.

My initial though was to get the IP address of the web server (SCRIPTKIDDIESERVER01) and if was not the same as the server I am in control of (SERVER01) then do not call the web service email code.

Problem is that I cant get the IP address of the SCRIPTKIDDIESERVER01 machine, only the Script Kiddies PC/Laptop Ip address.

Basically, I would like my email service to look like this

[webservice]
function SendEmail()
{
if (RequestingServer == ServerRunningOn)
{
Send email
}
}

Quite simple really, just that I cant seem to get the IP address the requesting server.

regards

Mike

prencher

The only feasible way to do that is to route it through the server. A HTML/JS only script will just talk directly to your webservice from the client; Obviosuly you can't know whether that file is on your server, or the clients harddrive, or another server.

In other words, you'll want to set up a proxy postback or similar, that calls out to the service on the server side. That alone won't help anything against spamming however.

m1keread

prencher wrote:

The only feasible way to do that is to route it through the server. A HTML/JS only script will just talk directly to your webservice from the client; Obviosuly you can't know whether that file is on your server, or the clients harddrive, or another server.

Thanks,

That seems to be exactly what is happening. Maybe I should try a different tac.

What I am after is a "Form to Email" solution for generic HTML sites (Not ASP.NET). I thought my web service was an elegent solution, but if I cant nail it down, then I will have to try something like Frontpage extensions or I expect there are scripts out there somewhere

regards

Mike

prencher

m1keread wrote:

prencher wrote:The only feasible way to do that is to route it through the server. A HTML/JS only script will just talk directly to your webservice from the client; Obviosuly you can't know whether that file is on your server, or the clients harddrive, or another server.

Thanks,

That seems to be exactly what is happening. Maybe I should try a different tac.

What I am after is a "Form to Email" solution for generic HTML sites (Not ASP.NET). I thought my web service was an elegent solution, but if I cant nail it down, then I will have to try something like Frontpage extensions or I expect there are scripts out there somewhere

regards

Mike

It depends on your needs, but it might be enough to just limit the addresses you can send to through the script, and put a per-ip timeout on sending new e-mails.

Further I'd add a unique ID in a hidden field, so if abuse does happen, you can easily tell where it originated from, and eliminate that ID.

Obviously, you could then extend on that, and add a timeout per-ID as well as per-IP to make it even more robust. Etc etc.

RichardRudek

m1keread wrote:

...

What I dont want is "billy the script kiddie" copying my HTML page and sending his own emails via my web service.

Therefore, I was hoping for a way to stop any invocation of the web service except those coming from SERVER01.

...

So, it is as I described, then - you need to secure your Web Service.

I'm not a Web Developer, so I'm not familar with what is currently around for this. But if I were to design something like this, then the first thing you need to do is take the non-trusted party out of loop. ie Not have the client (Web Browser) use the Service.

However, if for some reason you have to involve the (non-trusted) client, then I would have the Web Server pass a token (permission) to the client, which must in turn supply this token to the Web Service. The token would need to be volatile. How volatile, would be dependent upon your needs. For example, it could even be a one-to-one, per message token, and/or expire after some amount of time, etc.

So the flow would be something like:

The Web Server obtains a batch of tokens from the Web Service, which it dispenses to the Browser as a hidden field (or whatever), and the javascript running on the Browser, passes the token on to your Web Service as a parameter. Your Web Service then validates the token, responding accordingly...