-
-
Notifications
You must be signed in to change notification settings - Fork 15.8k
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
Deprecate disabling HTTP header validation #13609
Conversation
|
@vietj too |
|
My sole concern is not the deprecation but if there's a plan for removal at some point. Sometimes, one side, typically the client one, has zero control over the other side and if it's buggy, it has to live with. |
|
No plans to remove the ability to opt out. I think we'll always need a way to control that aspect. Would be nice to have fewer constructors, though. Maybe we can use s builder pattern. Either here or Netty 5 only. |
codec-http/src/main/java/io/netty/handler/codec/http/HttpRequestDecoder.java
Show resolved
Hide resolved
codec-http/src/main/java/io/netty/handler/codec/http/HttpRequestDecoder.java
Outdated
Show resolved
Hide resolved
codec-http/src/main/java/io/netty/handler/codec/http/CombinedHttpHeaders.java
Show resolved
Hide resolved
codec-http/src/main/java/io/netty/handler/codec/http/DefaultHttpRequest.java
Show resolved
Hide resolved
codec-http/src/main/java/io/netty/handler/codec/http/DefaultHttpMessage.java
Show resolved
Hide resolved
codec-http/src/main/java/io/netty/handler/codec/http/HttpResponseDecoder.java
Show resolved
Hide resolved
|
I'm exploring the builder idea to see if the number of constructors can be cut down a bit. |
4cad674
to
75665b0
Compare
|
@idelpivnitskiy @slandelle With a combination of factories, builders, and configs, I think we now have a much nicer API for both guiding people toward better defaults, and offering all the knobs advanced users might need. Please take a look. |
75665b0
to
30c19a0
Compare
5cfe5f6
to
f89e370
Compare
|
@slandelle @normanmaurer @idelpivnitskiy Rebased this. Are we happy with it? |
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.
Absolutely love refactoring of all request/response and encoder/decoder types. Great work, Chris!
It took me sometime to wrap my head around factory-builder-factory though 😄
See my comments below:
codec-http/src/main/java/io/netty/handler/codec/http/HttpHeadersFactory.java
Outdated
Show resolved
Hide resolved
| /** | ||
| * A configuration object for specifying the behaviour of {@link HttpObjectDecoder} and its subclasses. | ||
| * <p> | ||
| * The {@link HttpDecoderConfig} objects are mutable to reduce allocation, |
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.
Mutability also has problems. WDYT about introducing HttpDecoderConfig interface and HttpDecoderConfigBuilder as a final class? Builder will be a good compromise between memory allocations and providing an immutable config by default. For cases when users need runtime mutability, they can implement interface.
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.
The constructors that take HttpDecoderConfig objects always extract all fields, so I think it's okay.
| * The {@link HttpDecoderConfig} objects are mutable to reduce allocation, | ||
| * but also {@link Cloneable} in case a defensive copy is needed. | ||
| */ | ||
| public final class HttpDecoderConfig implements Cloneable { |
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.
IIRC, there was a recommendation to use a copy-ctor pattern vs implementing a Clineable interface somewhere, maybe in Effective Java?
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.
What was the argument for 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 don't know if this article from 2000 is the latest word on that, but since the field types are not expected to have interior mutability, I think it's fine here.
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.
Yes, that's the one.
It's like a question when to use Atomic* vs Atomic*Updater. Sometimes it's easier to stick to a recommended pattern instead of considering each case independently. Up to you what approach you would like to keep.
codec-http/src/main/java/io/netty/handler/codec/http/HttpHeadersBuilder.java
Outdated
Show resolved
Hide resolved
codec-http/src/main/java/io/netty/handler/codec/http/HttpHeaders.java
Outdated
Show resolved
Hide resolved
codec-http/src/main/java/io/netty/handler/codec/http/DefaultFullHttpResponse.java
Outdated
Show resolved
Hide resolved
codec-http/src/main/java/io/netty/handler/codec/http/HttpHeadersBuilder.java
Outdated
Show resolved
Hide resolved
Motivation: HTTP request/response splitting is a serious vulnerability, which is mitigated by enabling HTTP header validation. We already do header validation by default, but we have many constructors in our HTTP codec that permit turning it off. We should discourage all our down-stream users from turning header validation off. Modification: - Add an HttpHeadersFactory interface, implemented by an HttpHeadersBuilder, for specifying how headers should be constructed. - Add an HttpDecoderConfig for encapsulating all the HttpObjectDecoder parameters. - Deprecate all constructors in our HTTP codec, that allow header validation to be turned off. - Offer alternative constructors to all the newly deprecated ones, that take HttpHeadersFactory. Result: We hopefully encourage integrators to validate headers. And we hopefully get fewer issues reported about disabled header validation when people run security scanners on their code.
This also avoids a future compatibility headache if we were to ever add more fields to it, since that would imply adding more parameters to the private `with` method.
f89e370
to
2c727c3
Compare
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.
Thanks for cleaning the factory/builder!
codec-http/src/main/java/io/netty/handler/codec/http/HttpHeadersFactory.java
Show resolved
Hide resolved
| * The {@link HttpDecoderConfig} objects are mutable to reduce allocation, | ||
| * but also {@link Cloneable} in case a defensive copy is needed. | ||
| */ | ||
| public final class HttpDecoderConfig implements Cloneable { |
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.
Yes, that's the one.
It's like a question when to use Atomic* vs Atomic*Updater. Sometimes it's easier to stick to a recommended pattern instead of considering each case independently. Up to you what approach you would like to keep.
codec-http/src/main/java/io/netty/handler/codec/http/DefaultHttpHeadersFactory.java
Outdated
Show resolved
Hide resolved
codec-http/src/main/java/io/netty/handler/codec/http/DefaultHttpHeadersFactory.java
Outdated
Show resolved
Hide resolved
|
@idelpivnitskiy Addressed all your comments |
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.
Thank you!
|
I'll make a separate PR for Netty 5 since this is too big to just forward-merge. |
This is a forward port of netty#13609, aka 84a13a9. Motivation: HTTP request/response splitting is a serious vulnerability, which is mitigated by enabling HTTP header validation. We already do header validation by default, but we have many constructors in our HTTP codec that permit turning it off. We should discourage all our down-stream users from turning header validation off. Modification: - Remove many constructors in our HTTP codec, that allow header validation to be turned off. - Offer alternative constructors to all the newly removed ones, where header validation is enabled. - Offer alternative constructors, that take HttpDecoderConfig or HttpHeadersFactory instances. - Trailer validation in `DefaultLastHttpContent` is now enabled by default in the `DefaultLastHttpContent(Buffer, HttpHeaders)` - Add more guidance in the javadocs. Result: We hopefully encourage integrators to validate headers. And we hopefully get fewer issues reported about disabled header validation when people run security scanners on their code.
This is a forward port of #13609, aka 84a13a9. Motivation: HTTP request/response splitting is a serious vulnerability, which is mitigated by enabling HTTP header validation. We already do header validation by default, but we have many constructors in our HTTP codec that permit turning it off. We should discourage all our down-stream users from turning header validation off. Modification: - Remove many constructors in our HTTP codec, that allow header validation to be turned off. - Offer alternative constructors to all the newly removed ones, where header validation is enabled. - Offer alternative constructors, that take HttpDecoderConfig or HttpHeadersFactory instances. - Trailer validation in `DefaultLastHttpContent` is now enabled by default in the `DefaultLastHttpContent(Buffer, HttpHeaders)` - Add more guidance in the javadocs. Result: We hopefully encourage integrators to validate headers. And we hopefully get fewer issues reported about disabled header validation when people run security scanners on their code.
Motivation:
HTTP request/response splitting is a serious vulnerability, which is mitigated by enabling HTTP header validation. We already do header validation by default, but we have many constructors in our HTTP codec that permit turning it off. We should discourage all our down-stream users from turning header validation off.
Modification:
DefaultLastHttpContentis now enabled by default in theDefaultLastHttpContent(ByteBuf, HttpHeaders)constructor (Behavioral change!)DefaultHttpHeadersfor those who want to use custom header validators.Result:
We hopefully encourage integrators to validate headers. And we hopefully get fewer issues reported about disabled header validation when people run security scanners on their code.