8

We have a public ecommerce website hosted at our datacenter onsite. For people who are within the corporate firewall hitting the website I want to display profiling information about the request of the current page. This would include sql so we want to secure it as much as possible. When accessing the website from inside of our corporate firewall the users's IP address is always 192.168.0.12.

How can I reliably/securely tell if the user visiting our website is coming from inside of the corporate firewall? Is verifying the IP address enough?

Improve this question
2
  • What performance are trying to measure? How many users will use this type of access? Is the data sensative or are you concerned about weakening current server protections?
    – this.josh
    Jun 11, 2011 at 18:15
  • We are planning on implementing something similar to this: samsaffron.com/archive/2011/06/09/…
    – Paul Lemke
    Jun 13, 2011 at 12:38

3 Answers 3

Reset to default
5

How can I reliably/securely tell if the user visiting our website is coming from inside of the corporate firewall? Is verifying the IP address enough?

I think a bigger concern is "can you write this code in such a way nobody could manipulate it?" I very much doubt it, however, there are things you can do.

Edit Ok, old answer was probably being a bit security paranoid here. Introducing debug code into your live app is a security risk because it's another level of authentication you need to definitely stand up to scrutiny. However, in certain scenarios, that might be acceptable.

In the case of an online store, I could say the best option is client side SSL certificates signed by a trusted certificate the server knows about, possibly combined with IP address restrictions. Keep a revocation list Reasons for this:

  • Pretty hard to spoof. The certificate has to be signed and authorised by you first and installed into the client browser. Thus security becomes controlling access to authorised certificates - you can invalidate them server side by keeping a revocation list/whilelist of trusted "I will show profile information to"
  • You're using SSL anyway in the slowest case (logged in user) therefore you can assume SSL-based traffic times are upper bounds (plain HTTP will be faster, but only marginally).
  • Rely on existing crypto implementations rather than attempting to implement something new that might possibly be broken cryptographically speaking.
  • You could actually relax the IP requirements to a certain extent; developers can test from home too.
Improve this answer
2
  • This was the inspiration: samsaffron.com/archive/2011/06/09/… The trigger that actually turns the profiling on is determined by me. Our ecom site is quite large and we already log tons of info. I was hoping this was a "quick" way to get some realtime performance info.
    – Paul Lemke
    Jun 10, 2011 at 19:00
  • @Paul Fair point, and on reflection we use pypi.python.org/pypi/django-debug-toolbar/0.8.4 (The Django debug toolbar, which does much the same thing) in debug mode. I can sort of see why logs might not be enough, especially if it is hard to replicate the production environment due to scale, so I've re-written my answer.
    – user2213
    Jun 10, 2011 at 19:18
4

I would add additional authentication to the mix--perhaps an additional header added by an intermediate proxy or something. Even a header isn't very strong because it can be spoofed, but IP address alone seems a bit weak.

While spoofing TCP traffic (and seeing responses) is not trivial, you should look for another layer to add if possible. If you're in Windows, consider adding Kerberos/NTLM to the mix (Windows Auth).

Improve this answer
3
  • We are on Windows but our servers sit within a DMZ that doesn't have access to the windows domain. Not to mention we would have to turn kerberos/ntlm on for the entire website.
    – Paul Lemke
    Jun 10, 2011 at 18:52
  • Also... what about using the header, ip, and a querystring param?
    – Paul Lemke
    Jun 10, 2011 at 18:53
  • All three are controlled by the client, though. It doesn't mean you don't get some security out of it, but you need to realize that it can't be depended on 100%. The trick is understanding how much you're getting and not overestimating it.
    – Daniel Miessler
    Jun 19, 2011 at 10:00
1

For authenticated areas of the site, you could add a list of users that the application would provide debug information to, and check that along with the source IP address, so essentially it would only work for appropriate users coming from the internal network.

As other answers have noted relying on source IP address alone could be an issue, as anyone with access to that network would get this information if they hit the site, which (depending on who's on that network) could include people who shouldn't see it.

Depending on the configuration the risk of IP address spoofing could well be quite low, but allowing a whole network access to potentially sensitive information without authenticating them further would usually not be considered a strong control.

Improve this answer

You must log in to answer this question.

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