-
Notifications
You must be signed in to change notification settings - Fork 5.5k
[http] Handle faulty filters from removing required request headers #13470
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
Merged
mattklein123
merged 25 commits into
envoyproxy:master
from
asraa:remove-release-assert-h1
Nov 5, 2020
Merged
Changes from 4 commits
Commits
Show all changes
25 commits
Select commit
Hold shift + click to select a range
4d5f6f1
draft
asraa 3610e3e
Merge remote-tracking branch 'upstream/master' into remove-release-as…
asraa 2f4e85d
Merge remote-tracking branch 'upstream/master' into remove-release-as…
asraa bae336c
include tests for h/2 and add response code
asraa e6e0602
change response detail name
asraa 11973d5
move to per iteration, in header utility
asraa 2e24391
fix comments
asraa ef6cf11
remove extra line
asraa 0286898
remove extra build line
asraa f4195a1
Merge remote-tracking branch 'upstream/master' into remove-release-as…
asraa fdeedba
fix test and rel note
asraa 2f7aa2d
change encodeheaders return val
asraa 77f80c7
Merge remote-tracking branch 'upstream/master' into remove-release-as…
asraa 0dc8a1d
cleanup
asraa 664cd66
fix tests
asraa 0aed751
add what required headers are checked
asraa 979473c
fix quiche tests
asraa b2d4e1d
fix all quiche
asraa 4346a95
fix upstream tests
asraa db86e97
add router test
asraa 9372e57
fix extension test
asraa b0384af
fix legacy tests
asraa 6fd4d2f
address comment
asraa 7afd34b
remove FM checks and add a test with a direct response
asraa b7203ac
Merge remote-tracking branch 'upstream/master' into remove-release-as…
asraa File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,42 @@ | ||
| #include <string> | ||
|
|
||
| #include "envoy/http/filter.h" | ||
| #include "envoy/registry/registry.h" | ||
| #include "envoy/server/filter_config.h" | ||
|
|
||
| #include "common/http/header_utility.h" | ||
|
|
||
| #include "extensions/filters/http/common/pass_through_filter.h" | ||
|
|
||
| #include "test/extensions/filters/http/common/empty_http_filter_config.h" | ||
| #include "test/integration/filters/common.h" | ||
|
|
||
| namespace Envoy { | ||
|
|
||
| // Faulty filter that may remove critical headers. | ||
| class InvalidHeaderFilter : public Http::PassThroughFilter { | ||
| public: | ||
| constexpr static char name[] = "invalid-header-filter"; | ||
|
|
||
| Http::FilterHeadersStatus decodeHeaders(Http::RequestHeaderMap& headers, bool) override { | ||
| // Remove method when there is a "remove-method" header. | ||
| if (!headers.get(Http::LowerCaseString("remove-method")).empty()) { | ||
| headers.removeMethod(); | ||
| } | ||
| if (!headers.get(Http::LowerCaseString("remove-path")).empty()) { | ||
| headers.removePath(); | ||
| } | ||
| if (Http::HeaderUtility::isConnect(headers)) { | ||
| ENVOY_LOG_MISC(info, "REMOVING Host FROM CONNECT"); | ||
| headers.removeHost(); | ||
| } | ||
| return Http::FilterHeadersStatus::Continue; | ||
| } | ||
| }; | ||
|
|
||
| constexpr char InvalidHeaderFilter::name[]; | ||
| static Registry::RegisterFactory<SimpleFilterConfig<InvalidHeaderFilter>, | ||
| Server::Configuration::NamedHttpFilterConfigFactory> | ||
| decoder_register_; | ||
|
|
||
| } // namespace Envoy |
This file contains hidden or 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
This file contains hidden or 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we just assert checkHeaderMap?
Also maybe update encodeHeaders include comments about this requirement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also are we comfortable with the router being the terminal filter? I know it is today but I thought once we add upstream filters that won't be the case any more. I wonder if we should just handle errors here and return a status or something? cc @snowp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would still be the terminal filter as far as the HCM is concerned, but it definitely wouldn't be the last extension point that could be modifying the headers before we hit the upstream codec. I haven't looked at this PR in detail, but conceptually it seems like doing this validation makes more sense in the codec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh! Yes. I could change
encodeHeadersto return a status that could be handled in the caller's code.Doing it in the codec would be a lot cleaner in terms of extensibility and not worrying about the problem happening later. What worried me was how large-scale the change would be if
encodeHeadersreturned a status. I'll give it a try now, and see if I hit bad trouble.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we may run into the problem where a buggy filter removes a required header and then subsequent filter in the chain crashes because it expects the header to be in the map. Would it make sense to check the integrity of the header map after calling
decodeHeaders()for each filter and abort with 500 if a filter messes up the header map?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolution: Fixed with per-iteration check in the filter manager. Avoid the issue of relying on router filter being terminal. FM sends back direct response and debug logs point to which filter made the error.
@snowp: I don't think there's a way to get the codec to do these checks. The codec has no way of handling the error at that point. I think future extensions that may end up manipulating need to harden against causing errors as well.
re original comment: encodeHeaders doc string updated, ASSERT on required header check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I mildly prefer having this function do the checks, and return a failure status, rather than having the caller have to know to do the check beforehand. What do folks think about that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the concern about doing the check here is it will make the change much larger. In principle I agree it would be better, but this seems fine to me also. I'm fine either way.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could build it off as a start, my concern is that every caller of
encodeHeaderswould need to handle the status (if absl::Status is used, whose result can't be ignored), and I'm not sure if it's worth implementing in every place. I could start withIgnoreError()calls for now though. I do think the change is better done inside, especially if there are other places that will modify headers before encoding.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tracing through the change now. I'll push the change as soon as I can get tests working, can always revert later.