Control panel security improvements

[gompster]

Hi,

I would like to suggest some security improvements to the control panel web application:

• Add the ability to restrict access to the control panel based on a whitelist of IP addresses (which could be configured in the control panel itself). An administrative interface should not be publicly accessible.
• Use a generic 'login failed' message instead of giving an attacker information about whether a username exists in the system or not.
• Implement protection against brute-force password guessing attacks, preferably by requiring the user to solve a CAPTCHA after ~5 failed login attempts.
• Separate the login page from the rest of the application so that the URL structure (or available functionality) of the application is not revealed to an unauthenticated user.
• Finally you may want to implement additional protection mechanisms against cross-site request forgery attacks.

[JoshData]

Implement protection against brute-force password guessing attacks, preferably by requiring the user to solve a CAPTCHA after ~5 failed login attempts.

It would be nice if this were managed by fail2ban so we have a consistent policy across services.

Finally you may want to implement additional protection mechanisms against cross-site request forgery attacks.

Do you see a vulnerability or is this hypothetical?

[aspdye]

We could just create a "jail" for Fail2Ban so that Roundcube, ownCloud AND the Admin Panel would be secured :wink:

[gompster]

Fail2ban integration sound like a good plan, but beware of undesired lockouts. I opted for a CAPTCHA approach to make sure that administrators are always capable of accessing the control panel.

I dived a little deeper in the session handling in the control panel. It seems cross-site request forgery is not possible because the target user's browser will not append the Authorization HTTP header automatically to the forged request.

There is however one other issue that comes to mind when storing credentials (or some form of credentials) in the local storage. Please beware that every other page/application on the same domain as the control panel will be able to access local storage information. Should other applications contain vulnerabilities that allow an attacker to execute JavaScript (cross-site scripting vulnerabilities), the attacker is able to obtain the control panel's credentials and use them in his own browser. Using cookies instead of the local storage would be an improvement, since cookies can be equipped with a HttpOnly flag that prevents client-side scripts from accessing the cookie value.

[gompster]

And while we are at it, another good idea would be to implement protection against clickjacking by letting nginx set an X-Frame-Options HTTP header in every HTTP response.

[aspdye]

Interesting Aspect! So ownCloud, Roundcube or Static Security Vulnerabilites could "Break" the whole Control Panel and the Mailserver.

@JoshData Security Priority Bug?!

[JoshData]

Fair enough. I was trying to get around CSRF attacks by using local storage, but I see how that opens up another avenue. (Note: CSRF attacks are an actual vulnerability, whereas local storage is a hypothetical problem that relies on a possibly nonexistent vulnerability elsewhere.)

[gompster]

So far, I did the following to harden my mail-in-a-box server:

• Harden Postfix SSL configuration by disabling the weak SSLv3 protocol and weak RC4 algorithms:

postconf smtpd_tls_mandatory_protocols=\!SSLv2,\!SSLv3
postconf smtpd_tls_protocols=\!SSLv2,\!SSLv3
postconf smtpd_tls_ciphers=high

This results in a better rating at https://ssl-tools.net/mailservers.

• Add protection against clickjacking attacks by adding an X-Frame-Options HTTP header. In /etc/nginx/conf.d/local.conf, add the following directive to the server section:

add_header X-Frame-Options "SAMEORIGIN";

• Only allow whitelisted IP addresses to access the control panel. In /etc/nginx/conf.d/local.conf, add the following to the location /admin/ section:

allow $MY_IP;
deny all;

Replace $MY_IP with the IP address that should have access to the control panel. Other IP addresses that will try to access the control panel will be presented a HTTP 403: Forbidden response.

It would be nice if users could ultimately configure the IP whitelist from the control panel. The other two improvements are quick wins. The improvements in my first post should also be easy to implement. Rebuilding the application to use sessions instead of the local storage would take some more work, so perhaps this is something for the long run.

[JoshData]

Harden Postfix SSL configuration by disabling the weak SSLv3 protocol and weak RC4 algorithms:

See #611 for that.

Add protection against clickjacking attacks by adding an X-Frame-Options

Submit a PR to add that to https://github.com/mail-in-a-box/mailinabox/blob/master/conf/nginx-primaryonly.conf?

Rebuilding the application to use sessions instead of the local storage would take some more work

Maybe it's better, at least in the short term, to simply not have persistent logins to the control panel. That would drop localStorage and wouldn't break the architecture at all. The control panel front-end would store the privileges in a javascript variable, rather than in locaStorage.

[scottnzuk]

Login Cross Site Request Forgery CSRF XSRF.pdf

So I run a secury scan on my mail in a box install and this critical security flaw was reported. (hopefully this is the correct place to report)

[scottnzuk]

FULL REPORT - All Findings

Detectify_FullReport_kiwiz.co.uk_2018-01-04T16.12.01+00_00.pdf

[yodax]

Ideally open a new issue for this. But first look into this line of code.

[ghost]

Why not use a dedicated Flask plugin, something like FlaskSecurity? This way we don't reinvent the wheel.