Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Issue with MAX_COOKIE_HEADER_LEN
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Benjamin Herrenschmidt via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 18 May 2023 17:07:07 +1000
On Wed, 2023-05-17 at 16:44 +0200, Daniel Stenberg wrote:
> On Wed, 17 May 2023, Benjamin Herrenschmidt via curl-library wrote:
>
> > And more specifically by the 8KB limit applied to the cookier headers.
>
> Back again, having done some more thinking.
>
> The main problem with upping this limit is that a typical user don't know what
> the maximum allowed line length in the other end is. The limit was introduced
> because it was noticed that (some) servers will treat a too long line as a
> serious error and repond with a 400.
>
> If curl receives a set of cookies that combined needs TOO_LONG bytes to get
> sent over the wire, and it gets a 400 back, then curl is pretty much stuck and
> can't do anything against that server without some actions or when enough
> number of cookies expire...!
>
> So: not an easy limit to toy around with.
Ok. I got some data from the main affected customer in the meantime:
They are using curl to authenticate to ADFS using Kerberos and SAML
config. The Kerberos token itself is 6.8k in size. The cookie was 3.5k.
That brings it to 10.3k.
They also pointed to some MSFT documentation (link below) where it says
the default header size for IIS is 16KB.
https://support.microsoft.com/en-us/topic/how-to-limit-the-header-size-of-the-http-transmission-that-iis-accepts-from-a-client-in-windows-2000-a81639da-f1e9-2273-6de1-12f5b258a5c5
I agree that the failure mode you describe is ... sub-optimal. It was
my understanding the limit was introduced to fix a CVE caused by
unbounded growth but I might be mistaken.
Any better idea to solve the issue ? We (Amazon) could carry a
downstream only patch for our curl but I don't like that option much...
The above seems to be a legitimate use case.
Cheers,
Ben.
Date: Thu, 18 May 2023 17:07:07 +1000
On Wed, 2023-05-17 at 16:44 +0200, Daniel Stenberg wrote:
> On Wed, 17 May 2023, Benjamin Herrenschmidt via curl-library wrote:
>
> > And more specifically by the 8KB limit applied to the cookier headers.
>
> Back again, having done some more thinking.
>
> The main problem with upping this limit is that a typical user don't know what
> the maximum allowed line length in the other end is. The limit was introduced
> because it was noticed that (some) servers will treat a too long line as a
> serious error and repond with a 400.
>
> If curl receives a set of cookies that combined needs TOO_LONG bytes to get
> sent over the wire, and it gets a 400 back, then curl is pretty much stuck and
> can't do anything against that server without some actions or when enough
> number of cookies expire...!
>
> So: not an easy limit to toy around with.
Ok. I got some data from the main affected customer in the meantime:
They are using curl to authenticate to ADFS using Kerberos and SAML
config. The Kerberos token itself is 6.8k in size. The cookie was 3.5k.
That brings it to 10.3k.
They also pointed to some MSFT documentation (link below) where it says
the default header size for IIS is 16KB.
https://support.microsoft.com/en-us/topic/how-to-limit-the-header-size-of-the-http-transmission-that-iis-accepts-from-a-client-in-windows-2000-a81639da-f1e9-2273-6de1-12f5b258a5c5
I agree that the failure mode you describe is ... sub-optimal. It was
my understanding the limit was introduced to fix a CVE caused by
unbounded growth but I might be mistaken.
Any better idea to solve the issue ? We (Amazon) could carry a
downstream only patch for our curl but I don't like that option much...
The above seems to be a legitimate use case.
Cheers,
Ben.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-05-18