I have a password reset email going out to users which uses Request.ServerVariables("SERVER_NAME") to generate a URL for the password reset page. Problem is, the URL of the web application was changed recently, and the old name is still being reflected in the SERVER_NAME server variable. How can I reset this so the new, current server name is used? I'd rather not restart the web app in IIS if I don't have to. (I haven't actually stepped through the code; if I'm understanding this correctly, it will work just fine locally because IIS gets refreshed a lot more frequently on my PC than it does on a production web server.) Or am I misunderstanding how server variables work?
In essence from my reading around, your SERVER_NAME may be the name of the windows server itself and not necessarily the DNS name the rest of the world uses to reach that server. HTTP_HOST might be a better bet because it is the contents of the Host http header, which came from what the user typed into their address bar and subsequently what the user's browser passed in order to gain access to the site.
This is particularly helpful for sites that are multi homed, by which I mean one set of code runs eg two websites with different branding/styling, different bindings in IIS (different dns names) but the same underlying code, repeating back to the user what they typed into the browser means they always think they are interacting with the same site
I am trying to use the anonymous meeting provided with in the UCWA sample code. The developer sandbox works fine when I use the metio.net domain but when I try to use my companies domain we get a error message: "Service does not allow a cross domain request from this origin". So when I went to use the Anonymous meeting join and changing the domain with in the AnonMeeting.js to my companies domain I get the same error. I tried the only other option available on the index page, which is My own topology. I used my Skype for business login and gives me the 403 error with the same console message "Service does not allow a cross domain request from this origin". At the company I am at we use Skype for business online.
When we enter the URL http://lyncdiscover.domain.com we get to the xml tree fine but if its https we need to accept the invalid certificate. Once we do this and try to reopen the UCWA sample site we get the same cross domain error.
I would like to know if we can change the url to http within the api. Also assistance in making the anonymous chat work for my domain[or even metio.net] with in the sample code. Thank you anyone for helping me with this
You need to add the location you are hosting your application to the allowed list of your company's SfB servers. I would assume you are hosting your application in localhost. Metio.net is whitelisted for that, hence it works for the metio.net environment.
-- Since I was flagged for pasting the relevant Url link last time with Microsoft published details, I am copying the content from the website ucwa.skype.com --
Allowed Domains
Allowed domains refers to those hosting a UCWA web application.
The samples will indicate that the host domain is not on the allowed list by alerting the following string, sent by the server in the headers of a 403 response:
Service does not allow a cross domain request from this origin.
Viewing the Allowed List
From the Skype for Business Server Management Shell on each server (front end, edge, and director), execute the following command:
Get-CsWebServiceConfiguration | select -ExpandProperty CrossDomainAuthorizationList
Editing the Allowed List
From the Skype for Business Server Management Shell on each server (front end, edge, and director), execute the following commands (replacing the text in {} with your values):
$x = New-CsWebOrigin -Url "https://apps.contoso.com"
Set-CsWebServiceConfiguration -Identity "{YOUR_IDENTITY}" -CrossDomainAuthorizationList #{Add=$x}
If you do not know the value of Identity for your Skype for Business Server, you can run the following command to see all identities configured on the server:
Get-CsWebServiceConfiguration | select identity
I'm migrating a web app from an IIS 6 server to an IIS 7 server and I'm having some troubles with getting the client's certificate.
The piece of code that I'm using looks like this:
HttpClientCertificate cert = Request.ClientCertificate;
if (cert.IsPresent)
{
...
}
On the IIS 6 server, the cert.IsPresent is always true. However, on the IIS 7 box, it is always false. Both tests were done with IE 8 from the same computer. The only change was the Server URL, so the client should be setup correctly.
I'm not getting any SSL connection errors (I'm accessing the page via https) and I've set the SSL Settings -> Client certificates: to Accept (same as the IIS 6 configuration).
I've gone through and configured the IIS 7 server as closely as I could to the IIS 6 server, but I'm still not getting the cert.
Are there other areas that I need to look at for configuration?
Also, if I set the Client certificates: to Required, I get a 403.7 error on the IIS 7 box. I don't know if that is a symptom, but just in case the information is useful...
Basically it boils down to the fact that the client can't provide the client certificate.
That's why you get the 403.7 error when you require it.
I believe you need this:
http://blogs.msdn.com/b/puneetgupta/archive/2009/08/03/where-is-the-client-certificates-ui-in-iis-7-0.aspx
Please let me know if this helps.
I came across this question while looking for more information about how to get certificates in IIS 7 vs. IIS 6. I see that #whosrdaddy's solution worked for the asker. There is something else that I had to hunt down.
One of the differences between IIS 6 and IIS 7 is that IIS 6 has the "Directory Security" tab in each web site's configuration. In order to make the web server request certificates in IIS 7, you must click on the "SSL Settings" feature for the Web Site or Virtual Directory you are configuration to see the "Client certificates:" setting: Ignore, Accept, or Require.
Make sure that this is not set to "Ignore", or else you will never get your certificates to work!
The IsPresent == false can be caused by several different things, both related to the server and the client. We hit everyone of these on the way to finally fixing these and I will detail each....
Server Issue #1 - The client cert passed in has 1 or more certification paths that do NOT exist on the server. Open the cert go to certification path (tab) and make sure each of the root authorities are in the SERVERS trusted root certificate authorities. Note, you DO NOT need to install the cert on the server just the root authorities public keys under Certificates (Local Computer) \ Trusted Root Certification Authorities.
Server Issues #2 (previously mentioned solution) - In IIS, for the site, make sure the SSL Settings are set to Accept OR Require (never ignore). The benefit of using Require is that the IIS logs will show you are 403 7 error where as Accept will just get your the IsPresent == false but with a 200 http code.
Client Issue #1 - Same as server issue #1, got to trust those authorities!
Client Issue #2 - You have the trusted root authorites but NOT the private key for the cert itself. Make sure you install the pfx (private key) into the cert store not the public key (.cer). You can also see if you have the private key by double clicking the cert in the cert store and on the general tab you should see a message saying as much.
Client Issue #3 - You put the cert in the wrong place. Probably best to place your cert in Certificates (Local Computer) \ Personal \ Certificates, rather than (current user). This will make the cert available to process accounts that are running your code and actually need access to it.
Client Issue #4 - Right mouse click the cert (in the store not a .cer file) --> All Tasks --> Manage Private Keys... and make sure the process account running your code has "Read" permission. A quick test of this (but not recommended for production use) is to add "Everyone" as read to see if this is your issue.
I am working on an update to one of our sites. This version will have unique behaviors based on the host name in the request. In order to test this behavior, I modified my computers host file by adding entries that point back to my computer.
127.0.0.1 newhostname.sample.com
127.0.0.1 oldhostname.sample.com
Everything seemed to be working fine, until I started working with the Session object. I discovered that after each request all my session variables were lost. Further investigation revealed that each response from the server contained a new SessionID.
Why is that?
I was able to hard code some flags to complete my testing using 'localhost' for requests without any problems.
I think this has to do with the domain of the site and the session cookie passed - the browser won't pass a cookie sent to it from oldhostname.sample.com to newhostname.sample.com.
To fix this, you'll need to set the domain of the session cookie that is sent. This question should show how to do this - ASP.NET Session Cookies - specifying the base domain.
Alternatively, you could look into using cookie-less sessions. http://msdn.microsoft.com/en-us/library/aa479314.aspx
I can't explain it, but I have an acceptable work around to my own problem.
Rather than use 127.0.0.1 in the Host file I am using my local IP. So requests to the names in my host file are handled locally and I keep the same SessionID throughout the site.
If anyone else can explain I'd be happy to know what IIS (or asp.net) is doing when using 127.0.0.1.
I have a website "www.website.com".
Recently I found out that somebody has set up a reverse proxy with an almost identical url "www.website1.com" in front of my website.
I'm concerned of those users who came to my website through that reverse proxy. Their username and passwords might be logged when they login.
Is there a way for me to have my web server refuse reverse proxy?
For example, I've set up a reverse proxy using squid with the url "www.fakestackoverflow.com" in front of "www.stackoverflow.com". So whenever I type "www.fakestackoverflow.com" in my web browser address bar, I'll be redirected to "www.stackoverflow.com" by the reverse proxy. Then I notice the url in my address bar changed to "www.stackoverflow.com" indicating that I'm no longer going through the reverse proxy.
"www.stackoverflow.com" must've detected that I came to the website from another url and then redirected me to the website through the actual url.
How do I do something like that in ASP.NET web application?
Also asked on server fault.
First, use JavaScript to sniff document.location.href and match it against your domain:
var MyHostName = "www.mydomain.com";
if (0 == document.location.href.indexOf("https://"))
{
MyHostName = "https://" + MyHostName + "/";
if (0 != document.location.href.indexOf(MyHostName)) {
var new_location = document.location.href.replace(/https:\/\/[^\/]+\//, MyHostName);
if(new_location != document.location.href)
document.location.replace(new_location);
}
}
else
{
MyHostName = "http://" + MyHostName + "/";
if (0 != document.location.href.indexOf(MyHostName)) {
var new_location = document.location.href.replace(/http:\/\/[^\/]+\//, MyHostName);
if(new_location != document.location.href)
document.location.replace(new_location);
}
}
Second: write a init script to all your ASP pages to check if the remote user IP address matches the address of the reverse proxy. If it matches, redirect to a tinyurl link which redirects back to your real domain. Use tinyurl or other redirection service to counter reverse proxy's url rewriting.
Third: write a scheduled task to do a DNS lookup on the fake domain, and update a configuration file which your init script in step 2 uses. Note: Do not do a DNS lookup in your ASP because DNS lookups can stall for 5 seconds. This opens a door for DOS against your site. Also, don't block solely based on IP address because it's easy to relocate.
Edit: If you're considered of the proxy operator stealing user passwords and usernames, you should log all users who are served to the proxy's IP address, and disable their accounts. Then send email to them explaining that they have been victims of a phishing attack via a misspelled domain name, and request them to change their passwords.
After days of searching and experimenting, I think I've found an explanation to my question. In my question, I used stackoverflow.com as an example but now I'm going to use whatismyipaddress.com as my example since both exhibit the same behaviour in the sense of url rewriting plus whatismyipaddress.com is able to tell my ip address.
First, in order to reproduce the behaviour, I visited whatismyipaddress.com and got my ip address, say 111.111.111.111. Then I visited www.whatismyipaddress.com (note the additional www. as its prefix) and the url in my browser's address bar changed back to whatismyipaddress.com discarding the prefix. After reading comments from Josh Stodola, it strucked me to prove this point.
Next, I set up a reverse proxy with the url www.myreverseproxy.com and ip address 222.222.222.222 and I have it performed the two scenarios below:
I have the reverse proxy points to whatismyipaddress.com (without the prefix **www.). Then typed www.myreverseproxy.com in my browser's address bar. The reverse proxy then relayed me to whatismyipaddress.com and the url in my address bar didn't change (still showing www.myreverseproxy.com). I further confirmed this by checking the ip address on the webpage which showed 222.222.222.222 (which is the ip address of the reverse proxy). This means that I'm still viewing the webpage through the reverse proxy and not directly connected to whatismyipaddress.com.
Then I have the reverse proxy points to www.whatismyipaddress.com (with the prefix wwww. this time). I visited www.myreverseproxy.com and this time the url in my address bar changed from www.myreverseproxy.com to whatismyipaddress.com. The webpage showed my ip address as 111.111.111.111 (which is the real ip address of my pc). This means that I'm no longer viewing the webpage through the reverse proxy and redirected straight to whatismyipaddress.com.
I think this is some kind of url rewriting trick which Josh Stodola has pointed out. I think I'm gonna read more on this. As to how to protect a server from reverse proxy, the best bet is to use SSL. Encrypted information passing through a proxy will be of no use since it can't be read in plain sight thus preventing eavesdropping and man-in-the-middle attack which what reverse proxy exactly is.
Safeguarding with javascript though can be seen trivial since javascript can be stripped off easily by a reverse proxy and also prevent other online services like google translate from accessing your website.
If you were to do Authentication over SSL using https://, you can bypass the proxy in most cases.
You can also look for the X-Forwarded-For header in the incoming request and match it against the suspicious proxy.
As I see it, your fundamental issue here is that whatever application layer defence measures you put in place to mitigate this attack can be worked around by the attacker, assuming this really is a malicious attack made by a competent adversary.
In my view, you should definitely be using HTTPS, which in principle would allow the user to confirm for sure whether they're talking to the right server, but this relies on the user knowing to check for this. Some browsers these days display extra information in the URL bar about which legal entity owns the SSL certificate, which would help, as it's unlikely an attacker would be able to persuade a legitimate certificate authority to issue a certificate in your name.
Some of the other comments here said that HTTPS can be intercepted by intermediate proxy servers, which is not actually true. With HTTPS, the client issues a CONNECT request to the proxy server, which tunnels all future traffic direct to the origin server, without being able to read any of it. If we assume that this proxy server is entirely bespoke and malicious, then it can terminate the SSL session and intercept the traffic, but it can only do that with its own SSL certificate, not with yours. This certificate will either be self signed (in which case clients will get lots of warning messages) or a genuine certificate issued by a certificate authority, in which case it'll have the wrong legal entity name, and you should be able to go back to the certificate authority, have the cert revoked and potentially ask the police to take action against the owner of the certificate, if you have reasonable suspicion that they are phishing.
The other thing I can think of which would mitigate this threat to some extent would be to implement one-time password functionality, either using a hardware/software token or using (my personal favorite) an SMS sent to the user's phone when they log in. This wouldn't prevent the attacker getting access to the session once, but should prevent them being able to log in in future. You could further protect the users by requiring another one time password before allowing them to see/edit particularly sensitive details.
There's very little you can do to prevent this without causing legitimate proxies (translation, google cache, etc..) from failing. If you don't care if people use such services, then simply set your web app to always redirect if the base url is not correct.
There are some steps you can take if you are aware of the proxies, and can find out their IP addresses, but that can change and you would have to stay on top of it. #jmz's answer is quite good in that regard.
I have come with an idea, and I think a solution.
First of all you do not need all page to be overwrite because this way you block other proxies, and other services (like google automatic translate).
So let say that you won to be absolute sure about the login page.
So what you do, when a user gets on login.aspx page you make a redirect with the full path of your site again to login.aspx.
if(Not all ready redirect on header / or on parametres from url)
Responce.Redirect("https://www.mysite.com/login.aspx");
This way I do not think that transparent proxy can change the get header and change it.
Also you can log any proxy, and or big requests from some ips and check it. When you found a Fishing site like the one you say you can also report it.
http://www.antiphishing.org/report_phishing.html
https://submit.symantec.com/antifraud/phish.cgi
http://www.google.com/safebrowsing/report_phish/
Maybe create a black-list of URLs and compare requests with Response.Referer if the website is on that list then kill the request or do a redirection of your own.
The black-list is obviously something you would have to manually update.
Ok i have went throu a similar situation but i managed to overcome it by using another forwarded domain that points to my original perminantly , then checking with code if the client is the reverse server or not if it it i would redirect them to my second domain which will go to the original
Check out more info from here: http://alphablog.xyz/your-website-is-being-mirrored-by-someone-else-without-your-knowledge/
The simplest way would probably be to put some Javascript code on your page that examines window.location to see if the top level domain (TLD) matches what you expect, and if not, replaces it with your correct domain (causing the browser to reload to the proper site instead).