New cheat sheet proposal: Apache HTTP Server

[ghost]

Thanks you for proposing a new cheat sheet.

Please provides the following information about your proposal:

1. Which security issues are bring or commonly meet when someone must work on this topic?
   Most web servers completely undermine any security that was built into the application. It can render all app security code pointless. Very important to get this right.
2. What is the objective of the cheat sheet?
   Make an updated single source of truth for a generally secure Apache config.
3. What the CS will bring to the reader?
   Eliminate the need to rely on 10 year old+ documentation that is scattered across the internet and often wasn't even right back then. Actually explain Apache HTTP Server in a way people not committing to the source code can actually understand.

Thanks you again for your contribution 😃

[righettod]

OK from my side.

@jmanico Do you are OK with this proposal?

[righettod]

As Jim is currently busy, i validate the proposal.

[righettod]

Ping me when you will start working on it in order that i pass the issue from the backlog to pending.
Thanks you in advance 😃

[ghost]

I have got this started: https://github.com/danehrlich1/very-secure-apache/blob/master/apache2.conf
That is pretty much every option you can set at the Apache level. Need to cleanup + add more stuff + get in format for this repo.

Things included:

• all 8 HTTP Security Headers you can possibly set
• etags, tokens, signatures, and traces all disabled
• http 1.1+ required
• TLS 1.2+ required
• Strong Ciphers only with HonorCipherOrder on
• Redirect logic from HTTP Port 80 to HTTPS

[righettod]

Hi,
OK thanks for the feedback.
I affect the issue to you and it add to the Pending area.

[Malvoz]

I'd like to help with this.

H5BP have for a long time been providing developers with a terrific boilerplate of apache security configs, and I feel obligated mentioning them: https://github.com/h5bp/server-configs-apache

If there's anything to take away from this comment; I would like to highlight one thing when it comes to HTTP (security) headers:

We need a consensus of which headers applies to which Content-Types. I'll refer you to h5bp/server-configs-apache#187 for more info on that.

[righettod]

Thank you very much for your proposal, feel free to submit a PR 😃

[righettod]

@danehrlich1 Any news about the PR for this issue ? Thank you very much in advance for your feedback 😃

[Malvoz]

feel free to submit a PR

This is not a small task. If you are referring to my proposal of mapping out which headers applies to which Content-Type.

I briefly reviewed, and commited to @danehrlich1's PR. There are some very debatable defaults in there, quick example:

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

This implies all subdomains are HTTPS, and although I agree they should be, this configuration with the (non-standard) preload directive is irreversible (from what I can remember) per the docs in https://hstspreload.org/.

[jmanico]

HSTS preload is easily reversible : https://hstspreload.org/removal/

[Malvoz]

@jmanico

https://hstspreload.org/#removal

Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers. Don't request inclusion unless you're sure that you can support HTTPS for your entire site and all its subdomains in the long term.

Yes it's not the end of the world, but there should be detailed information to the configurations.

[jmanico]

Luckily inclusion in HSTS preload list has significant requirements as you can see from: https://hstspreload.org/#submission-requirements. It's rare when site owners add themselves to preload lists  "on accident". But you are right, if you are preloaded and depend on HTTP resources, you are stuck until the next browser update cycle at best. Site owners usually have better luck upgrading HTTP resources to HTTPS fast vs. trying to get preload delisted.

[Malvoz]

Also, the example CSP is rather weak in terms of strictness. I'd like to refer you to https://github.com/h5bp/server-configs-apache/blob/master/src/security/content-security-policy.conf for a strict (https://csp.withgoogle.com/docs/strict-csp.html) example base policy. But which also should, IMO, include object-src 'none'. See details for that motivation in my proposal for H5BP here: h5bp/server-configs-apache#190

I've never contributed to OWASP before and I'm unsure of the course of action.

[jmanico]

I do not agree with the cited documents at all, I state with respect. All CSP policies should start with default-src 'none' and build from that, ideally. That way object-src 'none' is implicit and is not needed. Principle of last privileged. no unsafe-inline or unsafe-eval is also key if you want to avoid XSS. Aloha, Jim

[ThunderSon]

About the preload, I'd suggest removing it from the default configuration and adding it as a note for web masters that are managing the domain. A lot folks will be using subdomains and will inject preload, which doesn't hurt by default, but doesn't provide anything extra if they don't know what it is.

About CSP, I'd prefer having a not so strict CSP, and a reference to the CSP CS with some Apache examples instead. Having a strict CSPs might get people into trouble without actually reading up a bit on it as it is a bit hard to implement it for new-comers.

[jmanico]

