Is it secure to pass login credentials as plain text in an HTTPS URL?
https://domain.com/ClientLogin?Email=jondoe#gmail.com&Passwd=123password
Update: So let's say this is not being entered in the browser, but being generated programmatically and being requested with a POST request (not a GET request). Is it secure?
Solution:
It is not secure to use this type of URL in a GET request (i.e. typing the URL into the browser) as the requested URL will be saved in browser history and server logs.
However, it is secure to submit as a POST request to https://domain.com/ClientLogin (i.e. submitting a form) while passing the credentials as part of the POST body, since the POST body is encrypted and sent after making a connection to the requested URL. So, the form action would be https://domain.com/ClientLogin and the form field values will be passed in the POST body.
Here are some links that helped me understand this better:
Answer to StackOverflow Question: Are https URLs encrypted?
Straightforward Explanation of SSL and HTTPS
Google Answers: HTTPS - is URL string itself secure?
HTTP Made Really Easy
No. They won't be seen in transit, but they will remain in:
browser history
server logs
If it's at all possible, use POST over HTTPS on authentication, and then set a "authenticated" cookie, or use HTTP Digest Authorization over HTTPS, or even HTTP Basic auth over HTTPS - but whatever you do, don't put secret/sensitive data in the URL.
Edit: when I wrote "use POST", I meant "send sensitive data over HTTPS in POST fields". Sending a POST http://example.com/ClientLogin?password=hunter2 is every bit as wrong as sending it with GET.
TL;DR: Don't put passwords in the URL. Ever.
Passing login info in url parameters is not secure, even with SSL
Passing login info in POST body with SSL is considered secure.
If you're using SSL, consider HTTP Basic authentication. While this is horribly problematic without SSL, it is no worse than POST with credentials, it achieves what you want, but does so according to an established standard, rather than custom field names.
Related
I have a resource (an html web page, but it could be anything else like json/xml describing a book) and retrieve it with a GET request:
http://127.0.0.1/welcome
This resource is in Japanese (because kawai desu). Now, I do a GET request on this resource, asking server for another language:
http://127.0.0.1/welcome?lang=en
So the server responses with the English version of the resource. But from now on, since I called ?lang=en, I want to set the default language of the user in a cookie. So server adds a cookie to its response:
Cookie: language=en
Browser now have the language=en cookie. Then, I ask for the resource without GET parameters and the server delivers the English version because the browser sent the Cookie:language=en request header:
http://127.0.0.1/welcome
Returns the English version.
These queries look like retrieving (a resource with a cookie), idempotents (doesn't change a bit when send several times) and safe (server-modification less) queries to me: am I right to use GET requests even if they involve cookies?
Two GET requests have the same URI http://127.0.0.1/welcome
but different results: how does caching (browser and proxy) handle
this?
GET response for http://127.0.0.1/welcome?lang=en could be cached too: will (proxy/CDN, browser) cached responses include the language=en cookie (so user language for the website switches to en)?
With regards to the way resources accessed over XHR2/CORS can block the request unless it came from a whitelisted domain:
which header is read to determine the referrer domain - is it the standard HTTP_REFERRER?
could someone send a request pretending to be from another domain somehow?
I'm aware CORS is not a reliable means of securing data - I ask only as a point of curiosity.
The header that is read is Origin. As any HTTP header it can be faked. The idea behind COSR is to enable sending data, while still securing the user / preventing abusing of user session. The cross-domain requests are forbidden to protect the user, not the server.
The attacker should both send the request pretending this is another domain AND send the cookies the user has. And this is not something you can achieve via XSS alone - you have to steal the cookie and send the request on your own. But you cannot steal the cookie for site A from site B. If A however accepts request from any domain, via XSS on B you can trick the user's browser to send request to A, the browser will send the cookies and you can read the response back.
The Origin header contains the requesting domain.
This browser is in complete control of this header, and it cannot be faked. The browser controls this header on behalf of the user, and user's cannot override the value in the JS code.
Note that I said "the browser"; as with any HTTP request, the user could craft a curl request with any Origin header. But this has limited use as an attack vector, since the hacker would have to trick a valid user into issuing the correct curl request, which is unlikely.
Lets consider next scenario: assume I have a web app, and authentication of users is performed through a modal dialog window (lets say, that when a user clicks login button, ajax request is sent and depending on the callback I either close the window or display an error), and I use only HTTP protocol. Why is it considered to be not secure way to do things?
Also, please make sure that a modal dialog window is taken into account, because this is vital info. There may be some data displayed underneath the dialog window and can be accessible if modality is broken.
The question includes both:
How can you break an app security by
utilizing ajax call?
Is Ajax HTTP less secure than a
regular form HTTP?
Whoever told you - he is wrong. The ajax through post is not less secure than post with regular forms. Just because it is the same thing.
Update 1 according to the last edit:
You cannot
No
Argument: the AJAX request is the same http request as any other (such as request sent by html form). Absolutely the same. So by definition it cannot be less or more secure.
I don't know how to explain more and what to say else: ajax is a http request. the same request as your browser does when you open SO page or when you post the SO question form.
I can rephrase your question to something like "Why A is less secure than A". Answer to it: A is not less secure than A, because A is A :-S
Any sensitive data should be channeled through HTTPS. GET data is sent in the querystring. POST data is sent in the HTTP Request header. Ajax can do both. BOTH are not secure. You need a channel level encryption to really secure it.
HTTP isn't secure for private data because the data is transmitted in plaintext. This can be intercepted anywhere between the client and server (eg. wifi.) Ajax over HTTPS would be much better.
I think the issue is that you are using http. No matter how you look at it it wont be secure. If you use https the ajax request will be just as secure as a html form.
Somy answer would be to use https and you will be all set.
I'm no security expert, but I think it might be more secure sending it over HTTPS. Just googling learns me that it can be done securely though:
http://www.indicthreads.com/1524/secure-ajax-based-user-authentication/
http://msdn.microsoft.com/en-us/magazine/cc793961.aspx (focused on ASP.NET)
etc.
Since browsers use the same network stack for HTTP and HTTPS, be it AJAX or not, there is no difference. All the headers, cookies, authentication, etc work exactly the same.
Given all the coverage FireSheep has been getting, I have been trying to work out the best practices for balancing HTTP / HTTPS usage for some sites I manage (e.g. blogging sites, magazine sites with user contributed comments).
To me, its over kill to deliver all pages over HTTPS if the user is logged in. If a page is public (e.g. a blog) there is little point encrypting the public page. All I want to do is prevent session hijacking by sniffing cookies over HTTP channels.
So, one plan is:
Login form is over HTTPS
Issue two cookies: One cookie is 'public' and identifies there user for read only aspects (e.g. 'welcome bob!'). The second cookie is private and 'HTTPS only'. This is the cookie that is verified whenever the user makes a change (e.g. adds a comment, deletes a post).
This means that all 'changing' requests must be issued over HTTPS.
We use a lot of AJAX. Indeed, many comment forms use AJAX to post the content.
Obviously, I cant use AJAX directly to post content to a HTTPS backend from a HTTP frontend.
My question is: Can I use script injection (I think this is commonly called 'JSONP'?) to access the API? So in this case there would be a HTTP public page that sends data to the private backend by injecting a script accessed via HTTPS (so that the private cookie is visible in the request).
Can you have HTTPS content inside a HTTP page? I know you get warnings the other way around, but I figure that HTTPS inside HTTP is not a security breach.
Would that work? It seems to work in chrome and FF, but its IE that would be the party pooper!
Another way is to have an iframe which points to a https page that can make all kinds (GET, POST, PUT etc) of Ajax calls to the server over https (same domain as iframe is on https too). Once the response is back inside the iframe, you can post a message back to the main window using HTML5 postMessage API.
Pseudo code:
<iframe src="https://<hostname>/sslProxy">
sslProxy:
MakeAjaxyCall('GET', 'https://<hostname>/endpoint', function (response) {
top.postMessage(response, domain);
});
This works in all modern browsers except IE <= 7 for which you'll have to either resort to JSONP or cross domain communication using Flash.
The problem with JSONP is that you can only use it for GETs.
Can you have HTTPS content inside a
HTTP page? I know you get warnings the
other way around, but I figure that
HTTPS inside HTTP is not a security
breach.breach.
Including HTTPS content inside a regular HTTP page won't raise any alerts in any browser.
However, I don't think JSONP will help you out of this one. Using GETs to post content and modify data is a very bad idea, and prone to other attacks like CSFR
I have a website that is currently using https for secure login and transactions. You can't navigate to the to the main site unless you login.
I have had a request from a partner who have asked if they can seamlessly navigate to our site from their own web application, without logging in. There site is also using https.
I've set up a "PartnerLoginPage.aspx" page, and allowed them to POST html form values into this page (they have the correct user login details). I then authenticate them based on the posted values and redirect them to the main site. They don't need to login then, I've already authenticated them and it works perfectly.
My biggest concern is that this is not a secure way of authenticating the user. If you POST html form values into a https page is the data still encrypted? Just out of interest, if their site was not an http site (it is) would the data still be encrypted?
eg THEIR HTTPS-> FORM POST VALUES -> OUR HTTPS -> ARE FORM POST VALUES DATA ENCRYTPED?
and
THEIR HTTP (note: no 's') ->FORM POST VALUES -> OUR HTTPS -> ARE FORM POST VALUES ENCRTYPED?
Thanks for any help,
Stuart
Assuming all keys are valid, of course...
If the request is made an https page, then the request is encrypted (meaning the POST values, which are sent via the request, are encrypted, regardless of destination).
If the request is made from a non https page to an https page, the request is not encrypted, but the response would be, so the post variables are NOT encrypted (but the value returned would be).
HTTPS essentially sets up whether the server/page that is talking is using encryption or not, so http -> https = non-encrypted request, encrypted response, https -> http = encrypted-request, non-encrypted response.
Of course, there are levels of security that can be set at the script level, but I don't think your answer is worried about that.
Quick Post Script
Why don't you give the partner sites a service account like "username :partners, pw: sheswithme" or some such? You could use cURL to set up the cookie and pass the server variables and have them point their form to a script that makes the request instead of having their users having semi-direct access to your script.