I have an app that uses a session to store an ID for the user, standard practice for most login systems. The app has worked in IE before. I'm using Heroku to host.
I recently updated the rails version to 3.0.20 because of the security concerns, and it seems that IE will not allow any cookie to be set. Cookies are stored just fine in Firefox/Chrome/Safari, but IE will not store them.
There are no underscores in the subdomain, so that's not an issue.
As far as I know the only recent change was updating the rails version to 3.0.20, which leads me to suspect there's something amiss there. Since rails 3.0.20 was created to address a security concern, I'm curious if the security changes made IE think the app is a security violation and will no longer accept cookies from it? However, I even tested IE where I told it to accept all cookies from every site, so I'm not sure what's going on here.
Anyone seen this issue recently or aware of what may be going on?
There's no stack trace or errors to show; cookies just aren't being set, which results in a standard "record not found" error.
Related
I have built a cookie consent module that is used on many sites, all using the same server architecture, on the same cluster. For the visitors of these sites it is possible to administer their cookie settings (eg. no advertising cookies, but allow analytics cookes) on a central domain that keeps track of the user preferences (and sites that are visited).
When they change their settings, all sites that the visitor has been to that are using my module (kept in cookie) are contacted by loading it with a parameter in hidden iframes. I tried the same with images.
On these sites a rewrite rule is in place that detects that parameter and then retracts the cookie (set the date in the past) and redirects to a page on the module site (or an image on the module site).
This scheme is working in all browsers, except IE, as it needs a P3P (Probably the reason why it is not working for images is similar).
I also tried loading a non-existent image on the source domain (that is, the domain that is using the module) through an image tag, obviously resulting in a 404. This works on all browsers, except Safari, which doesn't set cookies on 404's (at least, that is my conclusion).
My question is, how would it be possible to retract the cookie consent cookie on the connected domains, given that all I can change are the rewrite rules?
I hope that I have explained the problem well enough for you guys to give an answer, and that a solution is possible...
I am still not able to resolve this question, but when looked at it the other way around there is a solution. Using JSONP (for an example, see: Basic example of using .ajax() with JSONP?), the client domain can load information from the master server and compare that to local information.
Based on that, the client site can retract the cookie (or even replace it) and force a reload which will trigger the rewrite rules...
A drawback of this solution is that it will hit the server for every pageview, and in my case, that's a real problem. Only testing that every x minutes or so (by setting a temporary cookie) would provide a solution.
Another, even more simple solution would be to expire all the cookies on the client site every x hour. This will force a revisit of the main domain as well.
Hi I have created a package for my metro application.Here while developing my app I have given a Url static,But I need to change Url dynamically whenever my requirement changes.So that what should I do?Can anyone help me.
Thank you.
If your requirements are changing, then you might be releasing a new version of your application anyways, so it might make sense to just update your app package manually each time the URL changes and re-release it. This is definitely the simplest solution if your URL is going to change infrequently. You would also need to handle deprecating the old URL in this instance or at least gracefully handling when the old URL is shut down so that users who have not upgraded to your latest version still don't have a horrid experience.
If that is not a viable option, then it gets a bit messier from here on. Really the only way to change the stored URL would be to have some sort of secondary service or authority on what the current URL is. The app would then do one of the following (or a combination):
Query the URL authority for the current URL before making any requests.
Attempt to make the request to the current stored URL, if it fails, query the URL authority for the new URL and store that URL.
Currently Azure Websites don't allow custom SSL certificates, but they have wildcard SSL enabled for the *.azurewebsites.net domain. I need a secure login form for my web app, but with no custom SSL, it appears that I'm SOL.
Is there any kind of workaround for this? Would it be possible somehow to have a login form at https://mydomain.azurewebsites.net that creates a forms authentication ticket that will then work at http://mydomain.com?
Couple of months ago I had exactly the same problem i.e. application was built on Azure Websites, had to run on custom domain other than *.azurewebsites.net and had to allow secure login process.
Workaround for that we used was to embed an iframe (using secure protocol and .azurewebsites.net domain name e.g. https://oursite.azurewebsites.net/login) into non-secure page on custom domain (e.g. http://mysite.com/login). And entire login process was performed in the iframe.
There is one thing which you should be aware of, namely, lots of customers checks whether the page where they provide their credentials was using secure connection or not. In our case, secure iframe in non-secure page was causing lots of customer complains. Workaround for that problem was to put a message confirming that the login process uses secure connection. The message made some improvements, however, still certain number of customers complains remained.
I hope that will help.
This isn't really an answer to your question, but Microsoft are very aware that custom mapped SSL to websites is one of the most requested features for Azure websites and they have said they are working on it.
Scott Hanselman himself confirms it here
In the meantime, Tom's answer is a perfectly valid workaround.
One thing I would be very wary of though is with something Tom brings up: the security warning that the browser will present. You'd be amazed how many people freak out when they see that message and don't go any further! We have a fairly active ecommerce site and there have been occasions where we have accidentally used a none secure image path on an SSL page and we have always received emails from customers asking if our site has been hacked or similar!
The disclaimer that Tom mentions is a good idea, but I think it will still put some people off.
I am working directly with the WAWS team right now to produce some public guidance for this. A GitHub repository with the requirements is currently being evaluated by the team (I sent it over to them literally 1 hour ago). Hopefully, the solution will be approved and made public within a few weeks.
I can say this - the workaround won't be fully supported or much custom guidance given on its usage aside from the repository and accompanying documentation. SSL is, literally, the #1 priority for the product, and hundreds of people are working insane hours to make it happen for everyone. This workaround should also be considered temporary, as you'll no longer need it once the full SSL functionality is launched.
I am using the Drupal Secure Pages module to secure sensitive pages (such as login and admin pages). I am running into two issues with this:
I am able to login securely on the login page using https. However when I traverse to a non-secure page such as the home page, the browser completely forgets that I am logged in (instead of my username, the login link shows up). (The problem goes away as soon as I disable the Secure Pages module.)
Since the secure pages are getting their images using non-secure URLs, the browsers are showing warning messages. For example, "The site uses SSL, but Google Chrome has detected insecure content on the page."
Is there any clean solution to these issues?
The recommendation here was to make the entire site secure, which seems like an overkill for my site (essentially an open source community). Having said that, how much of a performance hit does something like this incur, roughly?
Thanks.
I was able to solve the issue with non-secure pages not remembering the login state. The solution was to add this line to sites/default/settings.php: $conf['https'] = TRUE; You can see the details here.
As far as I can tell, issue #2 was a browser caching issue. I cleared all the caches and cookies and the problem seems to have gone away!
I have a login screen which I'm serving over SSL. The user fills in their login/password, this gets POSTed to the server. At this point I want to jump out of SSL, so I redirect them back to the same page with no SSL.
This causes the browser to show a warning dialog "You are about to be redirected to a connection that is not secure". How can I avoid this? I've been plenty of sites like yahoo mail, and gmail that give you an SSL page for login, then send you to a non-SSL page after this.
Secondary question: what's the purpose of this dialog? It's trying to warn me about some nefarous purpose - but what's so bad about redirecting someone to a non-SSL page? I don't get a warning when I'm on an SSL page and click a non-SSL link. What's different about redirecting someone?
I'm doing this in ASP.NET 2.0 - but I figure this is a generic web-dev question.
UPDATE SUMMARY: It seems the popular answer is "DON'T AVOID IT". I can understand that a user should get a message when security it being removed. But I don't get a dialog when I follow a link and security is removed, so at the very least I'd say this is inconsistent.
The dialog / browser versions. I actually don't see the dialog in IE7/FF3 (maybe I've clicked a checkbox preventing it). More importantly the client DOES see it in IE6 - with no checkbox to remove it (yes, I know IE6 is old and crap).
Firefox2: FF2 http://img521.imageshack.us/img521/8455/sslwarning.jpg
IE6:
The alternative: make the entire site SSL, never redirect the user out of SSL. I could handle that. But I've got a semi-technical client who has some fairly good points:
"SSL is going to cause an increase in traffic / processing power". I don't really buy this, and I don't think his site is every going to require more than one box to serve it.
"Yahoo does it. Yahoo is a big technical company. Are you smarter than Yahoo?"
I'm going to try sway the client over to an entirely SSL site. I'll argue Yahoo's approach made sense in 1996, or for a site that is MUCH more popular. Some official links explaining why this dialog happens would help (i.e Jakob Nielsen level of authenticity).
I've hit this same problem a while back. So I had a look inside fiddler to see how yahoo mail does it. Here's the step I saw (and used on my site):
User fills in SSL encrypted form, and POSTs to the server. Server authenticates, and spits out some script to redirect the client
<script language="JavaScript">
<!--
window.location.replace("~~ non-SSL URL ~~");
// -->
</script>
I figure the client side code is there to avoid this dialog.
"How can I avoid this?"
You shouldn't!
Although you could try that with JavaScript. This might work on some browsers and fail on others.
"What's the purpose of this dialog?"
It warns because switching between SSL and non-SSL on websites is usually unexpected by the user. A warning about the "non-SSL to SSL" is not emitted since it increases security and privacy. However, when security is suddenly decreased, the user should notice that quickly, in order to avoid a false feeling of security. In fact, redirecting to a non-SSL site is sometimes used in XSS/MITM attacks.
"SSL is going to cause an increase in traffic / processing power"
This is nonsense. It might be true for sites full of big, static content. However, for normal dynamic web applications, encryption is very cheap compared to business logic, database access, etc.
There is an urban legend saying that SSL-content is not chached by browsers. See "Will web browsers cache content over https" for more information.
"Yahoo does it. Yahoo is a big technical company. Are you smarter than Yahoo?"
Some rhetoric counter-questions:
Are you a big technical company like Yahoo?
Did being a big technical company prevent Microsoft from producing crappy software?
Do you have to support crappy old (SSL-broken) browsers, as Yahoo has to?
The attack this is preventing against is a man-in-the-middle SSL session strip. The message is there with good cause.
As for the purpose: It's to make you aware that your connection won't be SSL encrypted anymore. You may have seen before that the connection is encrypted and may think that it still is, so this warning says "Just to be clear, whatever data you send from here on will be plaintext".
As for how to suppress it: AFAIK you can't, it's a browser thing, what would be the point of the message otherwise? Even though there are workarounds like client-side redirects, I don't think you should try to work around client "problems" like this. If the browser chooses to be verbose, let it. There's a "Don't show this again" checkbox on the dialog after all If the user wishes to suppress this message he can easily do so, and maybe he actually likes to see it.
Also, IMHO, if the browser was worth its salt it would still pop up this warning, even if you employed client-side redirect tricks.
Use SSL for the whole page in the first place!
There's nothing wrong with SSL. You should provide user privacy everywhere, not only on login. It makes sense an the whole site. So simply redirect all non-SSL pages to SSL pages and keep everything SSL.
Just point your client to the latest attacks against mixed mode content (lookup CookieMonster on fscked.org) and proxy attacks (against sites available both in http and https, lookup Pretty-Bad-Proxy). He might reconsider.
It is much easier to get security right if you only deal with one protocol without mixing the two. SSL adds a bit of overhead, but it is nothing compared to the cost of a breach.
Gmail, yahoo, etc. use SSL for an encrypted iframe, which authenticates, but there's none of the in-page redirection you're talking about. The whole page isn't encrypted for these login systems.
read:
http://support.microsoft.com/kb/883740
which says that this is fixed in a hotfix or with a changed registry setting. However, not all the IE6 cpu's we use have this problem, nor do their registry settings correspond to what this article says they should. Also some that give the msg are XPsp3 and IE6 sp3.
We have an https log in screen that uses code to log into 15 other (http) domains and some of our IE6 users have to click 'Yes' 15 times. This is inacceptable to them.
No, we cannot control what browser all our users use. Some are not compatible with upgrade to IE7.
We are looking for some config attribute for each user to adjust that will suppress this msg. We've identically configed a 'bad' browser with settings that match one that does not give the msg. Internet and Intranet Security and Advanced settings and Proxies (none).Also Network connections. No joy so far.
Any ideas?