I have an application I would like to force SSL on the login page and on the page that the CC is entered on. I would prefer to keep the rest of the application free of SSL.
I have the code working to force SSL on certain pages, and remove SSL on others. The problem I have is that if I log in with SSL enabled the user is only authenticated on the pages that are SSL. The reverse holds true as well, if the user logs in without SSL they are only authenticated on pages without SSL.
What can I do to have this persist between the two. Is this using cookies or the session?
Thanks!
Classically, one would use the session for this.
You can use cookies as well.
In either case, you need to keep in mind that they can be spoofed, so you want to only keep a "logged in" token that you can verify on them.
Related
I have a website where users can post ads and view them. I am using ASP.net build it. So normally site is free for to view ads. But if anybody wants to post an ad he or she needs to be a registered user. So if an user try to Post an ad without logging then he will be redirect to login page. So I want to enable SSL for login page to securely transfer information over the internet.
Here few things you should know.
I just only need to secure the user name and passwords.
Ads post by users are not sensitive data. So it is OK if it transfer through non secure path.
I dont want to enable SSL for every page. Because it will slow down page loading and it is a CPU intense task.
So how to achieve this? Do I need to maintain the HTTPS state after user logged under SSL connection until he post articles and until he log out?
Cant I just secure the login page for authenticate the user and then go with normal pages? Keep in mind that I need to keep the logged information because I saw in an another blog that saying When you go from HTTPS to HTTP all the states are being lost. Is that true?
So Help me here.
Thank you very much.
You should maintain SSL for every page once a user is logged in so that you can use secure cookies for the authentication cookie. This can be set using the requireSSL="true" in the web.config (MSDN doc). You definitely should use secure cookies for authentication, and you'll only be able to utilize that cookie over HTTPS.
Or as Scott Hanselman put it in this seriously old blog post:
In order to prevent Session Hijacking, when you've got a secure site,
it's a good idea to mark your cookies as "secure," meaning that they
can't be accessed over HTTP. This prevents folks from being issued
cookies over HTTPS then switching to HTTP in order to access the
cookie with sniffers or other evil.
This question has also been covered at Information Security Stack Exchange and Programmers Stack Exchange.
More Reading: OWASP Top 10 for .NET developers part 9: Insufficient Transport Layer Protection
I'm looking to put SSL into place to prevent cookie replay attacks on our site.
The site is using .NET forms authentication. Do I just need to enable SSL for the login page or would it be every page behind the forms authentication that needs to be secure?
THanks
You would need to enable SSL for every page where the browser is instructed to send the authentication ticket cookie. By default, that would mean every page on your website, although when writing the cookie to the browser you can instruct it to only send it over HTTPS or to limit it to certain paths.
But in general it would mean SSL protecting every page on your site, not just your sign in page.
.Net websites transfer non only the viewstate but any cookies back to the server on postback. This impacts your security in that someone using firesheep (or a similar tool) could easily pick up an authentication cookie, not on login, but when a user postsback via a button press, or ajax event several pages into the application.
If you have access to IIS you can not only enable SSL use, but force it.
We have a non-SSL ASP.NET web app that allows a user to login (ASP forms authentication, inproc).
Once authenticated, we redirect their browser to an external, SSL secured page on another web site / domain altogether that we do not control.
The client is redirected back to a pre-configured url on our original http web app when done.
However, the customer is then asked to "re-login" again on our side which is undesired...
It seems the forms authentication cookie is destroyed when transitioning between HTTP and HTTPS and back again.
How can I keep the forms authentication cookie alive so that the customer does not have to re-authenticate on the round trip?
It's not being destroyed; you're not authenticating on your domain, so the cookie's not being set on your domain, and thus requests on your domain will not contain said authentication cookie.
This is GOOD. If this didn't happen, then every cookie from every domain you ever visited would get sent with every request. Which is obviously 1) crazy and 2) a security hole. Setting a cookie on mydomain.com should never be visible to pages on myotherdomain.com.
If you're using a 3rd party authentication system, like google, facebook, etc, they'll all have some sort of callback token that you'll have to process and set your own cookies.
Consider to set cookie's domain property for your cookies with more specified can be found here or try this code:
Response.Cookies["your_cookie_name"].Domain = "yourdomain.com";
You're looking for a Single Sign On solution.
It might be a little overkill for your problem, for which you might just want to get the same domainname. But if that isn't an option you might want to take a look at:
Windows Identity Foundation
I have a virtual folder containing an administration application, like
https://www.mysite.com/alpha
which requires SSL. In the IIS manager properties for the folder, under "Authentication and access control", Anonymous Access is disabled and "Authenticated Access" is set to "Integrated Windows authentication."
When I connect to the site in Chrome, I receive two login boxes. The first is from mysite.com/alpha:443, and the second is from mysite.com/alpha:80. Firefox appears to re-send my credentials for the second box so it is never shown.
Any ideas why I'd be required to log in twice?
If you require SSL for authenticated users on your website (for any reason), then the best solution is to always have your "Login" page on https://. That way when they log in, they are instantly secure. The reason for this is because of the native design of SSL. It separates/secures it's self from the non secure version by not passing authentication states between http and https.
you will also have to write some logic to redirect returning authenticated visitors to the secure page (IE: visitors who can return authenticated from a cookie).
EDIT:
Since your using windows authentication, it's probably easiest to simply redirect ALL incoming http traffic to https. This means your entire site will be over SSL and will be inaccessible via http (other than to redirect to https)
I wrote a Blog Post on forcing a website to use WWW in the web address, but it can also be ported to forcing https.
Yep,
The one uses SSL, the other not.
therefore, you are not allowed to share the credential cache from a Secure session, with the one of the unsecure session.
if you require SSL, then directly redirect the users to the SSL website.
I would like to create web application with admin/checkout sections being secured. Assuming I have SSL set up for subdomain.mydomain.com I would like to make sure that all that top-secret stuff ;) like checkout pages and admin section is transferred securely. Would it be ok to structure my application as below?
subdomain.mydomain.com
adminSectionFolder
adminPage1.php
adminPage2.php
checkoutPagesFolder
checkoutPage1.php
checkoutPage2.php
checkoutPage3.php
homepage.php
loginPage.php
someOtherPage.php
someNonSecureFolder
nonSecurePage1.php
nonSecurePage2.php
nonSecurePage3.php
imagesFolder
image1.jpg
image2.jpg
image3.jpg
Users would access my web application via http as there is no need for SSL for homepage and similar. Checkout/admin pages would have to be accessed via https though (that I would ensure via .htaccess redirects). I would also like to have login form on every page of the site, including non-secure pages. Now my questions are:
if I have form on non-secure page e.g http://subdomain.mydomain.com/homepage.php and that form sends data to https://subdomain.mydomain.com/loginPage.php, is data being send encrypted as if it were sent from https://subdomain.mydomain.com/homepage.php? I do realize users will not see padlock, but browser still should encrypt it, is it right?
EDIT: my apologies.. above in bold I originally typed http but meant https, my bad
2.If on secure page loginPage.php (or any other accessed via https for that instance) I created session, session ID would be assigned, and in case of my web app. something like username of the logged in user. Would I be able to access these session variable from http://subdomain.mydomain.com/homepage.php to for example display greeting message? If session ID is stored in cookies then it would be trouble I assume, but could someone clarify how it should be done? It seems important to have username and password send over SSL.
3.Related to above question I think.. would it actually make any sense to have login secured via SSL so usenrame/password would be transferred securely, and then session ID being transferred with no SSL? I mean wouldnt it be the same really if someone caught username and password being transferred, or caught session ID? Please let me know if I make sense here cause it feels like I'm missing something important.
EDIT: I came up with idea but again please let me know if that would work. Having above, so assuming that sharing session between http and https is as secure as login in user via plain http (not https), I guess on all non secure pages, like homepage etc. I could check if user is already logged in, and if so from php redirect to https version of same page. So user fills in login form from homepage.php, over ssl details are send to backend so probably https://.../homepage.php. Trying to access http://.../someOtherPage.php script would always check if session is created and if so redirect user to https version of this page so https://.../someOtherPage.php. Would that work?
4.To avoid browser popping message "this page contains non secure items..." my links to css, images and all assets, e.g. in case of http://subdomain.mydomain.com/checkoutPage1.php should be absolute so "/images/image1.jpg" or relative so "../images/image1.jpg"? I guess one of those would have to work :)
wow that's long post, thanks for your patience if you got that far and any answers :) oh yeh and I use php/apache on shared hosting
If the SSL termination is on the webserver itself, then you'll probably need to configure seperate document roots for the secure and non-secure parts - while you could specify that these both reference the same physical directory, you're going to get tied in knots switching between the parts. Similarly if your SSL termination is before the webserver you've got no systematic separation of the secure and non-secure parts.
Its a lot tidier to separate out the secure and non-secure parts into seperate trees - note that if you have non-SSL content on a secure page, the users will get warning messages.
Regards your specific questions
NO - whether data is encrypted depends on where it is GOING TO, not where it is coming from
YES - but only if you DO NOT set the secure_only cookie flag - note that if you follow my recommendations above, you also need to ensure that the cookie path is set to '/'
the page which processes the username and password MUST be secure. If not then you are exposing your clients authentication details (most people use the same password for all the sites they visit) and anyone running a network sniffer or proxy would have access.
Your EDIT left me a bit confused. SSL is computationally expensive and slow - so you want to minimise its use - but you need to balance this with your users perception of security - don't keep switching from SSL to non-SSL, and although its perfectly secure for users to enter their details on a page served up by non-SSL which sends to a SSL page, the users may not understand this distinction.
See the first part of my answer above.
C.