This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ecbftw
Recipients christian.heimes, corona10, ecbftw, giampaolo.rodola, martin.panter, serhiy.storchaka, supl, vstinner
Date 2017-07-21.20:38:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1500669503.8.0.942565948356.issue29606@psf.upfronthosting.co.za>
In-reply-to
Content
> The best place to reject invalid characters is where the URL is parsed, no? See also my bpo-30713.

No I don't really agree with that.  What other APIs can be used to submit a directory name, user name, password, or other field in an FTP command?  If you block unacceptable characters only at URL parsing, then you fail to address those other vectors.

The normal way to fix any injection vulneability is to encode the dangerous characters just before then are included in the surrounding syntax. Unfortunately in FTP's case, there's no widely-accepted way to encode these characters. So I think you should instead throw an exception right before the commands are put on the control channel.  Fixing the bug at the "sink" like this is a far more resilient way to address injections.

Any "legitimate" use case that users might have for these characters wouldn't have worked anyway. The code is already broken for new lines in file names. If you change the code such that it throws an exception when they are written to the control channel, that's a better mode of failure than what you have right now.
History
Date User Action Args
2017-07-21 20:38:23ecbftwsetrecipients: + ecbftw, vstinner, giampaolo.rodola, christian.heimes, martin.panter, serhiy.storchaka, supl, corona10
2017-07-21 20:38:23ecbftwsetmessageid: <1500669503.8.0.942565948356.issue29606@psf.upfronthosting.co.za>
2017-07-21 20:38:23ecbftwlinkissue29606 messages
2017-07-21 20:38:23ecbftwcreate