tags:

views:

263

answers:

10

I have some extra features on a site that employees can use but customers are not allowed to see.

The employees are all going to be on a series of domains.

What I do is get the user ip like so:

$user_ip = gethostbyname($_SERVER['REMOTE_ADDR']);

Then I get an array of all the ips for the domains the users will be on using gethostbyname

Then I check if the user is on one of the domains like so:

in_array($user_ip,$allowedIPS)

So if the user is on one of the domains they see additional features for internal use. Otherwise they just see what is meant for the general public.

My questions is, is this secure? Or could someone potentially spoof their IP to appear like they are on our domain and gain access to these features?

A: 

Everything is possible, but it's always matter of cost.
In most of cases such a spoofing doesn't worth

Col. Shrapnel
shit they upvote Amber for the same answer.
Col. Shrapnel
probably because your grammer is the suck
davr
@davr - shouldn't that be teh suk?
Joel Etherton
ahh then it's ok.
Col. Shrapnel
+3  A: 

IP spoofing is possible, if non-trivial.

Why don't you just have your employees log in to get access to employee-only features?

Amber
When you say "possible, if non-trivial", do you mean, this is not ok for storing sensitive information like bank accounts, but is ok for not so sensitive information like product-vendors?
John Isaacks
One very good reason is support costs. Having an application with its own credentials can become a giant pain in butt, fast. If he can tie into an exiting LDAP or other authentication server thats one thing, if not though it can generate a high volume of ongoing work. Passwords lost, changed, new employees need to be added, terminated employees need to be removed, etc... Doesn't sound like much, but in a medium sized corporation or higher it can sure add up over time.
Serapth
[a] If it's a system that they don't use often, or one which they access from multiple computers during the day, logging in each time is a pain [b] he'll have to supply registration, login, 'forgot password', and 'forgot username' pages.
egrunin
@John Isaacks - Yes, that's what was meant.
egrunin
-1 it is impossible to spoof a tcp connection over the open internet.
Rook
+1  A: 

I don't think this is possible, because when your making a request to a server, your actually requesting your ISP to request the server.

as long as you validate all the HTTP Meta data that the ISP Forwards on to you, such as X-FORWARDED-FOR and proxy meta you should be able to keep a tight system..

heres a diagram that may help you uderstand what i mean: alt text

read here for more info.

http://www.astahost.com/info.php/hacker39s-view-easy-spoofing-ip-address_t13807.html

RobertPitt
I think you're confusing **routing** (in the Network layer of the OSI stack) with **proxying** (in the Application layer). Very few ISPs use true proxying these days.
Daniel Pryden
+7  A: 

My questions is, is this secure? Or could someone potentially spoof their IP to appear like they are on our domain and gain access to these features?

No, unless they also have access to the networks of one of the allowed IPs, or any of the allowed machines under one of the IPs is compromised and proxies traffic.

In your scenario, it seems good enough. Well, except the privileged users will not be allowed to access the content from other IPs without some kind of VPN.

Note that IP spoofing generally has a different meaning than the one you're using. It means only forge the source address of a packet. This by itself is worthless because to access the service, it would also be necessary to receive the response from the server. Even "IP spoofing" in this sense is rare today due to better routing.

Artefacto
Yes and no - the response is not always necessary if you simply want to change something (and already know the proper request to submit to do so). It will prevent exploration, but not necessarily exploitation.
Amber
@Amber By response, I mean the SYN/ACK packet, not the HTTP response... It won't get that far.
Artefacto
@Artefacto While this is possibly getting a bit beyond the scope of the question, it's possible to make it get that far, if you have malicious intent - TCP sequence numbers are predictable, and thus you can pre-emptively send an `ACK` in response to the packet you know the server on the other end would be sending.
Amber
@Amber That's mostly been dealt with many years ago (see RFC 1948) and even then you'd need seriously misbehaving routers...
Artefacto
+2  A: 

