Ander Juaristi writes:
> On 06/03/17 16:47, Dale R. Worley wrote:
>> Orange Tsai 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
Oops
That my fault. I sent the wrong mail.
Very sorry :(
2017-03-07 3:03 GMT+08:00 Tim Rühsen :
> On Dienstag, 7. März 2017 02:01:06 CET Orange Tsai wrote:
> > I am surprise that `http://u...@evil.com:8...@good.com` will connect to `
> > evil.com`, not `good.com`.
> > Most
But still thanks :)
I will try to ask for allocating a CVE from https://cve.mitre.org/
2017-03-07 3:05 GMT+08:00 Orange Tsai :
> Oops
>
> That my fault. I sent the wrong mail.
>
> Very sorry :(
>
> 2017-03-07 3:03 GMT+08:00 Tim Rühsen :
>
>> On
On Dienstag, 7. März 2017 02:01:06 CET Orange Tsai wrote:
> I am surprise that `http://u...@evil.com:8...@good.com` 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
> It
I am surprise that `http://u...@evil.com:8...@good.com` 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
It seem more dangerous if a developer still rely on the result of parse
> From: Tim Ruehsen
> Date: Mon, 06 Mar 2017 10:17:25 +0100
> Cc: Orange Tsai
>
> Thanks, just pushed a commit, not allowing control chars in host part.
Hmm... is it really enough to reject only ASCII control characters?
Maybe we should also reject
Orange Tsai 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
On Monday, March 6, 2017 3:42:24 AM CET Orange Tsai wrote:
> Hi
>
> I just found that there is a CRLF Injection in the latest version of Wget
> 1.19.
>
> Wget uses urlencode to encode CRLF in PATH part but doesn't use in HOST
> port. So an attacker can inject arbitrary header in the request.
>
Hi
I just found that there is a CRLF Injection in the latest version of Wget
1.19.
Wget uses urlencode to encode CRLF in PATH part but doesn't use in HOST
port. So an attacker can inject arbitrary header in the request.
For example:
# This will fail
$ wget 'http://127.0.0.1/%0d%0Cookie: hi'