benweissmann opened a new pull request, #625: URL: https://github.com/apache/httpcomponents-client/pull/625
See more context in discussion from #619. The advantage of using a random boundary by default are: - It's in line with the behavior recommended by RFC 2046, [as discussed here](https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727040042) - It's in line with most [other](https://github.com/urllib3/urllib3/blob/3e8f2db735dcaced6a3b777aa1966f40c018af7c/src/urllib3/filepost.py#L26) [MultipartEntity](https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/mime/multipart/writer.go;l=87) [libraries](https://github.com/nodejs/undici/blob/f11ae944dab697d2dc22318403200b144b4b2b91/lib/web/fetch/body.js#L121) so will minimize surprises for users who have used multipart encoding in other languages or libraries, and doesn't require us to reason about the operational or security considerations of a novel or uncommon boundary selection scheme - It does not risk mis-encoding content that happens to contain the hardcoded boundary, which could happen for nested bodies (while this library does provide affordances for constructing such bodies, there's no prohibition around passing a body constructed by this library as a part of another body, and there could easily be in-the-wild code that does so), or for content that happens to be discussing the hard-coded boundary value itself (consider, for example, a Java-based Github client, and how it would handle posting a multipart/form-encoded comment on this repo discussing the boundary value). - It avoids attacks like the one tracked as [CVE-2025-22150](https://nvd.nist.gov/vuln/detail/CVE-2025-22150) where an attacker can trick an application into including unexpected fields via a crafted payload that contains the boundary value. - Of note, the current default behavior makes this attack much, much simpler than the one in that CVE, because an attacker does not need to guess the random value from an insecure random number generator; all existing libraries and applications that use httpcomponents-client will start using the new hard-coded default value when they upgrade unless they explicitly opt-in to the new random behavior or were already generating their own boundary values. - As a practical, in-the-wild example of this, consider this [Modern Treasury Kotlin library function](https://github.com/Modern-Treasury/modern-treasury-kotlin/blob/cb41cbb555312728a6fb9f33285e838f502ed957/modern-treasury-kotlin-core/src/main/kotlin/com/moderntreasury/api/services/blocking/DocumentServiceImpl.kt#L31), which uses [uses our MultipartFormBuilder](https://github.com/Modern-Treasury/modern-treasury-kotlin/blob/cb41cbb555312728a6fb9f33285e838f502ed957/modern-treasury-kotlin-core/src/main/kotlin/com/moderntreasury/api/core/HttpRequestBodies.kt#L45) API to hit [the Create Document](https://docs.moderntreasury.com/platform/reference/create-document) api endpoint. - Consider the most common likely usage of this function: - A Kotlin web application allows users to upload documents, like I-9 forms or other financial or compliance paperwork - The server-side component of this application receives the document from an authenticated user, and then uses this API method to attach the user-provided document to corresponding Modern Treasury entity. For example, it might take an employee's I-9 (employment verification form) and attach it to that employee's bank account record in a payroll system. - A malicious user could upload a PDF that ends with ``` <regular PDF data> --httpclient_boundary_7k9p2m4x8n5j3q6t1r0vwyzabcdefghi Content-Disposition: form-data; name="documentable_id" Content-Type: text/plain some-other-account-id ``` - Now, instead of the server-side component of this application sending the user-provided PDF and the server-provided "documentable_id", it would be tricked into sending an attacker-controlled documentable_id, which would associate the financial or compliance paperwork with the wrong account. While there is disagreement from some maintainers on some of these points, I would content that *any one* of these four arguments should be sufficient to use the secure-random UUID default behavior, rather than the currently-implemented fixed-value default (or, for that matter, the currently-released insecure random default). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
