This is a follow up post of my previous question about BASIC auth over HTTPS
Are the path to the resource and query string passed securely to the server if I use HTTPS?
i.e.
URI: http://server/path/to/a/resource?with=a&query=string
Server: server
path: /path/to/a/resource
query string: with=a&query=string
This is a really good explanation of this: http://answers.google.com/answers/threadview/id/758002.html#answer
Summary: only the host and port would be visible unencrypted.
In short, yes. But you shouldn't store sensitive data in URL's since it may be visible in the browsers history and server logfiles. And anyone who looks over your shoulder sees it too.
Yes it is - the entire session is secured and encryped so anything you send, including the query string is unreadable.
You can prove this to yourself, if you wish, by using something like Fiddler to view the http/https traffic you generate when you visit a secure url. Anything you send over HTTPS will not show the querystring, as shown here:
The actual URL I was visiting looked like this:
https://www.halifax-online.co.uk/_mem_bin/formslogin.asp?source=halifaxcouk&simigvis=
As per other answers, you shouldn't pass any sensitive information in the querystring as this may be stored in your webservers log files, so if you were passing a username/password combination anyone who could access your logs would be able to capture that information. This could allow someone to log into your site/application as if they were someone else even if you were making efforts such as storing passwords in your database as salted hashes, rather than plaintext.
HTTPS is simply HTTP tunnelled over an SSL connection. This means that the request, response, headers and content are all within the SSL tunnel and should therefore be encrypted.
Related
I have an app that I am trying to pull data from a remote database. I have the url and the table columns and database name but i'm not sure how to call on that database with an http get. Below is my code:
def self.data
BubbleWrap::HTTP.get("url", {credentials: {username: '***', password: '***'}}) do |response|
p response.to_s
end
end
I know this request is working because it shows me data in the console.I can't find anywhere how to request information from a database attached that url. Any help would be greatly appreciated. I have been working with Ruby for a year now but new to RubyMotion.
Not sure to understand exactly your question, but you might want to take a look at this link and this one, explaining how to retrieve and handle data from a service.
Hope it helps.
This may be too elementary, but with an HTTP request you are not querying a database, you are requesting data from an HTTP server. It's the job of the server to look your request over, go to the database, retrieve the data, package it (often in JSON format), and ship it back. I believe that's what #railsdog was referring to in terms of marshaling.
Now, a couple of other comments:
"url" in your code should be an actual endpoint like https://my.server.org/api/some_endpoint.json. The payload containing credentials can be attached as a query string, however, you might want to consider POST and SSL, as I say in my next point.
You should never send credentials in clear text over HTTP. If you have to send sensitive information, use HTTPS (set up your server to respond to SSL-encrypted requests).
It's probably best to authenticate once on first request and get a token you can use on subsequent requests so as not to expose usernames and passwords unduly. Perhaps you can fill in a few blanks about what your server is (Rails, some public API, other) and it will make it easier to help.
You will need to accept the data from the server in some recognizable format. JSON is very well supported. BubbleWrap has a JSON parser to help turn the results into a hash. Alternate formats are XML (ick) or XML-RPC (ick, ick), or SOAP (ick, ick, ice).
If you're way ahead of me on this and it's too basic to be of use, I apologize.
Is it ok to pass passwords like this or should the method be POST or does it not matter?
xmlhttp.open("GET","pas123",true);
xmlhttp.send();
Additional info: I'm building this using a local virtual web server so I don't think I'll have https until I put upfront some money on a real web server :-)
EDIT: According to Gumo's link encodeURIComponent should be used. Should I do xmlhttp.send(encodeURIComponent(password)) or would this cause errors in the password matching?
Post them via HTTPS than you don't need to matter about that ;)
But note that you need that the page which sends that data must be accessed with https too due the same origin policy.
About your money limentation you can use self signed certificates or you can use a certificate from https://startssl.com/ where you can get certificates for free.
All HTTP requests are sent as text, so the particulars of whether it's a GET or POST or PUT... don't really matter. What matters for security in transmission is that you send it via SSL (and handle it safely on the other end, of course).
You can use a self-signed cert until something better is made available. It will be a special hell later if you don't design with https in mind now :)
It shouldn't matter, the main reason for not using GET on conventional web forms is the fact that the details are visible in the address bar, which isn't an issue when using AJAX.
All HTTP requests (GET/POST/ect) are sent in plain text so could be obtained using network tracing software (e.g. Wireshark) to protect against this you will need to use HTTPS
We are currently in the process of building a new service, the intent is to use PHP for the backend, and more importantly, use AJAX rather than regular HTTP requests for the frontend. So there will only ever be one initial page request.
While doing this, we'd also like to make sure that it is secure.
So the problem is this:
Login is based on regular username/password. The AJAX frontend will make AJAX-requests to the server as necessary, but what should be done to avoid unnecessary security issues? Hashing the password is obviously one, it can be further improved by also including a server generated token in the hash, etc, etc.
But, I'm sure there are established protocols for these things, but I really don't know the merits of them... or even what they're called or where to find them (note, the server itself is trusted).
Would using HTTPS make all this redundant? Or is for instance hashing the password still strictly necessary (theoretical question)? Would using a protocol still be important/useful/pointless over HTTPS?
http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol, is that something I should look into? Does HTTPS make SRP redundant? Are there more suitable protocols, especially over HTTPS?
If you use PHP sessions, you should be fine. When you make a AJAX call, the server will be sent a cookie payload from your page indicating which session ID it corresponds to. Obviously, do this over HTTPS to make the communication secure.
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.
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.