Imagine I need to provide a secure endpoint with private data. Consider user1 with password1234. Is there any difference in security between:
https://website.com/myendpoint/user1/password1234
https://website.com/myendpoint with HTTP Basic Auth with credentials given above
It seems to me there is in fact no difference, but I don't have any specific/strong arguments for it.
There is indeed a significant difference. As per the best practice, you should not include any sensitive information (let alone passwords) in the url.
Reasons are the following:
Urls get logged on the server (typically to files, but other datastores might even be worse) which might allow an attacker to extract this data, think for example backups as well.
Urls might get logged and/or inspected on intermediate proxies. Consider corporate proxies with https inspection.
Urls are cached on the client and added to browser history. A script or a malicious user having gained access to a pc might extract passwords from there. Even if the intended client is programmatic, consider users who want to use your app or api from a browser for whatever reason (users are very creative :) ).
Urls might be seen on screen.
Of course not all of these apply to all usecases, but some of these you have no control over. So it's best to not include any sensitive data in your urls. Http basic over https is much better.
Related
I am trying to learn how to implement a DNS server, and am looking first at Heroku.
Why do they have # point to hidden-sierra-7936.herokudns.com.? Why not just foo.herokudns.com., or better yet, herokudns.com. (no subdomain), or even better, heroku.com. (main website). What are the reasons for this? Is it security, performance, architecture-needs, something else, all of the above? More specifically, what are the details of these reasons, does it depend on the number of requests coming through and that's why the <dynamic-name>.herokudns..., so there are a lot of them? Or perhaps if there is an error in one they can quickly switch it?
Finally, can these reasons be avoided/countered/argued-against so you could make the domain a little nicer and just do heroku.com.? Why can't you just do it on heroku.com.? (If you were building Heroku that is, obviously Heroku doesn't support this).
I am also looking at this. It looks like Heroku used to do it like proxy.heroku.com, but for some reason they switched it. Why?
As far as using subdomains on .heroku.com, this is at least partly a security mitigation.
Consider the arguments made in this blog post from GitHub, published when they moved Pages sites from .github.com to .github.io:
There are two broad categories of potential security vulnerabilities that led to
this change.
Session fixation and CSRF vulnerabilities resulting from a browser security issue sometimes referred to as “Related Domain Cookies”. Because Pages sites may include custom JavaScript and were hosted on github.com subdomains, it was possible to write (but not read) github.com domain cookies in way that could allow an attacker to deny access to github.com and/or fixate a user’s CSRF token.
Phishing attacks relying on the presence of the “github.com” domain to create a false sense of trust in malicious websites. For instance, an attacker could set up a Pages site at “account-security.github.com” and ask that users input password, billing, or other sensitive information.
I would like to secure a .NET Web API service. I will be using SSL, but I also need to restrict the Web API calls that each user can call depending on the user's permissions.
From what I've read, REST/HTTP is supposed to be stateless, so technically you shouldn't be able to maintain any session state, but there are some ways around that.
One is to use basic authentication. The credentials are sent with every request. While this may be okay security-wise because they're being transmitted over SSL anyway, it really isn't practical given that it would require a lot of overhead to re-authenticate against the database every time. (A possibility might be to cache them in memory, but I doubt that's the best way.)
Another could be to use an HMAC (example implementation) to control access to API calls. There is a comment in this article that says:
Just to be clear to people that are implementing this on their HTTPS services: YOU DON'T NEED TO IMPLEMENT HMAC ON SSL!!! It's a waste of time and waste of complexity for absolutely no reason. DON'T DO IT. Use Basic Auth and be done with it.
I don't agree with this for the reasons mentioned above (it is more practical to authenticate once and control using HMAC than authenticate every time).
Is it a good and effective practice to use an HMAC to provide security to Web API calls when working over SSL, or are there any points that I am missing?
The answer depends on how much you care about security.
What is this API being used for? If security is a big concern, Basic Authentication is NOT a sufficiently good choice -- even if you're using SSL.
Even if you're using SSL, an attacker who can control or get access to your initial request can pretend to be the desired HTTPS web service, and intercept your traffic easily (then get a hold of your API credentials).
A much better solution is to do several things:
Use an API key and secret.
Generate a unique ID with each request.
Generate a timestamp with each request.
Encrypt the body of your request against your API key secret.
Put the encrypted output into the HTTP_AUTHORIZATION header in the form: API_KEY_ID:<encrypted_output>
On the server side, decrypt the payload.
Compare the timestamp -- if the request was sent more than a second before -- drop it (this prevents timing attacks).
Compare the unique id -- if this request was already executed -- drop it (this prevents replay attacks).
The above strategies make it impossible for attackers to gain access to your API credentials, even if they are able to successfully man-in-the-middle your API calls.
For username/pwd verification - the good websites use https - to avoid sending cleartext password over the wire. If I have a site where I want to do this - i.e. login over https. However - after logging in the rest of the stuff should be over http. Is this possible - if yes, why don't we see too many websites doing this. If not, why not?
You might want to read up on Firesheep. The short form is that this technique allows malicious people to hijack the session.
if yes, why don't we see too many websites doing this
The usual excuse for not using end-to-end TLS/SSL is that it causes the web app to take a performance hit, slow response times etc. This is a very flawed argument for https-sometimes security policy. Not entirely unfounded, but still unjustifiable.
If not, why not?
The thinking is that the only inherently vulnerable aspect of user access control is the authentication phase, i.e. where you supply your username and password to prove you are who you say you are. Organizations are aware of the risk of transmitting the credentials in clear text. After this process however, authorization is carried out server side and the web app trusts you from there on out and there are no credentials to protect any more.
Or are there?
As jszakmeister pointed out very succinctly, the session cookie is every bit as security critical as a username/password pair. Should someone get a hold of that, they might as well have seen the password and username on post-it.
I was recently looking around at some of the features my current web host offers, and am now wondering about a few things. Even if you can only answer part of this, I appreciate any help you can provide.
I have a domain, mydomian.com, and the host offers shared SSL so I can use HTTPS by using this address https://mydomain.myhost.com. The SSL certificate is good for *.myhost.com.
I don't know a lot about SSL, but I'm assuming this means that the data between site users and ANY domain on myhost.com is encrypted. So was curious if this meant that if someone else on the same host as me somehow intercepted the data from my site would they be able to view it, since they would also have a https://theirdomain.myhost.com address, which uses the same SSL certificate? I may have no idea at all, and this was pretty much a guess.
If HTTPS is used on a login page, but after logging in the other pages are viewed over HTTP, is this a security issue?
Is there any way to show a web form via HTTP for bots like Google, but have real users redirected to the HTTPS version? Would be ideal if this could be done via .htaccess. I currently have some rewrite rules that redirect certain pages to HTTPS, but the rest as HTTP. So if a visitor visits the contact form they get the HTTPS version automatically, but it automatically switches back to HTTP for pages that don't contain forms. So, via htaccess, is there a way to direct real users to the HTTPS version, but have bots directed to the HTTP version? I would like these pages to still be indexed by the search engines, but would like users to see it via HTTPS.
Thanks in advance for any help you can provide.
I'm going to guess you'll be okay for number one. If your host does it correctly, individual subdomains never get to see the SSL keys. Here's how it would work:
Some guy with a browser sends an encrypted request to your subdomain server.
Your host's master server receives the request and decrypts it.
The master server sends the decrypted request to your subdomain server.
And any HTTPS responses you send back go through that process in reverse. It should be easy to check if they've set things up that way: If you can set up shared SSL without personally handling any key files, you're good. If you actually get your hands on some key files... not good.
For two: If you encrypt the login, you protect the passwords, which is good. But if you switch back to HTTP afterwards, you open yourself up to other attacks. See: Firesheep. There may be others.
And for three. Yes - definitely doable. Check out mod_rewrite. Can't give you an example, as I've never used this particular case, but I can point you to this page - particularly the section entitled "Browser Dependent Content."
Hope that helps!
Every traffic is encrypted, when you use https:// as protocol. (Except for some uncommon circumstances I won't talk about here). An SSL certificate's purpose is to prove the identity of the server, by combining it's public key with an identity. This certificate is only usable with the private key that belongs to the public one. In your case it seems that this certificate as well as the key-pair is provided by your hosting provider. I guess that neither you nor the other customers on the host have access to this private key. That means that only your provider is able to decrypt the traffic. Since that's always the case (he's running the server, so has access to every data), that should be no problem.
In most cases it is a security issue. On every further unencrypted http-request the client has to provide some information of the session to the server. These can be intercepted and used by an attacker. (simply speaking)
The bots should support https, why not redirect them? Anyhow: The important part is not to provide the page containing the form via https. To protect your user's data you should take care that the response is transferred via https.
Scenario:
I have a ASP.Net / Silverlight website with webservices for supporting the Silverlight apps with data. The website uses forms authentication, and thus the webservices can also authenticate requests.
Now I would like to pull some data from this system to a Android application. I could implement code for running the forms login, and storing the authentication cookie, but it would actually be much simpler to send the username and password in the webservice url and authenticate each call. I don't really see a big problem with this as the communication is SSL encrypted, but I'm open to be conviced otherwise ;)
What do you think ? Bad idea / not so bad idea ?
Conclusion:
After reviewing the answers the only really valid argument against name / pass in the url request string is that it's stored in the server log files. Granted it's my server and if that server is hacked the the data it stores will also be hacked, but I still don't like passwords showing up in logs. (Thats why they are stored salted and encrypted)
Solution:
I will post the username and passord with the request. Minimal extra work, and more secure.
See Are querystring parameters secure in HTTPS (HTTP + SSL)?
Everything will be encrypted, but the URLs, along with the query string (and thus the passwords) will show up in the server log files.
Bad Idea: The contents of your post are encrypted and though the URL parameters may be encrypted as well, they could still be visible to third-party trackers, server logs or some other monitoring software that can directly sniff your traffic. It is just not a good idea to open up a potential security hole in this way.
Users do tend to copy-and-paste URLs straight from their address bar into emails, blogs, etc., and save them in bookmarks, and so on.
And things like plugins, or even other software that reads, for example, window properties (alternate shells, theme managers, accessibility software) could end up with the info. And they might, for example, crash and automatically send crashdumps back to their developers.
And worms far less sophisticated than keloggers - like things that take screendumps - can get passwords this way. Sometimes even security software, for example if deployed in a corporate network.
And if the user has a local proxy, then they might be communicating in plaintext with the proxy which in turn is talking in SSL (not the way it's supposed to be done, but it happens).
And for these and more reasons, URLs with usernames and passwords, that used to be standard - such as ftp URLs with the username and password in the authority segment - are now typically forbidden by browsers.
https://www.rfc-editor.org/rfc/rfc3986#section-7.5
So, an emphatic NO, DO NOT DO THIS.
It is always good programing practice to not provide delicate info like username and password
in the URL. No matter how good a site is it can be compromised. So why provide with more info?