I do agree drop preload from the default policy. It requires careful planning.

[Malvoz]

@jmanico

All CSP policies should start with default-src 'none' and build from
that, ideally.

default-src only affect fetch directives, leaving document- and navigation directives to their defaults. This is less strict than e.g. setting frame-ancestors to 'self' or 'none' (following the same strictness as the OWASP example X-Frame-Options: deny).

However, setting no document/navigation directives aligns better with @ThunderSon's opinion on having it less strict by default.

Contrary to what I may have indicated, I don't really have strong opinions but I appreciate a dialog. ^^

[righettod]

@Malvoz Take the time you need, it was just to "keep the ball rolling" and make a tour on the different issues in pending state at project level.
It's part of my role as PL 😃
Take all the time you need, no pressure, no delay 😃

[ThunderSon]

@Malvoz We're more than happy to have discussions. We need to give you some feedback as well on how to proceed with the issue/PR. CSP is a hot topic recently and it is worth the investment.
CSP is better planned than forced, yet having a good and secure policy is more than welcome to be mentioned, but not set by default. I recommend checking the talks mentioned in the references of the CSP CS.

[ghost]

@Malvoz I 100% agree with you. Preload should be taken out. I am shocked I put that in there. That only works if you properly follow the preload requirements, doesn’t work for self-signing in testing, blah blah.

[ghost]

@righettod I can work on this more. The only thing though is...you’re never 100% sure with Apache. I’ve literally had different devs on the mailing list for httpd, and these guys are absolutely brilliant, tell me to do different things. The source code is so old...no one is totally sure. A good example of this is that recently, no one knew all the directives you could put in .htaccess, whose source code is based on a different web server (NCSA for University of Illinois) from like 1993.

I’ll finish it, but I am going to add two warning labels to the top:

• blah blah blah no Apache config tutorial is 100% correct and there are different opinions on what is the most secure blah blah blah
• a note that some Operating Systems, such as RHEL/CentOS, have the Apache2.conf spread out over several files and not in 1 (apache2.conf)or sometimes 2 files like Debian/Ubuntu

[ghost]

@Malvoz I would love to work with you. I’ve already learned a ton from your comments here.

[jmanico]

But preload is still important. Can you add a second header with comments and caveats that includes the preloading?

…

-- Jim Manico

On May 29, 2019, at 4:12 PM, Dan Ehrlich ***@***.***> wrote: @Malvoz I 100% agree with you. Preload should be taken out. I am shocked I put that in there. That only works if you properly follow the preload requirements, doesn’t work for self-signing in testing, blah blah. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ghost]

1. @jmanico Agree and that can be done as a good compromise.

2. I'd also like to note...if you are installing Apache from apt or yum or dnf you have a very old version in many cases. It's been patched for security stuff, but other than that like the default Debian one is 18+ months old.

3. I've been playing around with HTTPD's official docker image which has the latest, 2.4.39. Interesting configuration layout (makes more sense actually), many new features. Will somehow work this way into the cheatsheet. People need to use that Docker container, or at least borrow its scripts for installation for sure. https://hub.docker.com/_/httpd

[ThunderSon]

I really like how indulged you are in the Apache configuration versions and how complicated it can get.
The mentioned points, such as preload and CSP, I'd recommend having them in comments and have some notes with them for users to apply.
The notes that you want to mention are okay as well.

I'd recommend pushing for the PR, and not worrying as much about these minimal points 😄

[ThunderSon]

@danehrlich1 @Malvoz Hello! Any status on the issue?

[Malvoz]

Due to the fact that not all apache directives are accessible in the context of .htaccess files, for a large percentage of developers that do not have access to the main server configuration file (which is almost always the case of shared hosting), half of @danehrlich1's configurations either does nothing in an .htaccess file, or rather, most likely ends up returning a 500 Internal Server Error status. IMO, this Apache configuration must be .htaccess-first, with additions for users with such server access.

[mackowski]

Personally I think that the best way to address issues is to create a PR with proposal. That way we will be able to add comment to specific line and try to resolve it and avoid statements like 'large percentage'.
I can also suggest that even is something is not available from .htaccess but can increase security we should recommend it but also mention that it is not accessible in the context of .htaccess files. Or you can create two cases - first when you have access to the main server configuration file and second when you do not have it.

[mackowski]

@danehrlich1 hey, what is the status of this issue? Do you need any help from us?

[ghost]

Let me just get it in and over with. Then we can edit it there still but at least we've heaved it over the finish line. 72 hours.

[ThunderSon]

This CS will not be picked up by the team in the coming time period, and as such, this issue will be closed.