ftp: make the MDTM date parser stricter (again)

A previous refactor made the parser more lenient and this takes it back
to making sure only ascii digits are accepted.

Added test 1684 to verify

Follow-up to 304b5183fd

Pointed out by Codex Security

Closes #21041
This commit is contained in:
Daniel Stenberg 2026-03-20 23:27:55 +01:00
parent 96d5b5c688
commit 322db3efc0
No known key found for this signature in database
GPG key ID: 5CC908FDB71E12C2
3 changed files with 60 additions and 11 deletions

View file

@ -226,7 +226,7 @@ test1666 test1667 \
\
test1670 test1671 \
\
test1680 test1681 test1682 test1683 \
test1680 test1681 test1682 test1683 test1684 \
\
test1700 test1701 test1702 test1703 test1704 test1705 test1706 test1707 \
test1708 test1709 test1710 test1711 test1712 test1713 \

46
tests/data/test1684 Normal file
View file

@ -0,0 +1,46 @@
<?xml version="1.0" encoding="US-ASCII"?>
<testcase>
<info>
<keywords>
FTP
MDTM
</keywords>
</info>
<reply>
<data>
a joke
</data>
<mdtm>
213 2003040a102659
</mdtm>
</reply>
# Client-side
<client>
<server>
ftp
</server>
<name>
FTP with malformed MDTM response
</name>
<command>
ftp://%HOSTIP:%FTPPORT/%TESTNUMBER -z "apr 1 2025 08:00:00"
</command>
</client>
# Verify data after the test has been "shot"
<verify>
<protocol crlf="yes">
USER anonymous
PASS ftp@example.com
PWD
MDTM %TESTNUMBER
EPSV
TYPE I
SIZE %TESTNUMBER
RETR %TESTNUMBER
QUIT
</protocol>
</verify>
</testcase>