I have a website that came with a SSL site for HTTPS but its on a different server. Example being
my website:
http://example.com
my SSL site:
https://myhostingcompany.com/~myuseraccount/
So I can do transactions over HTTPS and we have user accounts and everything but it is located on a different domain. The cookie domain is set for that one.
Is there a way I can check on my actual site to see if a cookie is set for the other one? And possibly grab its data and auth a user?
I think this violates a major principle of security and can't be done for good reasons, but am i wrong? is this possible?
You can setup a service on either site to handle RPC via HTTP POST requests. You can make it require some sort of session that can only be created by your sites. However, whatever can be accessed over that shared session on the HTTPS site will have no guarantee of confidentiality or integrity.
Related
I have an application that uses account slugs for various accounts, of the format myapplication.com/{SLUG}, similar to how Github does it. This domain has an SSL cert and everything is fine.
However, I have some clients who purchased domain names that they give to clients that forwards them to their account page on my application.
For instance, let's say "John Smith" purchased domain johnsmithisawesome.com and he sets that domain up to forward to myapplication.com/johnsmithisawesome. It's mostly for branding purposes, so John can give out a cool/catchy domain name to clients which eventually sends them to my application.
Note that this redirect only happens once. I am not using it as a proxy, it is just a convenience method for folks to use a catchy domain that fully redirects them to the application domain. After that initial redirect, the client will be on the application domain and all requests go directly to the secured application, and they should not reference the insecure domain any more.
Also note that there are no security credentials being passed back/forth to the insecure domain. If the client has to login, they are doing it directly on the application domain and are not interacting with the insecure domain at all.
The flow essentially works like this:
User visits johnsmithisawesome.com in their browser
DNS for johnsmithisawesome.com uses an HTTP REDIRECT that points to myapplication.com/johnsmithisawesome
User's browser URL is now at myapplication.com/johnsmithisawesome
All further requests go through myapplication.com/johnsmithisawesome, there are no further requests going through johnsmithisawesome.com
I'm hoping this is explicitly clear in what I'm trying to accomplish, I know I'm not as well versed in the terminology.
Is there any security risk with not having an SSL cert on the domain that just forwards them to my application?
My assumption is it doesn't matter, because the actual application itself is protected with SSL (or TLS as the new standard), and I can't think of any security risk with using a domain to just forward, but wanted to check with some folks who know more about this than I do :)
Unfortunately, the short answer is yes, if you want to secure it, you need a separate SSL cert for the other domain too.
Consider the following. Alice (the enduser) enters johnsmithisawesome.com in her browser, the browser makes a request. A man-in-the-middle attacker Mallory captures the request, makes a request to https://yourapplication.com/johnsmithisawesome, which creates an SSL session between Mallory and your application. When Mallory receives a response, transforms all references to your application to http://johnsmithisawesome.com and returns the resulting (modified) page
to Alice.
What your application can see is t here was a request on https which it served, all is good. What Alice can see is she entered a domain and got the results, even the domain name in the URL bar matches what she wanted to see. What Mallory can see is all (presumably confidential) traffic between Alice and your application. The only hint for Alice is that there is no indication of SSL in the browser, but most users won't spot that.
This is called SSL Stripping, and there are ready-made tools to pull this off with a few clicks. Your scenario is a little bit special compared to the original idea, but it just helps the attacker.
In fact, Mallory doesn't even need to do this. Without a certificate for johnsmithisawesome.com, Mallory can just replace the response and that's it, he doesn't need to strip SSL strictly speaking, because there wasn't any SSL. :)
This is what the HSTS response header was invented for, and should be sent by both your application and johnsmithisawesome.com during redirection.
As long as you will not access the forwarding domain with HTTP you will technically not need to have a certificate, i.e. the redirect will work. Only, when you want to access the forwarding domain with HTTPS you technically need a certificate for this domain, even if all what is done on this domain is to forward to somewhere else. Otherwise the end user will get warnings in the browser and the forwarding will not happen.
But, even if it is not technically required it might still make sense to make use of HTTPS on the forwarding domain for security reasons.
All further requests go through myapplication.com/johnsmithisawesome, there are no further requests going through johnsmithisawesome.com
Note that this is only the technical view of what works and not works.
I interpret this as there is only a single requests to the clients domain which results in a redirect to the final domain. And that no sensitive data will be shared with the clients domain but only with the final (secured) domain.
In this case the main attack vector is an man in the middle attack which changes the target of the redirect, for example from myapplication.com/johnsmithisawesome to an attacker controlled domain and URL like myapplication-secure.com/johnsmithisawesome. With a properly named domain the attacker can surely trick the user into believing that he reached the proper site.
Such attack can be mitigated by protecting the redirect with HTTPS and security-wise this is the best option. But this means that the client should access the clients domain with HTTPS in the first place, because otherwise the attacker could hijack the initial request and change the redirect. If one accepts this risk and hopes that attacker is not present during the first request one might either redirect to HTTPS and add an HSTS header to enforce future use of HTTPS on the clients domain or one could make a 301 redirect to the final domain instead a 302 redirect. With 301 the browser will cache the redirect and will not ask the clients server again but go straight to the final domain on the next visit, thus bypassing an attacker which managed to intercept requests to the clients domain.
DNS for johnsmithisawesome.com uses an HTTP REDIRECT that points to myapplication.com/johnsmithisawesome
That's not how it works.
Technically DNS can not issue HTTP redirects. DNS is only used to resolves the hostname to an IP address. The HTTP server at this address then can do the redirect at the HTTP level.
Some DNS providers still offer such a HTTP redirect. But this works by resolving the hostname to an IP address the DNS provider owns and running a special HTTP server at this IP address which then does the configured HTTP redirect. Sometimes they let the customer configure if this will be a 301 or 302 redirect and sometimes not. And usually there is no way for configure a certificate in this kind of setup anyway.
We are evaluating feasibility of the following solution for Single Sign On.
Scenario.
Website domain. https://www.example.com
[SSL using multi-server wildcard certificate]
Hosted on Server 1.
Other portal. https://portal.example.com
[SSL using the same certificate (multi-server wildcard certificate)]
Hosted on Server 2.
Solution:
The intention is to share a cookie between the www.example.com and the portal.example.com subdomains, however, for this to work the SSL protocol needs to satisfy the following requirements:
Continue to block Man-in-the-middle attacks.
Encrypt/Decrypt in the same manner for both Server 1 and Server 2. So that they can get the same information from the cookie.
Question is: Is there any limitations in terms of private keys or the SSL protocol perse that will make the solution above not feasible?
Thanks,
Yes, your solution will work and will mitigate most MITM attacks provided the CA that your certificates are purchased from are trusted by the client browsers.
If the cookie is set with domain example.com it will be shared between www.example.com and portal.example.com. It is also advisable to set the Secure flag to make sure it cannot be transmitted over plain HTTP. I am assuming both www.example.com and portal.example.com both have a server-side mechanism to validate the cookie value to authorise each request.
RFC 6265 states:
The Domain attribute specifies those hosts to which the cookie will be
sent. For example, if the value of the Domain attribute is
"example.com", the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, www.example.com, and
www.corp.example.com.
The old RFC 2109 specified that you needed a . before the domain, however 6265 overrides this. This means if you want to share cookies and make it compatible with very old browsers you should set the cookie with domain .example.com rather than example.com. There is nothing to lose by doing the former as newer browsers will simply ignore the dot.
In your solution, both Server 1 and Server 2 will receive and be able to decrypt the cookie. Note there is not requirement for both servers to have the same certificate - they will both decrypt the SSL session independently using their installed private keys (or rather a shared symmetric key that is transmitted using their installed private keys - to be precise).
However, using a wildcard certificate for *.example.com will be cheaper as the same certificate can be installed on both servers.
One great advantage of using Azure Websites is that I can get secure HTTP (HTTPS) without doing nothing: I simply type https://xyz.azurewebsites.net and it works. I don't have to worry about certificates because I use the subdomain that Azure gives me (in the example it would be xyz)
So, what I usually do is that people come by through some registered domain I have, eg. http://www.my-application-homepage.com, and there, if they want to use my application, I redirect them to the subdomain at azurewebsites.net, using HTTPS.
Now, having said that:
I'm in need of upgrading to Azure Cloud Services or Azure Virtual Machines, because these have capabilities that Azure Websites don't . These two also offer a free subdomain: xyz.cloudapp.net, but my question is: will I get HTTPS there too? and how?
I searched in google for some cloudapp examples and what I tested was the following:
1) Connect through HTTP (ie. type http://xyz.cloudapp.net). Result: worked
2) Connect through HTTPS (ie. type https://xyz.cloudapp.net). Result: didn't work (chrome gave ERR_CONNECTION_TIMED_OUT)
No. HTTPS is not offered for .cloudapp.net domain as of today. Also since you don't own .cloudapp.net domain, I don't think you can buy a SSL certificate for that. If you want you could create a self-signed certificate and use that.
I would walk through the documentation listed here:
http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Since you're getting a timeout with HTTPS (rather than a certificate error), check that you have a HTTPS endpoint defined in ServiceDefinition.csdef.
Additionally, be aware that the redirect-to-subdomain approach isn't much more secure than using a self-signed certificate. The reason browsers reject self-signed certs is that they are vulnerable to spoofing attacks: a user can't detect if an attacker has, for example, hijacked the DNS to point to his IP address instead of yours, where he hosts a facade of your site that just collects passwords or whatever.
In your scenario, the cloned site could redirect to another a second clone, one that is a facade of your cloudapp.net site. It could be even be secured with the attacker's SSL certificate. Unless the user was trained to recognize the host name of the real cloudapp.net, she wouldn't know she was on the attacker's "secure" site.
** Update: This method is not valid as well, we got the certificate revoked after one week using it **
We use this approach for staging/dev servers:
If you don't want to use a self-signed certificate, one option is to purchase a cheap SSL certificate, e.g.:
https://www.ssls.com/comodo-ssl-certificates/positivessl.html
Then once you need to approve it you have to ask support to change the approver validation process: instead of sending an email to a admin#mydomain.cloudapp.net you can ask to change the validation process to placing a given file with a given file in the root of your website (you have to ask in the support / chat room about that option).
More info:
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/791/16/alternative-methods-of-domain-control-validation-dcv
This question has come up at my job a few times, and I was hoping to get some community backing.
We are working on a Single Page WebApp, but require that the data coming from our services API be secure to prevent snooping of the data. We are also trying to iron out the prod environment details for where our SPA will be hosted. One of the options is using something like Amazon's S3, which doesn't support SSL (to my knowledge).
There's a group that believes the whole site needs to be hosted over SSL. However, it's my understanding that SSL will only protect the transmission of the data. So the point I'm trying to make is that hosting the services from an HTTPS site and the client code from non-SSL based URLs will be just as secure as hosting everything from an SSL site.
Could anyone clarify this for me?
Thanks in advance.
Yes, SSL just encrypts the transmission of the data, and does not offer any type of protection of the runtime environment on any client-side code.
Now, it is generally considered a best practice to host everything over SSL, for these reasons:
Users can get warnings that a site is transmitting data with an untrusted source if parts are from SSL and parts are not.
Any cookies, will be sent in the clear when requesting the non-SSL files and may contain information that should be kept private.
What are the latest news on CDN security, related to the fact that CDN provider has access to my users' cookies? Let's assume that the delivered scripts are not patched to do a malicious job behind the scenes, but the fact that someone intercepts (by design, SSL can't help here) cookies of my users is somewhat worrying.
A CDN won't have access to your user's cookies. Cookies are tied to a specific domain (or subdomains if you tell them to be) so HTTP requests to a CDN won't include the cookies because the domain name will be different. You can use Fiddler or your network monitor tool of choice to verify this.