If you are going to do this, do it with apache config, not with code. You are basically re-inventing functionality the is built-in.

As to the direct question, as others have said, spoofing an IP is possible if non-trivial. Also hope you don't have any unsecure access wireless points.

EDIT: Apache access control instructions. This is my assuming you are using Apache due to PHP usage, if you are actually using IIS, its still a config driven setting but obviously different in its execution.

Serapth
Thanks, the apache version only works for allowing whole pages right? I am trying to allow specific features on pages.
John Isaacks
Yes. From a best practices though, you are almost guaranteed to be best served having a secure vs non-secured site as opposed to a mix and match approach. Otherwise I promise you, with any complexity to your system, you will leak confidential information at some point, or create a maintenance nightmare going forward.
Serapth
+3  A: 

It is impossible to spoof a TCP connection over the open internet due to the Three Way Handshake. However, it maybe possible to access this feature using CSRF.

PHP pulls $_SERVER['REMOTE_ADDR'] directly from Apache's TCP socket, there for it cannot be influenced by an attacker. And yes, i have looked at this code.

Rook
So if I understand CSRF. An employee with an allowed IP accesses a different website where someone uses CSRF to trick the employee's browser to access the page with the hidden features. Thus, gaining access to the features via the employee's IP. But the attacker still wouldn't be able to see the features, right? because its a blind attack. They could only try to "use" the features blindly. Right?
John Isaacks
@John Isaacks this is correct. However "using csrf to trick" is bad wording. CSRF attacks are `<img>` tags to produce GET requests and `<form>` that automatically perform a `.submit()` when the page or iframe is viewed. I would still prevent CSRF in case of an insider attack. This can be as simple as checking the referer.
Rook
Awesome, thanks!
John Isaacks
A: 

I upvoted ROOK on this one. You cannot spoof a TCP connection and still access your site from the same machine doing the spoofing. Why? Because the response your web server would make (initially) would be to the spoofed IP in an attempt to establish a socket connection (TCP 3-way handshake).

It is conceivable that if you have two computers (A and B) at two different public IP addresses and you use one of the computers (A) to spoof or send packets to your web server using B's IP address such that when your web server replies it sends packets to B.

If the IP addresses used in the spoofed call are internal on your subnet, then internal workstations would receive TCP ACK packets for uninitiated TCP SYN packets and reject them or ignore them. I'm not aware of any TCP/IP stack implementation that would try to complete a 3-way handshake against ACK only packets; it breaks standard protocol.

Spoofing is technique for UDP flooding where an attacker does a DoS (Denial Of Service) attack using a phony IP address to attempt to hide their tracks.

Hope this helps.

Eric M
A: 

Check the server docs or source.

baklap
A: 

$_SERVER['REMOTE_ADDR'] is provided by your web server and it's not possible to spoof it directly. The only way around it that I can see is proxying the connection via one of the allowed IPs.

Pies
A: 

When we were confronted by a similar question, we came to the conclusion that if the user was accessing us via http, we couldn't absolutely rely on their IP address, because they could be using a proxy. But https is always a direct connection; it doesn't allow proxies, so we could be sure that the IP address we were seeing was correct. Therefore, we locked our users down based on IP address PLUS they had to access the site via https (and log in to their account, of course).

Your case sounds a little bit different from ours, but I'd say the above should be useful for you as well.

Even if you don't follow that exact path, you do need to be aware of proxies. A proxy could theoretically allow any number of different users to access your site from a single IP address, so if you somehow managed to get a proxy's IP into your list of allowed addresses then you'd be opening up a security hole, so you need to be sure that any IP address you add to the list is legitimate (this is where https can help).

Also, if your users are coming from their home PCs, be aware that their IP address could change over time. Most ISPs will issue their customers with dynamic IPs which can be re-assigned, meaning that each time you connect to the internet, there's a chance you'll get a different IP address. If this is the case, there's no spoofing going on but nevertheless you won't be able to reliably identify a user by their IP address.

Spudley