2 Answers
2

Running the sites under HTTPS is good but it will not mitigate the types of attack against the lack of HttpOnly and Secure flags.

In the case of Secure cookies without HttpOnly, they could be read by an XSS attack should an XSS flaw exist on a site.

If HttpOnly is set, but not Secure then an attacker could force the browser to leak the cookie accross plain HTTP:

Say your website is https://www.foo.com and you set a session ID cookie with HttpOnly but not Secure. If the attacker could get a user to visit their own website (or it could be a forum, etc, that the attacker has posted on) the attacker could have embedded an image tag on their own page: <img src="http://www.foo.com/bar.jpg" />. It is not necessary for the image to exist, nor the fact that your server has port 80 open.

Because the Secure flag is not set, the once private session ID is now leaked across an unencrypted HTTP connection as the browser will send all non Secure cookies with the request. This would open up your application to a Man in The Middle attack. In the case of port 80 being closed on your server, the attacker could simply MITM this connection and redirect it to another server that is open.

HTTPOnly isn't really related to HTTPS. It instructs the browser not to make the cookie visible to JavaScript. So if there is an XSS flaw, regardless of HTTPS it should not be able to steal the cookie through that flaw.

The Secure if received over HTTPS instructs the browser to only send the cookie over HTTPS connections. It's meant to prevent an attacker from sniffing the cookie over the network (open wireless etc.).

HTTPOnly does not stop sniffing on an open wireless network. Secure does not prevent JavaScript from reading the cookie in case of XSS.