Is a secure cookie supposed to be sent to an HTTPS server that have an invalid certificate? I mean, I have an application served by a HTTPS server which send a cookie with the secure flag activated after the login step. Is my server supposed to receive the cookie back if it has an invalid certificate? Is this is normalized (it seems it's not), could someone point me to the relevant part of the norm?
Yes, a cookie with Secure flag set is only sent for TLS/SSL secured connections:
If the cookie's secure-only-flag is true, then the request-uri's scheme must denote a "secure" protocol (as defined by the user agent). […] Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS. For example, most user agents consider "https" to be a scheme that denotes a secure protocol.
But to establish a TLS/SSL connection, it only matters whether the certificate is trusted. It doesn’t matter how the certificate was trusted, i. e. whether it was trusted automatically or manually.
Whether the certificate is valid or not is actually immaterial. If an invalid certificate is detected when browsing to a site most browsers will tell the user the cert is invalid and let the user determine whether they want to proceed or not.
With regards to the "secure" part of the cookie, all that does is tell the browser that the cookie is only valid for https connections and shouldn't be transferred over regular http connections.
This means that yes, your server should receive the cookie back from the browser provided that the URL being accessed is an https url. Even if the server's cert is invalid.
There's also this statement in the RFC 2965 which is obsoleted by RFC 6265:
The user agent (possibly with user interaction) MAY determine what
level of security it considers appropriate for "secure" cookies.
The Secure attribute should be considered security advice from the
server to the user agent, indicating that it is in the session's
interest to protect the cookie contents. When it sends a "secure"
cookie back to a server, the user agent SHOULD use no less than
the same level of security as was used when it received the cookie
from the server.
Related
Web application manages and identifies it's client by cookies.. session maintenance is also based on cookies..if attacker managed to read my cookie(which obviously he can by packet sniffing) then can he log in to my account with that details?? how application server is prevent this from happening??
It would probably be impossible. The server does not identify the client with only the session value (cookie value). In addition to the session value, the server uses additional information such as the client ip to determine whether the session value (cookie value) is valid. If the attacker is involved in the first session using the Man-in-the-middle attack (MITM), the server knows the attacker's IP as the client IP and trusts the information provided by the attacker.
The attack will succeed.
However, if you use SSL for the connection, the attack will fail.
As you can imagine, if an attack is successful with only a cookie value copy, any service that does not use https will be able to hack. Web technologies are designed so that they are not easily hacked.
check this page
I'm reading the list of useful header from OWASP and I've some trouble understanding if the first two require an HTTPS certificate ?
Public Key Pinning Extension for HTTP : The Public Key Pinning Extension for HTTP (HPKP) is a security header that tells a web client
to associate a specific cryptographic public key with a certain web
server to prevent MITM attacks with forged certificates.
Strict-Transport-Security : HTTP Strict-Transport-Security (HSTS) enforces secure (HTTP over SSL/TLS) connections to the server. This
reduces impact of bugs in web applications leaking session data
through cookies and external links and defends against
Man-in-the-middle attacks. HSTS also disables the ability for user's
to ignore SSL negotiation warnings.
HTTP Public Key Pinning(HPKP) is a trust on first use technique. When a user requests a web server for the first time, the server tells to pin its own or an intermediate CA’s public key to the browser via a special HTTP header. After that browser stores this key for a given period of time. Upon user’s subsequent requests for that web server, the browser expects to contain the pinned key inside one of certificates in the certificate chain of the web server. If not, the user is blocked by giving a warning. For more information you can refer Implementing and Testing HTTP Public Key Pinning (HPKP)
Yes they both do require a certificate:
The first one pin a list of certificates. One of the must be in the current certificate chain.
The second one force to use https if the current https connection is valid.
So by definition the first one need https and a certificate, and the spec of HSTS forbid to send the header with http connections.
I am curious how to properly send username and password from a website login form to a server.
If I just send the username and password without hashing them to an https server how exposed is the password I send in a POST request to somebody sniffing the package and finding out the password? The server is https enabled.
What would be the proper methodology to do this?
If the server is HTTPS enabled then any data going over the wire will be encrypted. It would be extraordinarily difficult for a network-only attacker to sniff even a plaintext password over HTTPS without one of the parties noticing.
HTTPS uses SSL/TLS on the transport layer, which is designed to provide both encryption and authentication. The SSL/TLS protocol, as part of its handshake, negotiates a symmetric encryption key that is different for each session and is used with a strong algorithm to protect data on the wire.
To mitigate 'man-in-the-middle' attacks, the asymmetric keys used by the client and server to establish a shared encryption key are also cryptographically signed by a certificate authority, both to provide assurance of trust and to prevent modification of the certificate. As long as the certificate authority can be trusted, it is easy to check the signature and and server name on the certificate itself. All modern browsers do this automatically and throw a warning to the user if there is any problem with the certificate.
As long as you and your users are aware of the issues surrounding the proper use of SSL (e.g. keep your private key safe, and make sure your users pay attention to browser warning), it's fine to send plaintext passwords over an SSL connection.
If the demands of your application are such that you cannot do even that, you might consider X.509 authentication (which uses certificates on the client side as well as the server side) or Kerberos authentication (which sends no passwords over the wire). For a basic web application, though, both of these solutions are overkill.
I'm reading the API for a web service, and all methods involve sending an HTTP request to
https://example.com/api/APIVER/METHOD?apikey=APIKEY&user=USERNAME&password=PASSWORD
To be clear, both the API key and user password are sent in plain text via the URL. But is this OK because "all HTTPS traffic is encrypted" or not because they're still in plain text or because the URL is somehow different?
If this isn't secure, what is the minimum change the API maintainer needs to do?
Yes, HTTPS makes this more secure.
HTTPS makes this more secure.
You should also send sensitive parameters as POST parameters instead (HTTP BODY) of GET query string ones. Typically the query string will be logged by Web server logs (server side) in plaintext, so it will be accessible to system administrators that perhaps shouldn't be able to see it.
HTTPS will encode the URL in each request, so if you are worried about network sniffing then you're OK. HTTPS also adds a nonce value, so you aren't exposed to reply attacks.
It would be possible, depending on infrastructure to insert a fake SSL certificate that's trusted by the user device and route requests through a proxy using that certificate. However this would require admin/root access to the client machines to make such a certificate trusted (barring breach of a normally trusted CA), and once something needs admin access all bets are off anyway.
It's still not a wonderful idea though, I'd be concerned about developers forgetting to configure it for HTTPS. You have an API key, so why not take the password and hash it using the APIKEY as the salt. Now for the API calls the salt is a password equivalent but it would mean that the username and password couldn't be used for logging into elsewhere with those credentials, for example the web site that the API is running off (assuming you let users log in there of course.)
Even better would be to use a shared secret that doesn't go over the wire at all, and use that as the salt.
any request is made via HTTPS and the token is transmitted the following ways:
a) GET https://foo.dom/foobar?auth_token=abcxyz
b) GET https://foo.dom/foobar with HTTP-header like X-FOOBAR-TOKEN: abcxyz
As I understand SSL, in case of an HTTP request the client first negotiates the SSL connection and does only transmit additional parameters and/or HTTP headers in case the secure connection was established successfully.
Am I right so far?
Thx fur any suggestion.
Felix
SSL buys you encryption of the transport so no one can snag the auth token while it is being sent/to from the site. There are some man-in-the-middle attacks that can be performed against SSL but generally SSL should protect the token content.
What makes or breaks the security is whether or not the Token it-self is cryptographically secure. If that can be said to be true then your are golden. Check out this site http://web.mit.edu/kerberos/dialogue.html.
There are plenty of other sites that use secrue tokens for auth, see: http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RESTAuthentication.html.