Is there a way to limit access to a particular page with IIS? basically what I'm looking for is to only allow access to a particular page via another specific page/link. I've looked into the IP Address and Domain Restrictions feature within IIS and can utilize that, but I would like to keep it between particular pages.
for example:
I have a page, SecurityCheck.aspx and I only want a person to be able to access that page if they came from SecurityPassThrough.aspx.
Since I don't know your experience level I think it's worth pointing out that what you're trying to do would not truly be a secure solution. Anyone is capable of modifying their HTTP request headers before sending them to the server.
If this faux security is good enough for your purposes, then you could implement it simply by checking the Request.UrlReferrer property. As far as I know there is no way to do this type of processing out of the box in IIS, so you're left going down the stack to the ASP.NET level:
if (!Request.UrlReferrer.Segments.Contains("SecurityPassThrough.aspx")) {
//Do something
}
Related
We are working on the conversion of an ASP site to ASP.Net and are running into problems with redirects and resource locations. Our issues are coming from a peculiarity of our set-up. Our site can be accessed in two ways:
Directly by URL: http://www.mysite.com - in this case everything works fine
Via a proxy server with a URL like: http://www.proxy.com/mysite_proxy/proxy/
In #2 "mysite_proxy" is a mapping on proxy.com that directs the request behind the scenes to www.mysite.com, "proxy" is a virtual sub-website that just redirects the request to the root of www.mysite.com. It essntially is meant to give us a convenient way of knowing if a request is hitting the site from the proxy or not.
We are running into two problems with this setup:
Using Response.Redirect either with the "~" or a plain relative path (Default.aspx) generates a 302 response with a location of "/proxy/rest_of_the_path.aspx." This causes the browser to request http://www.proxy.com/proxy/rest_of_the_path.aspx which isn't anything and doesn't even hit our server so we couldn't do an after the fact re-write.
Using "~" based URLs in our pages for links, images, style-sheets, etc. creates the same kind of path: "/proxy/path_to_resources.css." We could probably solve some of these by using relative paths for all these resources though that would be a lot of work and it would do nothing to address similar resource links generated by the framework and 3rd party components.
Ideally I want to find a global fix that will make these problems transparent to the developers working on the site. I have a few ideas at this point:
Getting rid of the proxy, it is not really needed and is there for administrative and not technical reasons. Easiest to accomplish technically, the hardest to accomplish in the real world.
Hand the problem off to the group that runs the proxy and say it is their problem they need to fix it.
Use a Response filter to modify the raw html before it is sent to the client. I know this could fix my resource links, but I am not certain about the headers (need to test it out) and there would be a performance hit to having to parse every response looking for and re-writing urls.
All of these solutions have big negatives in my mind and I was hoping someone might have another idea. So any thoughts?
Aside: there are a lot of posts up already that deal with the reverse of this issue: I have a relative URL, how do I may it absolute, but I didn't come across anything that fit the bill for the other direction.
As a fix, I'd go with a small detection routine at Global.asax:Session_Start (since i imagine that the proxy doesn't actually starts another application instance), set a session variable with the correct path, and use it instead of '~'.
In the case a different application instance is used, then use Application_Start instead of Session_Start and a static Global variable instead of a Session variable.
I want to be able to restrict page access in a web application deployed in IIS 6.0.
Say my web applications has these pages:
a.aspx
b.aspx
c.aspx
d.aspx
The proper way to access is "http://mysite/a.aspx"
From a.aspx the other aspx pages could be loaded. What I want to be prevent is someone typing in:
"http://mysite/c.aspx"
And then being served that page. Any ideas?
Thanks.
You have a couple of options really. You could utilize some user authentication, this seems like it could be overkill for what you are attempting.
I think the easiest method if I have understood you correctly is only to allow viewing if the referring page is a.aspx So it would give a permission denied or some other message if your referring page is not a.aspx.
You could always store a session variable in a.aspx and check that variable in c.aspx and redirect back to a.aspx if it is not what you are looking for. To prevent a repeat the session variable could be destroyed in c.aspx. I am sure someone could spoof the session if they wanted to that badly but unless you have gold on that page no one is going to care, and if you have gold on that page you need different security measures anyway.
You could set a variable in the page in question whose value will only be set when coming from the specific page and the first thing you check on the page in question is whether that value is set otherwise display some message or deny access.
Is there a way to access referrer information from the server log in a ASP.NET web application?
I would like to know if a customer comes to my web app from a specific site and change the app's behavior accordingly. I could have the webmaster of the other site include a query string, but to my knowledge this wouldn't work because as soon as Tom, Dick or Harry posted the link somewhere else, the query string would be unreliable.
Is there a sure fire way for a web app to know where the user came from?
Why not just check the Request.UrlReferer property and change the behavior if the referer is not any page on your site?
This would be a lot simpler than referencing IIS logs.
You can access the referrer information through the HttpRequest.UrlReferer object.
However you should note:
This can null - so check for null before calling AbsoluteUri on it.
This can be changed fairly easily, so you can't rely on it completely
Why would you not just access the Request host header for the HTTP_REFERER instead of the log file? See here, but note that you are never guaranteed to recieve this information, nor is it reliable if you do.
Request.UrlReferrer.AbsoluteUri
gives you the same as the server logs will. Probably a combo of querystring variable and UrlReferrer will do the best job of ensuring that it came from the right source.
UrlReferrer is sent by the client, and it's not guaranteed to be there.
Are you using a shared environment? Normally they will supply this if you request the logs (normally an option in Plesk or similar). The log directory will probably be one or two folders up from the root http folder, so it may not be accessible using the IIS user.
On a dedicated server then you can obviously configure this manually.
I suspect the answer is no (or at least, not in an intelligent manner), but felt like asking.
Is it possible in an asp.net HttpModule to determine the page that is going to be returned to the user, taking default page settings of IIS into account (without hardcoding them outside of IIS). For example, if a user requests http://www.example.org/bar/, the real page might be http://www.example.org/bar/index.html -- but could just as easily be http://www.example.org/bar/foot.html , depending on the user's IIS settings.
You're correct: in cases where there was no file.ext available in the requested URL, the IIS settings would have to be available in order to determine the actual page that was returned.
Given that the module has to live on the IIS server, I think you could get the list of default pages configured in IIS by connecting via WMI. You'd then have to get the list of files in the requested folder to figure out which of the default pages was actually returned.
I do not believe this is possible, but I figure there are people out there way smarter than me, so why not check ..
I would like to have an HTTP image that is viewable from within a page when used w/in an img tag, but NOT visible if the img src link is called directly. Does that make sense? Viewable in page, but not if called directly.
Quick edit .. acceptable alternative is to embed image in page in such a way as url is not human readable / able to be extracted and typed into browser.
Update 2 ... .NET IIS7 env.
Note that "security" products such as Norton Internet Security and Norton Personal Firewall prevent the HTTP Referer: (TBL's spelling mistake, not mine) header being sent by default. As these products are widely used, referrer blocking will break things for an awful lot of people.
FWIW, if I was keen to get your image other than by viewing your page (although I can't imagine why I should be) I would just grab the bits as they came over the network when I viewed your page, using something like Charles or Fiddler. It's completely impossible to make content available over the web but prevent people from making a copy.
I believe that you can achieve something like this by relying on the referrer header supplied by the browser - when the referrer is a web page on your own site, you serve up the image, but not otherwise.
It's not 100% reliable (as passing the referrer isn't mandatory in the HTTP spec) but works well enough for some sites.
This is achieved through configuration of your webserver; you therefore might have more luck asking this on ServerFault.
Yes, there are lots of articles on how to setup mod_rewrite rules in apache to try and prevent direct access to files.
http://www.cyberciti.biz/faq/apache-mod_rewrite-hot-linking-images-leeching-howto/
It depends on how it gets built. You can always make sure your referrer is the page that you expect it to be hosted from and lock down requests there.
If you have some notion of authentication, you could bury the image under some type of php/ruby script or asp.net http handler that requests the image from the server or database (in a place that is not publicly viewable but is reachable by your server-side code) and that handler could check for your authentication status before returning it.
Frankly, I re-worked my solution so I didn't really have to worry bout it ... know that's a cop out, as it doesn't REALLY answer the question, but there it is. My concern that users would be able to defraud the "game" I was creating if they could figure out the sequence that was being used to name the images. Quick and dirty solution .... don't make image file names sequential / predictable.