springspring-security

CVE-2024-38809: Spring Framework DoS via conditional HTTP request


https://spring.io/security/cve-2024-38809

As per above link either we should upgrade version or apply filter.

Now my issue is i am using older spring version and i can not upgrade because of other dependencies and long testing cycles.

i want to apply filter, and it is mentioned in above link that "Users of older, unsupported versions could enforce a size limit on "If-Match" and "If-None-Match" headers, e.g. through a Filter."

What should be appropriate size limit of "If-Match" and "If-None-Match" headers ?

how by restricting its size limit will solve issue ?

How can someone attack by "If-Match" and "If-None-Match" headers in request ?

No documentations or github links available for older version and its solution.


Solution

  • i want to apply filter, and it is mentioned in above link that "Users of older, unsupported versions could enforce a size limit on "If-Match" and "If-None-Match" headers, e.g. through a Filter."

    Awesome.

    How can someone attack by "If-Match" and "If-None-Match" headers in request ?

    In summary, the atacker will try to exhaust your CPU (causing DoS) by provinding a really long list of values in the If-Match or If-None-Match header ... you can read more of this in here.

    how by restricting its size limit will solve issue ?

    Well, it will act as a break fast logic ... instead of parsing the whole list of values, you will read at most X number of values, preveting CPU exhaustion.

    What should be appropriate size limit of "If-Match" and "If-None-Match" headers ?

    It depends. There is no magic number. You should select a number according to your API use or business case ...

    No documentations or github links available for older version and its solution.

    You're right about this. They do not provide an example for the proposed filter. However, this is the GIT commit that shows how they solved the issue ... you can use it as a starting point to implement the filter (or the logic associated to it) ... NOTE: As you can see, what they did was to replace the use of RegEx for parsing the Etag values to a more vanilla (but efficient) parsing ...

    Additionally, more resources:

    Issue track of some library

    mend.io