Pawel,
On 4/18/24 20:32, Pawel Veselov wrote:
On Thu, Apr 18, 2024 at 9:40 AM Adwait Kumar Singh <adwsi...@gmail.com> wrote:
I'm not (yet) convinced distinguishing between those scenarios is always
going to be possible.
I have a Tomcat patch which we use at work to do this, i.e always close the
connection if HTTP parsing fails but not if it's a user set status. I can
create a PR for feedback.
It can't be that straightforward though. The HTTP parsing can very well fail
well past the point the application was invoked, and returned a status, during
chunked request parsing. The server can't respond with another error though,
as the headers are/can be committed, it has no recourse but to try to send them
if possible, and then shutdown the connection.
Assuming that the container is still in charge of the HTTP part of
things, then the container definitely knows if the request has
experienced some problem with e.g. chunked content.
Tomcat has private information about requests that it keeps separate
from what applications can (usually) get access to, and it could simply
mark a request as "requiring connection termination" and doing that at
the appropriate time when execution finishes with the application and
returns to the container.
And handling incomplete body reads from the application is also
going to be a nuisance that has to be dealt with. Tomcat will have to
consume the remainder of the body without application doing so
(Tomcat already does this.)
, which may not be desirable in all cases, and will require either an
API change to be supported as being signalled by the application
(here is my status, but PLEASE don't break the HTTP connection), or
requiring the application to diligently consume the body till the end
before returning service back to Tomcat, or having that as a
configuration parameter.
I'm not sure this is different from today.
A new API isn't strictly necessary, here. The application can
communicate with the container using request attributes. But I'm not
sure anything like that is needed.
I actually don't know how Tomcat deals with bodies that aren't fully read by
the app right now. I would very much like to know for sure.
Tomcat does one of two things:
1. Reads the remainder of the request entity and discards it
2. Closes the connection without finishing the read
I believe it tries (1) for a while and, after some configurable number
of bytes (<Connector> maxSwallowSize), it switches to (2) and gives up.
-chris
On Thu, Apr 18, 2024 at 8:42 AM Mark Thomas <ma...@apache.org> wrote:
On 18/04/2024 15:18, Stefan Ansing wrote:
Hi Rémy, Mark,
I just want to make sure that we’re understanding each other. I can see
that the connection needs to be closed in certain conditions to prevent
request smuggling attacks. I certainly don’t want to change that
behaviour.
However, I’m facing a scenario where an application is responding to a
valid request (from HTTP perspective), with a valid response using these
status codes (more specifically status codes 400 and 500).
If the request is a valid HTTP request then a 400 status doesn't seem
appropriate to me.
If the server is correctly handling that request to generate the
response, a 500 status doesn't seem right either.
I don’t think that in this scenario a request smuggling attack could be
executed, or am I missing something?
The main issue is if the original request is invalid HTTP there is no
way to determine where the next HTTP request starts.
If there is a proxy in the mix then the risks of something going wrong
tend to go up.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
