Block auto-indexing of static assets more narrowly #8555
+12
−22
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In c870cc3, we added rules to 404 instead of serving a 403 or auto-indexing on static asset directories in automate-ui and dex respectively. The regexes used are overly broad in that they cause any URIs ending in "dex" or "assets" to 404[1] including unrelated API endpoints. For example, this is blocking us from publishing policyfiles named "index". I'm not so familiar with these internals, but I believe it's sufficient to use regexes `^/dex/` and `^/assets/` etc instead of `.dex` and `.assets` etc. I also blocked auto-indexing of two other static asset directories under dex (`fonts` and `font-awesome-*`). I made a note that ideally dex itself should be handling this. I'll note that the 404s served at the loadbalancer look different than the 404s of underlying servers, so an attacker can still know they "hit" something. For example: ``` $ curl -k -v -H 'Host: chef-automate' 'https://127.0.0.1/dex/foo/bar' ... < HTTP/2 404 < date: Wed, 28 Aug 2024 17:35:03 GMT < content-type: text/plain; charset=utf-8 < content-length: 19 < x-content-type-options: nosniff < x-xss-protection: 1; mode=block < x-content-type-options: nosniff < 404 page not found $ curl -k -v -H 'Host: chef-automate' 'https://127.0.0.1/dex/static' < HTTP/2 404 < date: Wed, 28 Aug 2024 17:35:55 GMT < content-type: text/html < content-length: 146 < x-xss-protection: 1; mode=block < strict-transport-security: max-age=63072000; includeSubDomains < x-content-type-options: nosniff < <html> <head><title>404 Not Found</title></head> <body> <center><h1>404 Not Found</h1></center> <hr><center>nginx</center> </body> </html> ``` At least it doesn't auto-index, but I do question the integrity of this approach. As I stated above it should be handled by dex itself. I suspect there's a way to handle the automate-ui assets more elegantly as well. [1]: https://community.progress.com/s/article/Paths-or-URIs-ending-with-dex-or-assets-Lead-to-a-404-in-Chef-Automate Signed-off-by: Adam Saponara <[email protected]>
👷 Deploy Preview for chef-automate processing.
|
|
I added this as a feature request as well. If anyone else comes across this PR, please feel free to upvote it too. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In c870cc3, we added rules to 404 instead of serving a 403 or auto-indexing on static asset directories in automate-ui and dex respectively. The regexes used are overly broad in that they cause any URIs ending in "dex" or "assets" to 4041 including unrelated API endpoints. For example, this is blocking us from publishing policyfiles named "index".
I'm not so familiar with these internals, but I believe it's sufficient to use regexes
^/dex/and^/assets/etc instead of.dexand.assetsetc. I also blocked auto-indexing of two other static asset directories under dex (fontsandfont-awesome-*). I made a note that ideally dex itself should be handling this.I'll note that the 404s served at the loadbalancer look different than the 404s of underlying servers, so an attacker can still know they "hit" something. For example:
At least it doesn't auto-index, but I do question the integrity of this approach. As I stated above it should be handled by dex itself. I suspect there's a way to handle the automate-ui assets more elegantly as well.
🔩 Description: What code changed, and why?
Fix nginx 404 rules
⛓️ Related Resources
👍 Definition of Done
For us, the ability to publish policyfiles named "index"
👟 How to Build and Test the Change
curl assets and dex endpoints
✅ Checklist
All PRs must tick these:
With occasional exceptions, all PRs from Progress employees must tick these:
make spellin any component directory)All PRs from Progress employees should tick these if appropriate:
Please add a note next to any checkbox above if you are NOT ticking it.
📷 Screenshots, if applicable
n/a
Footnotes
https://community.progress.com/s/article/Paths-or-URIs-ending-with-dex-or-assets-Lead-to-a-404-in-Chef-Automate ↩