I am hosting several IFrames on a 3rd party web site. The 3rd party site is the middle man to allow user access to a web site that is primarily for internal use by another company.
What I would like to do is verify the user's IP Address against a range of valid IP's for the 3rd party (middle man) web site. If it falls in the range allow the user to access the IFrame, if not - ACCESS DENIED!
Anyways, there are a ton of examples online to get the Request.UserHostAddress, but this brings back my IP Address.
My question is: how do I get the user's IP Address whom is accessing the IFrame to assure the request is coming from the 3rd party site?
So far I have tried ServerVariables and UserHostAddress. They both return ::1. I am running the site that hosts the IFrames locally and accessing those through the 3rd party site which is hosted on a server.
UPDATE
I have finally gotten around to updating everyone. Trying to do this by code is not a viable solution. But, I believe there is a solution for this through authenticating the IP Address with IIS. In code without implementing a very hacky solution we will only be able to obtain the user's IP Address.
However, by using IIS you can verify the 3rd party's address. This post from SO demonstrates how to do it. The post does not fit my case, but it does show you how to authenticate IP ranges.
Direct different IP's to different pages on IIS7
If I am successful I will specify that this is a solution for my problem.
I think you have the wrong idea of what should be happening.
As I understand it the situation is this:
You have Site A which has Iframes that have content from Site B in them. When you go to Site B directly the IP address you get is for your computer. What you are expecting is that when you go to Site A that the IP address that Site B receives will be that of Site A. This is incorrect.
When you view Site A you will download the page that will contain the IFrame HTML which will tell it what content to put in that frame by having a src="url" type syntax. At this point your browser (ie on your computer) will request the content from Site B and in doing so Site B will receive the IP of your computer again.
One thing that does what you want is the Referrer header (https://en.wikipedia.org/wiki/HTTP_referer). This is a way for a request to say what page told you to access that page. For example if you click to a link on Page C to Page D then Page D may receive a referer header saying that Page C referred it. The important part of that is that it may send it. It is often considered a security risk (especially between domains) so may not be sent in all cases or may be stripped by security tools and most importantly can be faked so it is not suitable for security purposes.
In general it is not easy to determine when serving a page that it is being embedded in a specific page's iframe.
The only way I can think of offhand to do this is when generating the iframe and its src target is to embed some kind of cryptographically signed token in that Site B can trust has been put there by site A. The token would of course have to have some kind of expiry to it and similar things to prevent a malicious user getting unfettered access once they have a token and some way to prevent replay attacks, etc.
In general the best bet would be to just use security on your Site B (eg username and password) and if somebody unintended gets to see it they don't have password details so they don't get anywhere.
Related
I'm working on a .NET Framework website that is only opened from a redirect command. Is it possible to do that only if I redirect from a certain website?
For example, if I have a personal blog and I want to redirect users to a certain site, that site would only open if the previous website is one I can whitelist or something like that.
If possible, I'd like to do it server side (the redirecting application is built in .NET Core 2.1)
Thanks a lot!
Technically, no. While you can use the Referer (historically mispelled) header, that header is not guaranteed to be present and can also be spoofed. In other words, if the client simply doesn't send the header, there's no way to know whether the user was redirected from your other site or not. Even if it is present, the client could have simply sent the header manually and completely bypassed your other site.
If the two sites are on the same domain or subdomains of the same domain, you can set a cookie at your other site that is then checked on the redirected site. However, the sites need to be able share cookies, which again, means same domain and both have data protections providers configured to utilize the same distributed store.
If you want to limit access the best and most fool-proof way is always going to be auth. Make them login at both points and you can ensure that no one can do anything you don't want them to do.
I have a Asp.net 4.5 MVC web application intended for a small group of international users. All functions available in the application are available to authenticated users only, there is no public content except for the login page.
For awhile I have had an error reporting system that emails me if an unhandled error occurs. Some of these reports include requests for pages that are obvious bot based security scans looking for holes. In an attempt to look at this problem further I installed an ip logging system that I could use to black list certain ip addresses (and store in a database table) and then use the Application_BeginRequest() method in the global.asax to return a 404 for a request from a blacklisted ip.
However, I recently deployed the routine and now see i am getting thousands of unwanted hits from thousands of different ip address scanning and looking for holes. As part of this I record the requested url, one of the most common looks like the following:
/Account/SetCulture?culture=fr-FR&returnUrl=http%3A%2F%2Fwww.mellon-associates.com%2FUserProfile%2Ftabid%2F42%2FuserId%2F26403%2FDefault.aspx
There are many variations on the returnUrl parameter. This doesn't work of course, as external urls are not supported by the application.
Regardless, I would greatly appreciate some suggestions on how I can lock down this application and the host server. I would use a white list only approach as a last resort as I don't necessarily know what ip a user is coming from.
thanks, John
You can use parts of IIS
"Request Filtering" for locking any parts in url.
"Dynamic IP Restrictions" for deny requests based on request frequency.
"IP Address and Domain Restrictions" for white/black lists of ip-addresses.
I'm writing a SaaS app in C#/ASP.NET, hosted with IIS7. I want to create a personalized subdomain for every customer that signs up, i.e. fred.mydomain.com, bob.mydomain.com, each of which will point to the same app, just with a different skin per customer.
How do I create these subdomains programmatically?
Use URL Rewrite for IIS7 to map all requests like user.mydomain.com (where user is not www, mail or other existing real subdomains) to mydomain.com/myapp?id=user Then in the script handle whatever theming you need.
You do not need to add rule for every user created. Just create one general rule to do so.
And, also, in your server DNS, you need to forward *.mydomain.com (where * is not www, mail or other existing real subdomains) to mydomain.com IP. This is pretty straight forward. You already have DNS records for existing subdomains. Just add *.mydomain.com and point to mydomain.com. This will do the DNS part of the trick. Other part is in the URL Rewrite
Realizing of course that someone already answered your question by telling you to do redirects, it seems the easier way might be to just grab the host server variable.
Setup IIS so that all incoming requests (regardless of the host
header) point to this one application. All sites have to either have a unique hostname or unique port in IIS, so you would set this up by:
Binding the site to the default port of 80.
Not providing anything in the Host Name field. This is also how the Default Website is setup by default when you first install IIS.
Figure out the static IP address of your server, and tell each new client that signs up to point the DNS for their domain to that IP. Or, if you will own the domain name, setup a catchall DNS entry: *.mydomain.com - points to the IP address of your server.
Within your application, check for the current
host header in order to provide a
different skin or master page.
This should grab the host header from within the code:
Request.ServerVariables["HTTP_HOST"]
From there you could test its value against a set of database values you have to determine which MasterPage/css stylesheet/etc you need to load based on that URL. Keep in mind if you do a catchall like this that you'll need to account for a URL mistyped that you therefore wouldn't have a skin to match to it.
Right now, I have all the employees of my company login to an external website using the company id, username and a password. We are trying to integrate it into an intranet portal which should provide seamless access to this website without requiring the user to enter these credentials.
Is there any way of doing this programmatically (.NET C#)? Very similar to screenscraping, Can I simulate the appropriate POST action and then redirect the user to the logged in page?
Any help is appreciated.
Thanks.
You can make a <form> in your page that mirrors the external site's login form with the same action= attribute, then fill put and submit it using Javascript.
Note that this requires that you send the user's password to the browser, which is never a good idea.
You can certainly post to the external website, the tricky bit will come when you redirect the user there, because there'll be cookies restrictions I think.
You might be able to do something with Javascript that makes the Client browser post directly to the third party with the correct credentials, look into jQuery's Post command.
Assuming that the external website maintains sessions with cookies in some way, the problem is, your company website can't set a cookie, except from it's own domain, and the 3rd party website can't read cookies except from it's own domain, so you can't transfer or pass the cookie across to your users.
The name for this technique is Single Sign-On. There's no one way to do it, but the emerging standard is called SAML. This requires participation on both parts (the originator and target website), so it's probably beyond your current purview.
Like the other two answers have mentioned here, you can post a formatted request directly to the action of the login script, but I can tell you from experience that that solution will be brittle, that is, it will shatter the second the target website makes any changes.
Your best bet is to contact the administrator of the target website and ask if they have an SSO (Single Sign On) solution.
How can I create a subdomain in an asp.net C# application? I am working with an asp.net portal. In that portal I need to be able to create the subdomain at runtime. The ftp for that subdomain also needs to be the same as the main domain ftp.
There are a handful of working parts here. It sounds like the requirement is that this all happen at runtime. I am sure a lot of web hosting providers are deep into these sets of problems and likely have custom solutions.
DNS: you'll need to have an API open at the DNS host. If it's a LAN environment, you'll have to check your DNS provider on whether they have APIs exposed. (i.e. Windows Server or whatever your network operating system is). If this is a public facing site that needs to be accessed via the internet, you'll have to get those APIs from the DNS registrar. Are the subdomains to be permanent?
IIS: You'll have to setup wildcard mapping, (i.e. *.mydomain.net). When an HTTP request comes in, logic within the ASP.NET page can determine the subdomain that you're working with. You could extract the subdomain, perform a lookup on that subdomain to get more information (CustomerID, names, valid visitor IP address ranges, whathaveyou).
FTP: if you require secure logins for that subdomain, you'd have to have created AD or local machine accounts for those users. If you want anonymous access, that's OK too. There are some scripting options that you'll have to look at to have that FTP folder setup as well. That is assuming you're using IIS's FTP module. If you are using a 3rd party FTP application, that complicates the scenario even further. Their APIs would have to be investigated.
Active Directory: If you are requiring secure access for each subdomain, you'll have to create AD users and/or groups. You can certainly script the creation of users into groups. Perhaps the users will be local to your web server. That doesn't scale well if you want to add another web server, but it's certainly do-able.
subdomain's are controlled by your dns settings. Beyond that I can't understand your question.
I think the best way is to have a wildcard DNS entry - i.e. *.domain.com that points to the domain. And then use a rewriting tool, like helicontech.com, to rewrite the 1st part of the subdomain to tell your app what you're looking at.
This would use regular expressions to pass the subdomain to your app:
RewriteCond Host: (mysub).domain.com
RewriteRule (.*) /$2?subdomain=$1 [I,L,U]
There are two halves to this:
A) Changing your DNS Settings:
This varies based on your host and whatnot. Contact them and ask if you can't figure it out.
B) Changing your host settings:
This varies based on your server. I assume you're using some version of IIS.
In IIS6, you can right click a web site, select the properties page, go to the web site tab, select advanced in web site identification, and start adding bindings (Generally you'll use default or the ip address for IP Address, 80 for TCP Port (unless SSL), and the site for the host header file (e.g. www.example.com or subdomain.example.com).
In IIS7, you right click on a website and select edit bindings, then click "Add". IIS7's add screen is pretty self explanatory.
I think he wants to created a subdomain from code, using an API probably that needs to be provided by his webhost folks. Like his own DNS manager app. If I interpreted your question wrong, then I guess you probably oughta reiterate a bit more.