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.
Related
I have a fairly basic query that I hope somebody can help with.
A website www.example.com presents a form to the user which collects a bunch of personal data. e.g. name, email, telephone.
The full URL is http://www.example.com/
On submit the form's data is collected via JavaScript, POSTed via an AJAX call to www.example.com/process.php and passed to the server via a secure API call using a curl request.
The full url provided in the curl request is https://api.mysecuresite.com/
Do I need to provide an SSL certificate for www.example.com?
Yes.
The data could be intercepted between the browser and http://www.example.com/process.php.
(Consider an analogy: You take a large amount of cash out of the bank, hold it up in the air and walk two blocks down the street. Then you put the cash in an armored van. Is this is safe way to handle the cash?)
Also: A man-in-the-middle attack could inject a script into http://www.example.com before it gets put into the HTTP request to http://www.example.com/process.php. This could also intercept the data even if you were making the Ajax request directly to https://api.mysecuresite.com/.
Additionally, users will be informed that http://www.example.com is insecure, which will (correctly) discourage them from trusting any assurances you make that their data is safe.
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.
How does browser send back cookie to the server during post requests. How is this different than the form data that is sent during a post ?
Also are the values of cookies for a particular domain automatically sent back to the domain for all its subsequent requests ?
Thanks,
Murtaza
There is no different between how cookies are sent for GET and POST requests.
Form data is data such as fields from an HTML Form, eg. name, username, file, etc...
Any cookies sent back in a response from a domain will be sent back to the server in subsequent requests. This is true in web browsers at least, if you are doing this in code, you might have to write additional code to handle cookies.
This should work for AJAX calls made by your browser as well as full pages. Every request, be it full pages, images or AJAX calls will have the Cookies attached if they are going to an appropriate domain and path.
These primers on cookies and HTTP POST would be useful:
http://en.wikipedia.org/wiki/HTTP_cookie
http://en.wikipedia.org/wiki/POST_(HTTP)
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
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.