[Core] Cookies Not Marked As Secure

[iancarroll]

Cookies created by Blesta are not marked as secure. Pretty easy to fix.

 

Strict-Transport-Security does fix this, but it would be better for Blesta to set it. Is there a quick modification I can make in the meantime to patch this?

[Paul]

You might find this useful http://stackoverflow.com/questions/24129201/add-secure-and-httponly-flags-to-every-set-cookie-response-in-apache-httpd

 

We suggest forcing SSL/TLS with your web server, and setting the necessary flags through the web browser. Many people still use Blesta without SSL, which isn't a good idea but broken installs are no fun either.

[iancarroll]

(I use Nginx, but there might be something similar)

 

Making it a configurable option or just checking if the session is over TLS before setting the flag would work fine. The point of the flag is to protect against you not forcing TLS (server misconfig) when your server normally would use it.

[Paul]

We will consider that. There's also a new setting in 3.4 (currently in beta 2, final out soon) under Staff groups to force logout on IP change. This prevents an attacker from using a stolen cookie. It's enabled by default for new installs and new staff groups, but if you're upgrading you'll need to explicitly enable it.

[iancarroll]

Thanks. Is the file that contains the cookie logic encoded (is it possible to make the change myself)?

[Paul]

Thanks. Is the file that contains the cookie logic encoded (is it possible to make the change myself)?

 

Take a look at /components/session/session.php, I *think* that's what you want. Cody or Tyson would know better than me though.

[iancarroll]

I'm trying the following patch but it doesn't work. I take it there's additional code elsewhere...

 

http://pastie.org/9796661

[Paul]

I'm trying the following patch but it doesn't work. I take it there's additional code elsewhere...

 

http://pastie.org/9796661

 

Check out /app/models/users.php. I believe this is where the session is set.

I'll ask Cody or Tyson to take a look at this thread.

[Max]

There's also a new setting in 3.4 (currently in beta 2, final out soon) under Staff groups to force logout on IP change. This prevents an attacker from using a stolen cookie.

 

Note that you already set the HttpOnly flag, so it is not possible for an attacker to steal the cookie through any Javascript injection vulnerability anyway. Which is good.

If you did not have that flag, the IP restriction could be used as an alternative protection against that.

 

However, this thread is about the Secure flag, and I do not think your IP restriction helps at all for situations that flag is actually for.

Which are situations in which the attacker can actually capture and manipulate your traffic...

 

 

Imagine the following situation:

 

• You are using the Internet at a public location, e.g. at a conference, using a public wifi access point.
• You are logged into Blesta using SSL. It displays the padlock icon and everything, so you think it is safe.

 

Now what could possibly go wrong with that?

 

Well, if I were the rogue wifi access point operator, your laptop is connected to, and you happen to visit any random other (non-SSL) site during the same session (or a website controlled by me), I could inject <img src="http://your-blesta-server/" width=0 height=0> in your traffic. Causing the cookie to be sent in the clear, and intercept that.

Even if your webserver is configured to automatically redirect users requesting http to https, your browser will still send all cookies set previously for that site in the clear first as part of the http request, before it is being redirected.

And since you are using MY connection, using MY IP, the IP restriction will not do any good.

I can send requests using my own IP too, you know...

 

When a Blesta user accesses the site through SSL it really should set the Secure flag when setting any cookies, so the browser knows it is to only allowed to send the cookies with https requests.

It also should regenerate the session id number and invalidate the old one, if the user did access Blesta through insecure HTTP before that point.