I have a webpage which checks for an encrypted cookie on page load to determine user identity. However, when I\'m testing the page locally on my development box, I don\'t h
The code for IsLocal
appears to be robust - I can't see any flaws in its logic so for your purposes it should be fine.
However, you should be aware that if your application (or any other application running on the same server) makes any HTTP requests whose destination can be influenced by the end user then you should add an extra layer of security such as a secret/expiring key or token to your request or you could secure the HTTP request when made so that it is not possible to request a local resource.
e.g. Say your website has an end point such as http://www.example.com/DeleteAllUsers
and in the code that handles this request you are checking IsLocal
to make sure that users can only be deleted if it is a local, trusted request.
Now let's say you have a function on your website Enter a web address to view headers: and the user enters http://www.example.com/DeleteAllUsers
in this text box, causing your application to request DeleteAllUsers
and satisfy the IsLocal
security check because the HTTP request is made from your app. This is how IsLocal
can be exploited, and I realise it is a contrived example to prove the point, but lots of websites do similar things such as grabbing a preview image of a URL to display. If nothing on your server can be made to make a local HTTP request you should be good to go.
Determining the remote IP is tricky and depends on configuring the server correctly.
For example a misconfigured server might use X-Forwarded-For to determine the IP, but it can be chosen by the client. But when using a reverse proxy that sets it to its own IP, this is the correct way to determine the IP.
Using the IP from the socket can be wrong as well, consider a reverse proxy running on the machine as the webserver.
=> If possible use a different authentication mechanism
You should not put this code on a production server, for the reasons mentioned in the other answers.
However, you could do
#if DEBUG
if (Request.IsLocal)
{
FormsAuthentication.SetAuthCookie("testUser", false);
}
else
{
#endif
FormsAuthentication.SetAuthCookie(/*EncryptedCookieValue*/, false);
#if DEBUG
}
#endif
On your development box, run a Debug build. In production, deploy a Release build.
I think your actual question is, how do you have development only functionality?
You could you use: Environment.UserInteractive
http://msdn.microsoft.com/en-us/library/system.environment.userinteractive.aspx
It returns false when running in IIS or a Windows Service, true when their is a user interface i.e. Visual Studio when your developing.
I think this is better than a DEBUG pre processor variable because the behaviour is more consistent, you could accidentally upload a DEBUG version of your dll to your live environment unless you have a very tight build/release process.
As a rule of thumb it's not a good idea to trust anything from the client.
I'd also be pragmatic, what are you protecting and how much effort would someone go to hack in?
The below SO post goes into some of the reasons why you shouldn't trust it:
Can I fool HttpRequest.Current.Request.IsLocal?
Reference
You can view the source at http://referencesource.microsoft.com
public bool IsLocal {
get {
String remoteAddress = UserHostAddress;
// if unknown, assume not local
if (String.IsNullOrEmpty(remoteAddress))
return false;
// check if localhost
if (remoteAddress == "127.0.0.1" || remoteAddress == "::1")
return true;
// compare with local address
if (remoteAddress == LocalAddress)
return true;
return false;
}