The url I am connecting to is my supplier's site which requires that I am logged in to access their inventory pages. These pages are only accessible over http. I copied the cookie sent by my supplier's site and set the expiration date to 0. The cookie contains an ASP.NET SessionId.

Is there a way for me to secure the cookie? And if not, how easy would it be for someone to hijack the cookie and access my suppliers site under my login. From my understanding, the man-in-the-middle attack would have to come from someone between my server and my supplier's server. Is this correct?

3 Answers
3

First step, use https:// for your ajax call. Unless you have code on the supplier's server which is able to decrypt a custom encryption (Say you JSON encode your cookie array, then encrypt it with mcrypt - then decrypt and rebuild on the supplier site), then you're at the mercy of the RESTful API on the supplier's end. If they're not requiring SSL, then you're kind of SOL.

The easiest way to secure any HTTP traffic is to use HTTPS. By wrapping the entire thing in SSL, the only thing visible without decrypting the request is the domain name of the request.

If they only allow for accessing it through HTTP, perhaps you should talk to them about investing in an SSL certificate...even if it is a self signed one (doing it that way offers encryption, but doesn't verify the identity of the server on the other end and so most browsers will throw a fit about it being insecure even though traffic is still encrypted). By your supplier only offering HTTP they are opening themselves up to attack, especially where any sort of session id is concerned.

Do you really mean you access your inventory supplier via HTTP, not HTTPS?

If so, there is nothing you can do with the cookie anyways, because the whole communication is insecure and can be either sniffed or intercepted at will - if you fear this, there is no help.

On the other side, a cookie itself is usually set by the server and has two options available: 1) httponly 2) secure.

1) httponly tells the browser not to make this cookie available to Javascript, but to only send it back via HTTP on the next requests, until it expires.

2) secure tells the browser not to send the cookie via unencrypted communication, i.e. only send it via HTTPS, not HTTP.

Your curl is the browser. Your curl has no javascript, so the first option is useless. And even then your curl must and will know which cookie should be set, and you can easily ignore the servers wish not to make it available to Javascript.

Your curl also will send back the cookie only if you program it to do so. If you think using insecure channels will be a good idea, then the secure flag will not prevent you from doing so, but it adds no security to the cookie itself.

Cookie values are always unencrypted on both sides of the communication. The only security against sniffing is added by using HTTPS. Anything else regarding cookie options is only there to secure the behaviour of browsers, to reduce the risk of the cookie getting known to a third party that should not know about it.