Well I figure there are a few ways to go here. One, find a way to present the multipart boundary back to the library user so that the user can check and escape their inputs and note with a big ol' caveat in the documentation that this is can be an issue to look out for (currently this is not mentioned at all). Two, check that the post contents including uploaded files passed by the user do not contain the selected multipart boundary and end up producing malformed requests; escape the input for the user or permute the multipart boundary so that the (none-too-bright) user input does not cause breakage. Three, do as Floris suggests and semi-securely randomize the seed value in Curl_srand.

\#1 helps and increases awareness of the potential pitfall, but pushes responsibility to the user who will inevitably make bad choices. The form boundary is also not created until Curl_getformdata is called, so that'd have to be shuffled around to be available earlier.
\#2 is probably the best solution for library usability in that user intervention is not necessary for the problem to go away, helping the most people with the least overall change. Unfortunately, it requires validating the form input similar to strstr when constructing the post data which is extra work that wouldn't be needed if the calling program disallowed strings in the same format as formboundary and pre-scanned file attachments for the same.
\#3 seems like the easiest effective solution to the problem listed by making the form boundary more difficult to guess and potentially corrupt post data. Use OS dependent mechanisms to get a random value to seed the PRNG with instead of time().

What do you think is the best way to go here?

---
** [bugs:#1251] Form boundary string should be truly random**
**Status:** open
**Created:** Mon Jun 24, 2013 11:24 AM UTC by Floris
**Last Updated:** Mon Jun 24, 2013 12:06 PM UTC
**Owner:** nobody
The use of predicatable pseudo-random numbers to generate the multipart/form boundary can lead to security issues in software using libcurl.
See: http://localhost.re/p/solusvm-whmcs-module-316-vulnerability
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.