-
-
Notifications
You must be signed in to change notification settings - Fork 774
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
Add configurable limit for the maximum length of Object property names to parse before failing (default max: 50,000 chars) #1047
Comments
I am also in favor of this ticket, as I wrote in this comment: #1014 (comment) |
@AlessandroPerucchi note that there is already ability to change existing limits: this would introduce one more limit. |
Related issue: spring-projects/spring-boot#36666 the key names are not controlled and produces an integer overflow when try copy the byte array. Confirmed in Java Spring Framework. |
Quick note: based on simple local testing with longer names, it looks like performance of, say, 1_000_000 (ascii) bytes/chars decoding is not superbly bad -- actually, unit test with cold start seems to process doc with 10 meg name in about 150 msecs. And although other factors (escaping, UTF-8 chars) no doubt change things (quick testing with escapes and 2-byte chars actually increases time to almost 500 msecs), I think we can -- if we want to -- allow larger names than 50k, by default, if we want to. I'll see if I can find limits other processors impose. |
Implemented via #1078. |
(note: part of #637)
Similar to token-length limits for Numbers (see #815) and Strings (see #863), we need an option to limit maximum Object Property name length to something reasonable, as otherwise name tokenization can become performance issue for very long names.
As with other limits, units would related to underlying input units --
byte
s orchar
s depending on input source.We need to decide on reasonable defaults to use: my initial suggestion is to limit to 64k but this probably needs to correlated to:
That is: figure out highest limit that works for DoS aspect, balanced with lowest limit that would be unlikely to break existing legit usage.
The text was updated successfully, but these errors were encountered: