In typical session riding scenario attacker makes victim machine to send HTTP request to web site they are already logged in, for example tricking victim to open link in the case of CSRF attack. Browser includes the session cookie (and all other cookies for that site) in the HTTP request, thus attacker can execute any - possibly malicious - operation victim is authorized to perform.
HTTPS encrypts the whole packet, thus making it impossible to read the content, including headers and cookies. But does it protect from session riding attacks, or will the browser still include the cookies and use correct encryption automatically?
will the browser still include the cookies and use correct encryption automatically?
Yes. A CSRF attack works because the browser treats the request just like any other the user would normally want to make. Both HTTP and HTTPS requests are sent as usual with all cookie data. That's why it's up to the server side of the application to compensate with tokens.
Related
I have an http-https redirect configuration set up in NGINX:
server {
listen 80;
server_name localhost;
return 301 https://$server_name$request_uri;
}
My question is: Is there at any point, from the user initially accessing the login page of my application to POSTing his username+password, a time when the credentials are going clear over HTTP before being redirected to HTTPS?
It depends on your login form somewhat (it should always post to the https url only), but based on this info, I think no, the password always goes over https when used as intended.
However, you might want to note a few things and add more protection (defense in depth), because the whole point in attacks is to make things not go as intended. :)
SSL Stripping
An attacker might be able to degrade the connection to http from the user's perspective while the attacker himself maintains a secure connection with the server. Note that this would work even if the server does not even respond on plain http. See this video or this link (among many others). The solution is HSTS (see below).
Attacker injecting plain http request
If the attacker can inject a plain http request in any way into the client browser that sends the credentials over plain http, those credentials will not be protected. This applies to username/password being posted, but also to the session cookie, which is equivalent to user credentials for the duration of the session. So this means if the attacker can for example insert an image with src="http://yoursite.com", the session cookie will be sent plaintext. The response will be a redirect as per your nginx settings, but that's too late. Always setting your session cookie as secure solves this problem (but not the other one about posting the credentials, which can be mitigated by HSTS).
HSTS
Your website should have a Strict-Transport-Security response header, so that once a browser had a chance to talk to the server without a man-in-the-middle attacker removing the header, it will remember to use https even if the user does not explicitly specify it in the url bar.
Strict-Transport-Security: max-age=31536000; includeSubDomains
More info on HSTS is here.
We all know that it's bad to transmit usernames and passwords over plaintext, since they can be easily viewed by anybody looking at the packets, so we use HTTPS to encrypt this data.
I've noticed that many websites just use HTTPS for the login form and use regular HTTP for all other pages (such as StackOverflow). Couldn't somebody see the cookie (like a session cookie) returned from a login form and inject that into their own web requests? Although it won't expose the username and password, it seems like they could impersonate another user by doing this.
Let's say I'm snooping into my friend's internet connection. After my friend authenticates in HTTPS, the server and my friend begin communicating over HTTP and transmit the cookies in plaintext. What is preventing me from using this cookie?
Nothing is preventing you from using the cookie and stealing his sessions. It's a very poor security practice to send cookies over HTTP. In fact this very weakness was used by the Firesheep Firefox extension that made headlines a few years ago. Since then some sites (notably Facebook and Gmail) have moved to HTTPS only. Other sites should follow suit.
It is not really. If an attacker steals the cookie and then uses it, this is known as Session Hijacking.
StackOverflow are aware of this problem and have been looking at moving towards HTTPS everywhere (site network wide).
To prevent a cookie from ever being sent over an insecure connection, the Secure flag should be set. This will stop the browser from sending it over HTTP connections, even if an attacker tried to make it leak from their own site (very easy to do, an attacker could just include <img src="http://www.example.com/anything.jpg" /> in their own site to cause an unsecure cookie to be sent over HTTP and conduct a MITM attack).
As we know, a cookie with Secure attribute means that it just transmitted via a encrypted connection. so my question is if a cookie can be a security one and a not security one. if so,
why or for what ?
As stated, a cookie can have a Secure flag.
If true, the cookie is only sent by the browser for HTTPS requests.
If false, the cookie is sent by the browser for both HTTP and HTTPS requests.
There is no setting for transmission solely on HTTP. The HTTPOnly flag simply stops it being accessible via JavaScript and other client-side languages, it does not affect its HTTP/HTTPS behaviour.
So by setting Secure to false, the cookie will be transmitted both encrypted and decrypted depending on the current protocol.
This is not recommended as the cookie value could be sniffed if sent over the HTTP connection, or forced to by an attacker (e.g. the attacker simply linking to the HTTP site in an image tag on their site will cause the value to be leaked - <img src="http://www.example.com/img.jpg" />).
The Secure and HttpOnly attributes do not have associated values. Rather, the presence of the attribute names indicates that the Secure and HttpOnly behaviors are specified.
The Secure attribute is meant to keep cookie communication limited to encrypted transmission, directing browsers to use cookies only via secure/encrypted connections. If a web server sets a cookie with a secure attribute from a non-secure connection, the cookie can still be intercepted when it is sent to the user by man-in-the-middle attacks.
The HttpOnly attribute directs browsers not to expose cookies through channels other than HTTP (and HTTPS) requests. An HttpOnly cookie is not accessible via non-HTTP methods, such as calls via JavaScript (e.g., referencing "document.cookie"), and therefore cannot be stolen easily via cross-site scripting (a pervasive attack technique).[37] Among others, Facebook and Google use the HttpOnly attribute extensively.
In short, it means that the 'Secure' attribute means it requires secure (ssl) transmission, for example HTTPS.
This is to prevent cookie theft or cookie hijacking. You can have a look at this wiki
You might also want to know about Cookie Encryption or Signed Cookie, a way to made your cookies safe from malicious cookie modification. Basically you append a hash to the cookie value and use it to verify the value of the cookie has not been modified.
I have a site which after the initial login pages (in https) should redirect to a http site.
I have noticed the session cookie is not carried over between the https and http requests.
What would be a secure way to do this?
Right now as an interim solution I generate a one time unique key to use the first time I move from https to http. This, after verified, re-creates the user session.
What would be a secure way to do this?
There isn't one. At best you end up sending session tokens in the clear and are open to session hijacking. At worst, you expose the user to a MitM attack (even on the pages that both you and the user think are secure, as long as they got there from a http only page).
Serve the entire site over HTTPS. The overhead isn't that high and it removes so many potential security pitfalls.
Owasp recommends the synchronizer token pattern to defend against cross-site-request-forgery. If the webpage is sent over HTTP, then a man-in-the-middle will be able to intercept the token. How much of a problem is this?
Attacker can steal much more sensitive information like cookie with MITM, so CSRF attack won't be even necessary. If you're afraid of MITM and eavesdropping, make your webpage go through SSL. Also, make sure to don't have a single non-HTTPS request, as long as it will be enough for MITM attack like SSLStrip. You may additionally send HTTP response header "Strict-Transport-Security: max-age=30000" (or your desired max-age value).
MITM attacks on a CSRF token used over HTTP are almost never going to be a problem, unless the malicious site is on the same network as the victim (and therefore can direct the victim's traffic through itself).
What p0deje said is true, however. If you care about a MITM stealing a CSRF token, you should definitely consider using HTTPS.