Message298824
| Author | ecbftw |
|---|---|
| Recipients | christian.heimes, corona10, ecbftw, giampaolo.rodola, martin.panter, serhiy.storchaka, supl, vstinner |
| Date | 2017-07-21.21:04:47 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1500671087.97.0.352345187418.issue29606@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
> What is wrong with an URL containing '\n'? I suppose that when format a request with a text protocol, embedded '\n' can split the request line on two lines and inject a new command. The most robust way would be to check whether the formatted line contains '\n', '\r', '\0' or other illegal characters. I agree, there's nothing wrong with an encoded line feed (%0a) in a URL. HTTP can easily handle '\n' in a basic auth password field, for instance. The problem is when these characters are included in a context where they are interpreted as a delimiter of some kind. In FTP's case, they are being interpreted as the delimiter between commands. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2017-07-21 21:04:48 | ecbftw | set | recipients: + ecbftw, vstinner, giampaolo.rodola, christian.heimes, martin.panter, serhiy.storchaka, supl, corona10 |
| 2017-07-21 21:04:47 | ecbftw | set | messageid: <1500671087.97.0.352345187418.issue29606@psf.upfronthosting.co.za> |
| 2017-07-21 21:04:47 | ecbftw | link | issue29606 messages |
| 2017-07-21 21:04:47 | ecbftw | create | |