I am creating a simple PHP application which uses JQuery and AJAX to call (GET method) a PHP script with some parameters; username and password. The application uses SSL.
When tracing the request in Google Chrome Developer tools, I see the following request URL:
https://application.com/php/login.php?username=John&password=Simple1234
I used WireShark to make sure the parameters are encrypted when sending the request, and I don't see any obvious request-headers.
Just to be a 100% sure. Does SSL also encrypt parameters which are included in the header and am I doing this the right way? I found some duplicate questions about this topic, but none of them had a specific example.
Yes but it is a bad idea to use $_GET for such sensitiv data.
This data would be saved in the server logs
This data would be saved in the browser cache
Even Screenshots taken while the login process could contain this data
Also even if the data is encrypted it is still "availble" and could be decrypted.
Use $_POST instead.
This article will show the risks:
https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
The fact that it is PHP or AJAX does not matter here.
The only thing that matters is the URL: is it https:// or http://?
If it is https:// since it means it is HTTPS(!) which means in summary HTTP inside TLS (SSL is dead since 20 years, its successor is TLS).
TLS encrypts everything (it does other things too but here we discuss only confidentiality needs), if implemented and configured correctly (I want to emphasize that because it is not a silver bullet, putting a sticker "TLS" is not enough, for example there is the whole issue of certificates verification, as authentication may be deemed more important that confidentiality in fact, because what do you gain if you encrypt everything towards an endpoint you are not 100% sure it is the valid one?)
What you see in the URL is part of the HTTP protocol. The URL will be inside the HTTP stream as GET /php/login.php?..., just before other headers. Same if using other HTTP methods. Since it is inside HTTP, it is inside TLS, hence encrypted.
The only thing visible by a passive monitor will be the domain name (both for DNS queries before the HTTPS connection - DNS over HTTPS/TLS solves that - and because of the SNI extension at the beginning of the TLS handshake - and encrypted SNI, still being designed, will solve that).
I building a service which be served via https.
I would like to know if password (or any specific key) transmitted in curl option CURLOPT_USERPWD are safe when data is "over the wire" ?
ALL data send via HTTPS is encrypted. This means that it is very difficult (but not impossible) for anyone between the server and the client to view the raw data of the request.
If you want to fully understand the potential ramifications of using HTTP basic auth, you should fully understand how it works.
Since HTTP is a plain text protocol, it is very insecure. HTTPS is simply HTTP using an encrypted socket - which means that the request/response format itself is completely unchanged. If you can view the plain-text version of the request, you can glean from it whatever information you like. But, using SSL/TLS makes it very difficult to view the plain-text version.
HTTP Basic auth is inherently vulnerable to man-in-the-middle attacks and should never be used over an unencrypted connection, but using HTTPS makes it fairly safe. The only consideration is that the server will be able to view the password in plain text - if you don't want this to happen, you should use Digest auth, HTTPS or otherwise.
Yes, the password won't be visible, because it is sent encrypted over the network, but most probably (not completely sure), the script that runs on the target website (the service in your case), will be able to see your password.
Consider a scenario, where user authentication (username and password) is entered by the user in the page's form element, which is then submitted. The POST data is sent via HTTPS to a new page (where the php code will check for the credentials). Now if a hacker sits in the network, and say has access to all the traffic, is the Application layer security (HTTPS) enough in this case ? I mean, would there be adequate URL encryption or is there a need to have Transport Layer security ?
Yes, everything (including the URL) is going through the encrypted channel. The only thing that the villain would find out is the IP address of the server you are connecting to, and that you are using HTTPS.
Well, if he was monitoring your DNS requests as well, he might also know the domain name of the IP address. But just that, the path, query parameters, and everything else is encrypted.
Yes. In an HTTPS only the handshake is done unencrypted, but even the HTTP GET/POST query's are done encrypted.
It is however impossible to hide to what server you are connecting, since he can see your packets he can see the IP address to where your packets go. If you want to hide this too you can use a proxy (though the hacker would know that you are sending to a proxy, but not where your packets go afterwards).
HTTPS is sufficient "if" the client is secure. Otherwise someone can install a custom certificate and play man-in-the-middle.
As a web developer not much can be done other than disallowing HTTP requests. This can be done via mod_rewrite in Apache.
Is adequate, because if it have access to all your traffic, doesn't matter what encryption protocol do you use, he can use man in the middle for both encryption protocols.
How would you use https ?, would sending information via GET and POST be any different while using https ?
Any information and examples on how https is used in php for something simple like a secure login would be useful,
Thank you!
It will be no different for your php scripts, the encryption and decryption is done transparently on another layer.
Both GET and POST get encrypted, but GET will leave a trace in the web server log files.
HTTPS is handled at the SSL/TLS Layer, not at the Application Layer (HTTP). Your server will handle it as aularon was saying.
SSL and/or HTTPS is used to provide some level of confidentiality for data in transit between the web users and the web server. It can also be used to provide a level of confidence that the site the users are communicating with is in fact the one they intend to be.
In order to use SSL, you'll need to configure these capabilities on the server itself, which would include either purchasing (an authority-signed) or creating (a self-signed) certificate. If you create your own self-signed certificate, the level of confidence that the site is the intended one is significantly reduced for your users.
PHP
Once your webserver is able to serve SSL-protected pages, PHP will continue to operate as usual. Things to look out for are port numbers (normal HTTP is usually on port 80, while HTTPS traffic is usually on port 443), if your code relies on them.
GET & POST Data
Pierre 303 is correct, GET data may end up in the logs, and POST data will not, but this is no different than a non-SSL web server. SSL is meant to protect data in transit, it does nothing to protect you and your customers from web servers and their administrators that you may not trust.
Secure Login
There is also a performance hit (normally) when using SSL, so, some sites will configure their pages to only use https when the user is sending sensitive information, for example, their password or credit card details, etc. Other traffic would continue to use the normal, http server.
If this is the sort of thing you'd like to do, you'll want to ensure that your login form in HTML uses a ACTION that points to the https server's pages. Once the server accepts this form submission, it can send a redirect to send the user back to the page they requested using just http again.
Just ensure you're sending the correct headings when allowing files to be downloaded over ssl... IE can be a bit quirky. http://support.microsoft.com/kb/323308 for details of how to resolve
I know next to nothing when it comes to the how and why of https connections. Obviously, when I'm transmitting secure data like passwords or especially credit card information, https is a critical tool. What do I need to know about it, though? What are the most common mistakes you see developers making when they implement it in their projects? Are there times when https is just a bad idea? Thanks!
An HTTPS, or Secure Sockets Layer (SSL) certificate is served for a site, and is typically signed by a Certificate Authority (CA), which is effectively a trusted 3rd party that verifies some basic details about your site, and certifies it for use in browsers. If your browser trusts the CA, then it trusts any certificates signed by that CA (this is known as the trust chain).
Each HTTP (or HTTPS) request consists of two parts: a request, and a response. When you request something through HTTPS, there are actually a few things happening in the background:
The client (browser) does a "handshake", where it requests the server's public key and identification.
At this point, the browser can check for validity (does the site name match? is the date range current? is it signed by a CA it trusts?). It can even contact the CA and make sure the certificate is valid.
The client creates a new pre-master secret, which is encrypted using the servers's public key (so only the server can decrypt it) and sent to the server
The server and client both use this pre-master secret to generate the master secret, which is then used to create a symmetric session key for the actual data exchange
Both sides send a message saying they're done the handshake
The server then processes the request normally, and then encrypts the response using the session key
If the connection is kept open, the same symmetric key will be used for each.
If a new connection is established, and both sides still have the master secret, new session keys can be generated in an 'abbreviated handshake'. Typically a browser will store a master secret until it's closed, while a server will store it for a few minutes or several hours (depending on configuration).
For more on the length of sessions see How long does an HTTPS symmetric key last?
Certificates and Hostnames
Certificates are assigned a Common Name (CN), which for HTTPS is the domain name. The CN has to match exactly, eg, a certificate with a CN of "example.com" will NOT match the domain "www.example.com", and users will get a warning in their browser.
Before SNI, it was not possible to host multiple domain names on one IP. Because the certificate is fetched before the client even sends the actual HTTP request, and the HTTP request contains the Host: header line that tells the server what URL to use, there is no way for the server to know what certificate to serve for a given request. SNI adds the hostname to part of the TLS handshake, and so as long as it's supported on both client and server (and in 2015, it is widely supported) then the server can choose the correct certificate.
Even without SNI, one way to serve multiple hostnames is with certificates that include Subject Alternative Names (SANs), which are essentially additional domains the certificate is valid for. Google uses a single certificate to secure many of it's sites, for example.
Another way is to use wildcard certificates. It is possible to get a certificate like ".example.com" in which case "www.example.com" and "foo.example.com" will both be valid for that certificate. However, note that "example.com" does not match ".example.com", and neither does "foo.bar.example.com". If you use "www.example.com" for your certificate, you should redirect anyone at "example.com" to the "www." site. If they request https://example.com, unless you host it on a separate IP and have two certificates, the will get a certificate error.
Of course, you can mix both wildcard and SANs (as long as your CA lets you do this) and get a certificate for both "example.com" and with SANs ".example.com", "example.net", and ".example.net", for example.
Forms
Strictly speaking, if you are submitting a form, it doesn't matter if the form page itself is not encrypted, as long as the submit URL goes to an https:// URL. In reality, users have been trained (at least in theory) not to submit pages unless they see the little "lock icon", so even the form itself should be served via HTTPS to get this.
Traffic and Server Load
HTTPS traffic is much bigger than its equivalent HTTP traffic (due to encryption and certificate overhead), and it also puts a bigger strain on the server (encrypting and decrypting). If you have a heavily-loaded server, it may be desirable to be very selective about what content is served using HTTPS.
Best Practices
If you're not just using HTTPS for the entire site, it should automatically redirect to HTTPS as required. Whenever a user is logged in, they should be using HTTPS, and if you're using session cookies, the cookie should have the secure flag set. This prevents interception of the session cookie, which is especially important given the popularity of open (unencrypted) wifi networks.
Any resources on the page should come from the same scheme being used for the page. If you try to fetch images from http:// when the page is loaded with HTTPS, the user will get security warnings. You should either use fully-qualified URLs, or another easy way is to use absolute URLs that do not include the hostname (eg, src="/images/foo.png") because they work for both.
This includes external resources (eg, Google Analytics)
Don't do POSTs (form submits) when changing from HTTPS to HTTP. Most browsers will flag this as a security warning.
I'm not going to go in depth on SSL in general, gregmac did a great job on that, see below ;-).
However, some of the most common (and critical) mistakes made (not specifically PHP) with regards to use of SSL/TLS:
Allowing HTTP when you should be enforcing HTTPS
Retrieving some resources over HTTP from an HTTPS page (e.g. images, IFRAMEs, etc)
Directing to HTTP page from HTTPS page unintentionally - note that this includes "fake" pages, such as "about:blank" (I've seen this used as IFRAME placeholders), this will needlessly and unpleasantly popup a warning.
Web server configured to support old, unsecure versions of SSL (e.g. SSL v2 is common, yet horribly broken)
(okay, this isn't exactly the programmer's issue, but sometimes noone else will handle it...)
Web server configured to support unsecure cipher suites (I've seen NULL ciphers only in use, which basically provides absolutely NO encryption)
(ditto)
Self-signed certificates - prevents users from verifying the site's identity.
Requesting the user's credentials from an HTTP page, even if submitting to an HTTPS page. Again, this prevents a user from validating the server's identity BEFORE giving it his password... Even if the password is transmitted encrypted, the user has no way of knowing if he's on a bogus site - or even if it WILL be encrypted.
Non-secure cookie - security-related cookies (such as sessionId, authentication token, access token, etc.) MUST be set with the "secure" attribute set. This is important! If it's not set to secure, the security cookie, e.g. SessionId, can be transmitted over HTTP (!) - and attackers can ensure this will happen - and thus allowing session hijacking etc. While you're at it (tho this is not directly related), set the HttpOnly attribute on your cookies, too (helps mitigate some XSS).
Overly permissive certificates - say you have several subdomains, but not all of them are at the same trust level. For instance, you have www.yourdomain.com, dowload.yourdomain.com, and publicaccess.yourdomain.com. So you might think about going with a wildcard certificate.... BUT you also have secure.yourdomain.com, or finance.yourdomain.com - even on a different server. publicaccess.yourdomain.com will then be able to impersonate secure.yourdomain.com....
While there may be instances where this is okay, usually you'd want some separation of privileges...
That's all I can remember right now, might re-edit it later...
As far as when is it a BAD idea to use SSL/TLS - if you have public information which is NOT intended for a specific audience (either a single user or registered members), AND you're not particular about them retrieving it specifically from the proper source (e.g. stock ticker values MUST come from an authenticated source...) - then there is no real reason to incur the overhead (and not just performance... dev/test/cert/etc).
However, if you have shared resources (e.g. same server) between your site and another MORE SENSITIVE site, then the more sensitive site should be setting the rules here.
Also, passwords (and other credentials), credit card info, etc should ALWAYS be over SSL/TLS.
Be sure that, when on an HTTPS page, all elements on the page come from an HTTPS address. This means that elements should have relative paths (e.g. "/images/banner.jpg") so that the protocol is inherited, or that you need to do a check on every page to find the protocol, and use that for all elements.
NB: This includes all outside resources (like Google Analytics javascript files)!
The only down-side I can think of is that it adds (nearly negligible) processing time for the browser and your server. I would suggest encrypting only the transfers that need to be.
I would say the most common mistakes when working with an SSL-enabled site are
The site erroneously redirects users to http from a page as https
The site doesn't automatically switch to https when it's necessary
Images and other assets on an https page are being loading via http, which will trigger a security alert from the browser. Make sure all assets are using fully-qualified URIs that specify https.
The security certificate only works for one subdomain (such as www) but your site actually uses multiple subdomains. Make sure to get a wildcard certificate if you will need it.
I would suggest any time any user data is stored in a database and communicated, use https. Consider this requirement even if the user data is mundane, because even many of these mundane details are used by that user to identify themselves on other websites. Consider all the random security questions your bank asks you (like what street do you live on?). This can be taken from address fields really easily. In this case, the data is not what you consider a password, but it might as well be. Furthermore, you can never anticipate what user data will be used for a security question elsewhere. You can also expect that with the intelligence of the average web user (think your grandmother) that that tidbit of information might make up part of that user's password somewhere else.
One pointer if you use https
make it so that if the user types
http://www.website-that-needs-https.com/etc/yadda.php
they will automatically get redirected to
https://www.website-that-needs-https.com/etc/yadda.php
(personal pet peeve)
However, if you're just doing a plain html webpage, that will be essentially a one-way transmission of information from the server to the user, don't worry about it.
All very good tip here... but I just want to add something..
Ive seen some sites that gives you a http login page and only redirect you to https after you post your username/pass.. This means the username is transmitted in the clear before the https connection is established..
In short make the page where you login from ssl, instead of posting to an ssl page.
I found that trying to <link> to a non-existent style sheet also caused security warnings. When I used the correct path, the lock icon appeared.