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?
It is not really. If an attacker steals the cookie and then uses it, they can then hijack the session.
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 insecure cookie to be sent over HTTP while they eavesdrop on the connection.
The Secure flag is stored as an attribute of the cookie in the browser, and is a boolean (true/false) value. If it is set to true, the browser will only send it to the site if the protocol is HTTPS. False means it is sent over the HTTP protocol as well.
The Same Origin Policy is lax for cookies in that HTTP and HTTPS share the same origin, unlike the remainder of the browser security model. In order to strengthen this, cookie prefixes are also recommended. In addition to the secure flag, the prefixes will also guard against an active manipulator in the middle (MITM) from setting the attacker's cookie over plain HTTP and "pushing" their victim onto the attacker's own session. This is because the Secure flag stops a browser sending the cookie over HTTP, but does not stop a cookie with the same name as the session cookie from being set over HTTP by an attacker, unless prefixes are used. One example of an attack vector could be logging in the victim as the attacker on a search engine where the attacker would then be able to check their search history as the searches would have been made whilst the victim was logged in as the attacker.
Lastly, HSTS (HTTP Strict-Transport-Security) is recommended which will make the browser automatically upgrade from plain HTTP to HTTPS before any connection is made to the server.