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

[Orange Tsai]

Sorry, please ignore that. That issue is not related to Wget. I sent to the
wrong mailing list. It's my fault :(

Tim Rühsen <address@hidden>於 2017年3月7日 週二，上午4:26寫道：

> On Dienstag, 7. März 2017 02:01:06 CET Orange Tsai wrote:
> > I am surprise that `http://address@hidden:address@hidden will connect to `
> > evil.com`, not `good.com`.
> > Most of URL parser will recognize `good.com` is host part. Like this
> > advisory, https://curl.haxx.se/docs/adv_20161102J.html
>
> The advisory is different in details (it's about # in userinfo, which is
> forbidden regarding RFC 3986).
>
> userinfo does not contain '@' and since
>         authority   = [ userinfo "@" ] host [ ":" port ]
> we know the userinfo is 'user' and than begins the host part.
>
> What is not correct in your example is that the port is not followed by /.
> So
> this kind of 'garbage' should result in an error (curl and wget2 ignore
> garbage after the port, which might not be correct, but is 'relaxed' style
> of
> parsing).
>
> > It seem more dangerous if a developer still rely on the result of parse
> URL
> > than my original report.
> >
> > Some testing:
> > $ python try.py 'http://address@hidden:address@hidden/x'
> >
> > Python scheme=http, address@hidden:address@hidden, port=
> > PHP scheme=http, host=127.2.2.2, port=
> > Perl scheme=http, host=127.2.2.2, port=80
> > Ruby2 scheme=http, host=127.2.2.2, port=
> > GO scheme=http, host=127.2.2.2, port=
> > Java scheme=http, host=, port=-1
> > JS scheme=http, host=127.2.2.2, port=null
>
> The only parser that handles it correctly is Java: returning an error.
>
> Tim
>
-- 
- Orange -