My site has https sections (ssl), and others are regular http (not using ssl).
Are there any issues going from ssl to non-ssl pages?
Some times that user will click on a link, which will be ssl, then click on another link that leaves https to http based urls.
I understand that when on a ssl page, all images have to be also served using https.
What other issues do I have to handle?
I recall that a popup displays sometimes telling the user about a security issue, like some content isn't secure, I am guessing that is when you are under https and the page is loading images that are not under https.
Mixing is generally a bad idea just because it tends to detract from the user experience and coding around the differences makes the application that much harder to maintain. If you need SSL for even a little of the site, I'd recommend putting it all behind SSL. Some companies use a hybrid for the public "low end" site and SSL for the actual customer experience.
As Miyagi mentioned, session sometimes gets goofy, but it's not impossible if you keep the session stored in an external location. These means all session objects must be serializable, compact, etc, and it also means you'll need to manage the sessionid in a common browser element (cookie is usually the safest).
There is a good article on The Codeproject about this theme. The author encapsulates the switching by code and configuration. Not so long ago I tried to go this way - and stopped going it. There were some handling problems. But the main reason for stopping was the bad user experience mentioned by Joel before.
If you are using sessions on your site you will lose any session information when switching between ssl pages and non-ssl pages.
Related
We are third party widget proving services company for payment (for example). PARENT website can add our widget built in ASP.net MVC -5 in their iframe. Our widget URL is completely secure (https) but the parent website where its getting embedded is not. Now that parent website is used by 100's of people to make the payment. Problem is they see that the whole website is not "SECURE". they cannot see that the iframe where they are making payment is secure. Is there any way I can solve this issue. How can I make the parent website detect that the iframe its using is HTTPS hence make the whole page as secure. Or if there is another way to handle it then please guide me.
Parent - http
iframe - https
users : scared of making payments
You can't, because it's in fact not secure. HTTPS only provides protection if it's HTTPS all the way. If any part drops to HTTP, the whole channel is insecure.
Tell your clients to implement SSL to protect their users. If they choose not to, there's not really anything you can do about it. It might be worth updating your terms of service to indemnify your organization against damages should your clients not utilize SSL and some sort of breach should occur because of that, when using your widget. Basically, transfer the legal responsibility to the client.
I am very green to developing a web front-end.
I wanted to create an eternally hosted site that will pull a collection of resources.
This is the scenario:
I want to "embed" pages within the web app. My thoughts, make the site called look exactly like it does originally, but keep the navigation header above. I have googled quite a bit to try and get a good direction in where to take this. From what I have found, iframe is the way to go.
The issues:
We host Dell Open manage Essentials on one of our servers. The only way to access this is through https://ome/. We currently do not have CA in place, therefore the certificate that is currently on the server is expired. This error is accurate due to the lack of a valid certificate.
My question:
1). Is iframe the right approach to this situation.
2). How do I bypass, or at least give the user the ability to continue to the embedded site? These sites are all internal.
You can't decide for a user to display content for a site with an expired certificate. The user has to accept that risk. That's why the browsers now immediately flag pages with expired certificates and make it super-obvious. There are few cases where you'd actually want to bypass this - so few, that the common browsers just don't make exceptions.
The VERY difficult way is to route your IFRAME url through a proxy that doesn't care about expired certs.
The less difficult way is to spend $50 on a certificate. Or you can even get a free one (YMMV) at https://startssl.com (at your own risk. I am unaffiliated.)
Our product has a collection of sites and the main page contain 3 iframes which loads these different web sites. We are going to enable SSL on all the site. We allow html user data to be displayed in our systems. Currently we put this on hold since we experience Mixed Content Issues because of following reasons.
Some of the elements in the user’s data which refers http content.
Ex: img, js etc
Some of the third party which loads in our iframes.
(Different content provider)
We thought of developing our own web proxy, we do have concern about performance as well as expensiveness of this solution. Can anybody tell what are the available solutions for the Mixed Content Issues and available third party web proxy where we can buy?
The best solution would probably be to purchase remote servers from some service (google will give you millions of hits) and then set up a CGI script to load the insecure content on to the remote server, cache it, and then serve that content. That way your users are protected from 3rd parties knowing what they look at and if you set up your SSL certificate on those servers then you can easily get around the mixed content.
That being said, there will be a big hiccup when you start loading your user's content off the remote server as it will have to start caching everything.
Using a web proxy is not a good solution for following reasons:
We have performance problem and expensiveness of this solution like you said.
The most problematic of this solution is we still have security vulnerability. The point of using https on a site is to prevent the site from sniffers and man-in-middle attack. If you use a web proxy, the connection between your browser and your proxy is still vulnerable.
I'm not sure whether a web proxy would help in anyway because the browser always interprets these links as http even if your server is SSL enabled.
For more information about mixed content: https://developer.mozilla.org/en-US/docs/Security/MixedContent
The correct way to deal with this situation is you must modify all your links to load content with https. Or a better way is to use protocol relative url
<script src="//scripts/main.js"></script>
Mixed content warnings are built into browsers by design to indicate exactly what they mean. You can turn them off in settings or just click ok, so by throwing the mixed content, you're degrading UI, but not functionality.
A few things come to mind, since the providers can't change their content:
Write a back end scraper for your app that scrapes the web page and servers the content locally over https.
Don't render the content immediately, make the user click on it to open the iframe so that at least your page loads and you can warn the user (optional).
Enhance either solution by checking for https first, a lot of websites have 80 and 443 both open, but as you pointed out, not everybody.
Not too familiar with this one, but you can maybe even have the server instance of internet explorer open the pages and cache them for you simplifying the scrape.
If I was writing this, I would check for https when possible and allow the mixed content warnings as all that's by design.
Our operator has implemented a Round Robin load balancer on our web portal and it seems to be causing some problems I can't get to the bottom of.
I'm able to identify which server we're on and as we navigate around the site we stay on server A. If I leave it for 5 minutes and try another page I'll get pushed to server B, logged out and shown the log in page.
I've got them to make sure the MachineKey in the machine.config is the same on both servers and I've tested locally that the session isn't being used - I can turn the session off completely locally and it still works. I've verified on both servers it is creating an ASPXAUTH cookie on the domain so we should be classed as authenticated on both servers - but keep loosing my authentication every time I change server.
Any ideas on what could be causing the logging out? I'm guessing it's my misunderstanding about how ASPXAUTH works.
Sessions are handled separately from Forms Authentication. There is a good explanation of this here.
The most common reason for Forms Authentication failures on load-balanced environments is lack of synchronization of the MachineKey element. You've stated that you've got the server operators to ensure that the MachineKey is synchronized, but have you verified this yourself in some way? Is this the case on ALL the web servers? From previous dealings with a couple of commercial web hosts, I've found that it is (unfortunately) difficult to take their assurances at face value.
Another thing to check is if the FormsAuthentication configuration (timeout, path, name, etc.) is the same on all of the hosts.
Are the patch levels the same on all of the hosts? You might want to see if the compatibility switch mentioned here is applicable in your situation.
Assuming that the hosting setup is correct, maybe you have initialization code on the page that logs you out if some condition is not fulfilled?
Try to take a look at the server logs and trace the sequence of HTTP requests involved during a failed page request. That might produce a clue.
Edit: This guide to troubleshooting Forms Authentication problems is detailed, and quite helpful: Troubleshooting Forms Authentication
Check for any other application functionality which depends on cookies. The web server on Server B will not recognize cookies that came from Server A. If any part of your authentication depends on cookies being populated, then that could cause your problem.
You have probably already ensured that the domain used for cookies is the same on all of the load balanced servers, but I thought I'd mention that. If the domains aren't compatible, then the browser will simply not send cookies to the server.
I starting too look at a bit of security into my site. My site I would consider a very low security risk as it has really no personal information from the user other than email.
However the security risk will go up a bit as I am partnering with a company and the initial password for this companies users will be the same password they use essentially to get onto the network and every piece of software.
So I have up my security( what is fine by me...I wanted to get around to this anyways).
So one of my security concerns is this.
A user logs in.
form submit(non ajax is done).
Password is hashed & Salted and compared to one in the database.
Reject or let them proceed.
So this uses no jquery or ajax but is just asp.net mvc and C#. Still if my understanding is right the password is sent in clear text.
So if a use SSL and I would not need to worry about that is this correct?
If that is true is that all I need?
Second the user can change their password at anytime. This is done through ajax. So when the password is sent it is sent in clear text( and I can verify this by looking at firebug).
So if I have SSL enabled on this page is that all I need or do I need to do more?
So I am just kinda confused of what I need to make the password being sent to the server(both ajax and full post ways secure).
I am not sure if I need to do more then SSL or if that is enough and if it is not enough what is the next layer of security?
If you use HTTPS/SSL for your page, your AJAX requests will (by default) be handled the same way, so yes this would eliminate all the clear-text issues and you'll get all the security benefits of SSL with your AJAX requests as well.
I would say for most sites this provides a sufficient level of protection, as much as is sane anyway. Keep in mind that nothing is 100% secure (go to any mainstream conference, the security talks will scare you :), it may be 100% secure so far, but it rarely remains that way. That being said, SSL is the most effective security mechanism/deterrent readily available, and it's the best route to go.
Also, SSL is the cheapest in terms of development time, you may not need to change not one line of code in your app to get it working, just make sure to keep your certificates valid/up-to-date.
if you are using SSL your data sent accross the server is well taken care by SSL let it be a ajax hit or simple hit