On 18/11/2013 17:21, Albrecht Scheidig wrote: > Hi there, I have not found any issues in JIRA regarding > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2186 > Should not this get fixed in fileupload?
No. This vulnerability requires that an application accepts data from a client and then, without validating it, de-serializes it. That is equivalent to using untrusted, unvalidated client input to build an SQL statement (SQL injection) or using untrusted, unvalidated client input to generate an HTML response (XSS). The vulnerability is, therefore, an application vulnerability not a Commons FileUpload vulnerability. There are some things we could do to mitigate this application vulnerability in FileUpload. One possible change would be to automatically generate a new temporary filename on deserialization. This actually has advantages for the real use case of deserialization which is migrating objects in an HTTP session between JVMs since it better handles the case where the JVMs have different temporary locations. As always, patches welcome. Aside: Validating data before deserializing it is hard. However, just because it is hard, it doesn't shift the responsibility for doing it. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
