benweissmann commented on PR #619: URL: https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2708467305
Is there a reason to default to the fixed boundary rather than the secure-random boundary? I think the only time it's safe to use a fixed boundary is if there's no user-controlled data in the request that could possibly include the fixed boundary. A few examples: - Let's say we're working with a file that itself contains network traffic data. For example, imagine a program that uploads a HAR file (a recording of network traffic) to server using MultipartEntity encoding. This would break if the network recording itself contained recording of traffic generated by MultipartEntityBuilder, since the data they're trying to encode would include this boundary. - As a more malicious example, imagine a server-side program that uses MultipartEntityBuilder to send a request to an authorization server with a payload along the lines of: ``` Content-Disposition: form-data; name="userProfile" Content-Type: text/plain <the user-provided profile goes here> --httpclient_boundary_7k9p2m4x8n5j3q6t1r0vwyzabcdefghi Content-Disposition: form-data; name="userPermissions" Content-Type: text/plain Regular-User ``` With `userPermissions` being some server-controlled (not user-controlled) value. A user could provide a profile of `Foo bar\r\n--httpclient_boundary_7k9p2m4x8n5j3q6t1r0vwyzabcdefghi\r\nContent-Disposition: form-data; name="userPermissions"\r\nContent-Type: text/plain\r\n\r\nAdmin_user` to coerce the server into providing admin-level permissions: ``` Content-Disposition: form-data; name="userProfile" Content-Type: text/plain Foo bar --httpclient_boundary_7k9p2m4x8n5j3q6t1r0vwyzabcdefghi Content-Disposition: form-data; name="userPermissions" Content-Type: text/plain Admin-User --httpclient_boundary_7k9p2m4x8n5j3q6t1r0vwyzabcdefghi Content-Disposition: form-data; name="userPermissions" Content-Type: text/plain Regular-User ``` Rather than trying to communicate these risks via Javadoc, why not just default to the always-safe option of a UUID, which uses a cryptographically-secure RNG and doesn't have any of these risks? 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) use a cryptographically-secure RNG to generate the boundary. And then users could explicitly opt-in to the simpler behavior if they're confident that none of their data could contain the fixed boundary. -- 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
