On 12/03/12 20:36, Richard Lynch wrote: > On Sun, March 11, 2012 6:29 pm, Stas Malyshev wrote: >> This doesn't look good. Documentation does say the @ prefix exists, >> but >> it has very high potential of creating security holes for unsuspecting >> people. open_basedir would help limit the impact, but still it's not a >> good thing. Any ideas on fixing it without breaking the BC? > Ouch. > > Issue an E_NOTICE when it happens? > > Add a new CURLOPT_FILEFIELDS that takes an array of the parameters > that are supposed to be files, so the ones that are expected to have > "@..." do not fire the E_NOTICE. > > Issuing E_NOTICE is a BC, I suppose, but you'd think people would > appreciate an alert about a potential security threat... That would only trigger the notice when you transfer data beginning with an @, which would end up being only when finally attacked.
I'd make it need another option to make @ options work (eg. CURLOPT_AT_TRANSFERS_FILES) which default to false. Similar to SO_BROADCAST, where binding a socket to a broadcast address is not enough to send the packets there. It *is* a BC break, but the current API is badly provided. I don't see a way to work around that. A one-line fix to get the previous not-too-used(?) behavior back seems as good as can be achieved. It is also possible to make a completely new option API without those problems, and deprecate the old one, but that's still a BC break. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
