bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part


From: Dale R. Worley
Subject: Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part
Date: Wed, 08 Mar 2017 11:11:18 -0500

Ander Juaristi <address@hidden> writes:
> On 06/03/17 16:47, Dale R. Worley wrote:
>> Orange Tsai <address@hidden> writes:
>>> # This will work
>>> $ wget 'http://127.0.0.1%0d%0aCookie%3a hi%0a/'
>> 
>> Not even considering the effect on headers, it's surprising that wget
>> doesn't produce an immediate error, since
>> "127.0.0.1%0d%0aCookie%3a hi%0a" is syntactically invalid as a host
>> part.  Why doesn't wget's URL parser detect that?
>
> Simply because it first splits the URL into several parts according to
> the delimiters, and then decodes the percent-encoding.
>
> Additionally for the host part it also checks whether it's an IP address
> and the IDNA stuff, but yeah you raise a good point. Other than that the
> host part is treated similarly to the other parts.

Ah, I looked into RFC 3986, and the generic syntax *does* allow the host
part to contain %-escapes.  But in any case,
"127.0.0.1<CR><LF>Cookie:<SPACE>hi<LF>" is not parsable as an IPv4
address.  (Always beware of parsing functions that stop when they see
the first invalid character!)

(Also, shouldn't the above example have ended "hi%0d%0a/"?)

Dale



reply via email to

[Prev in Thread] Current Thread [Next in Thread]