client should not send longer request headers than server can accept

[elarlang]

spin-off from #1739 (comment)

Problem to solve: if a user controls input that is sent to the server via request header (token) value, it must be validated or sanitized to not be longer than the "max header field size" allowed by server configuration, usually it is 8kB.

Classical functionality: cookies, authorization headers (including access_token JWT's)

If an attacker controls the value and can set it to the client browser, this client will have error 413 or 400 as a response for each request and can not use the service.

[tghosth]

This is input validation or sanitization of content going into an HTTP request, it is basically an expansion of #1739 (comment) where instead of a cookie we are talking about any header entry, correct?

[elarlang]

This is input validation or sanitization of content going into an HTTP request, it is basically an expansion of #1739 (comment) where instead of a cookie we are talking about any header entry, correct?

yes, the same problem is for every HTTP request header (field) which contains user-controlled input

[jmanico]

Please note this is more of a Webserver issue than an application issue. For example, Apache has a default 8k limit for the total size of the request header. NGINX is 4K.

[elarlang]

Statement in the issue:

Problem to solve: if a user controls input that is sent to the server via request header (token) value, it must be validated or sanitized to not be longer than the "max header field size" allowed by server configuration, usually it is 8kB.

Comment from @jmanico

Please note this is more of a Webserver issue than an application issue. For example, Apache has a default 8k limit for the total size of the request header. NGINX is 4K.

So, yes it is a webserver configuration question, but at the same time, the application needs to take this limit into account, and do not build longer values than it (a web server) can handle.

[tghosth]

Ok can you prepare a requirement text for this @elarlang ?

[elarlang]

Not ready yet to propose requirement text, just pieces to take into account:

• situation: if user input is sent to the server automatically by the browser
• problem: if automatically sent content length is larger than the server accepts (examples Cookie, Authorization, or any custom header that is always sent automatically by the frontend)
• outcome (issue to avoid): then it can cause a client-based denial of service attack - the browser automatically sends too long value and the server always responds with an error