Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update: HTTP_Headers_Cheat_Sheet #1401

Open
jfhr opened this issue May 11, 2024 · 3 comments
Open

Update: HTTP_Headers_Cheat_Sheet #1401

jfhr opened this issue May 11, 2024 · 3 comments
Labels
ACK_OBTAINED Issue acknowledged from core team so work can be done to fix it. HELP_WANTED Issue for which help is wanted to do the job. UPDATE_CS Issue about the update/refactoring of a existing cheat sheet.

Comments

@jfhr
Copy link
Contributor

jfhr commented May 11, 2024

What is missing or needs to be updated?

Some security headers such as Content-Security-Policy are (as far as I can tell) relevant on all HTML pages, including error pages. But the recommended configuration for Apache or nginx only sets headers on successful responses (2xx or 3xx).

See the Apache docs on Header set:

The optional condition argument determines which internal table of responses headers this directive will operate against: onsuccess (default, can be omitted) or always. The difference between the two lists is that the headers contained in the latter are added to the response even on error, and persisted across internal redirects (for example, ErrorDocument handlers). [...]

And the nginx docs on add_header:

Adds the specified field to a response header provided that the response code equals 200, 201 (1.3.10), 204, 206, 301, 302, 303, 304, 307 (1.1.16, 1.0.13), or 308 (1.13.0). Parameter value can contain variables. [...]
If the always parameter is specified (1.7.5), the header field will be added regardless of the response code.

Example of how that could be problematic: A site that shows user generated content has an XSS vulnerability in their app code, but it doesn't take effect because the server admin configured a strong CSP using the recommended Apache/nginx configuration. However, the CSP is not sent on 404 pages. If the app adds a feature to show content on 404 pages (ie. "What you're looking for doesn't exist, but check out this instead"), the XSS vulnerability could now be exploited.

How should this be resolved?

Add always to the recommended configuration for Apache and nginx, or add an explanation that the default is to only set headers on success responses.

Apache:

<IfModule mod_headers.c>
Header always set X-Frame-Options "DENY"
</IfModule>

nginx:

add_header "X-Frame-Options" "DENY" always;
@jfhr jfhr added ACK_WAITING Issue waiting acknowledgement from core team before to start the work to fix it. HELP_WANTED Issue for which help is wanted to do the job. UPDATE_CS Issue about the update/refactoring of a existing cheat sheet. labels May 11, 2024
@jmanico
Copy link
Member

jmanico commented May 13, 2024

This is a great piece of feedback, care to PR?

@mackowski mackowski added ACK_OBTAINED Issue acknowledged from core team so work can be done to fix it. and removed ACK_WAITING Issue waiting acknowledgement from core team before to start the work to fix it. labels May 17, 2024
@mackowski
Copy link
Collaborator

@jfhr do you want to make a PR for that?

@jfhr
Copy link
Contributor Author

jfhr commented May 18, 2024

Hey thanks for the feedback, I've created a PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ACK_OBTAINED Issue acknowledged from core team so work can be done to fix it. HELP_WANTED Issue for which help is wanted to do the job. UPDATE_CS Issue about the update/refactoring of a existing cheat sheet.
Projects
None yet
Development

No branches or pull requests

3 participants