Exactly. A better, or at least more general, mitigation than enabling HSTS (though that's a good idea anyway), is to not design your web application in such a way that a modified cookie in the client creates a vulnerability. Since cookies are stored in the client, they are always going to be susceptible to malware on the user's machine. So, trusting that the contents of a cookie were authored by the service receiving them is a bad idea in general. Cookies should be stored along with some additional information that verifies their authorship.

A relatively simple way to accomplish this is to have your application include an HMAC in the cookie contents, and verify it whenever the cookie is received. e.g, if you are storing $session_id in a cookie, change your cookie contents to be "$session_id:$hmac_of_session_id", and verify the HMAC every time a cookie is presented.

Now a user, or malware, or a MITM, is not in the position to take over or modify a different user's session simply by altering the cookie, since they will not be able to produce a valid HMAC (the key is never shared with the user).

If even storing the key in your web frontends is too risky, you could use RSA or DSA signatures, only store the public key in the web frontend that verifies cookies, and store the private key in a more hardened cookie-signing service that isn't directly exposed to external networks. This service can be invoked when new sessions are created or upon user login, if applicable.

On top of this, if the client supports ChannelID, you should include the ChannelID in the message that is HMAC'd, so that stolen cookies cannot be reused on other machines.